S3 Ep105: WONTFIX! Az MS Office kriptográfiai hibája, amely „nem biztonsági hiba” [Hang + szöveg]

Kattintson és húzza az alábbi hanghullámokat, hogy bármelyik pontra ugorjon. Te is hallgatni közvetlenül a Soundcloudon.

DOUG.  Lélegzetelállító adatsértések, visszafejthető titkosítás és rengeteg javítás.

Mindezt a Naked Security podcastban.

[ZENEI MODEM]

Üdvözlünk mindenkit a podcastban.

Doug Aamoth vagyok; ő Paul Ducklin.

Paul, hogy van ma, uram?

---

KACSA.  Doug… tudom, mert előre megmondtad, mi jön Ezen a héten a technikatörténetben, és NAGYON!

---

DOUG.  OK!

Ezen a héten, 18. október 1958-án egy oszcilloszkópot és egy szélellenállás szimulálására épített számítógépet egyedi alumínium vezérlőkkel párosítottak, és a játék Tenisz kettőre született.

A Brookhaven National Laboratory háromnapos kiállításán bemutatott Tennis for Two rendkívül népszerűnek bizonyult, különösen a középiskolások körében.

Ha ezt hallgatod, menj a Wikipédiába, és keresd meg a „Tennis for Two”-t.

Van egy videó valamiről, amit 1958-ban építettek…

…Azt hiszem, egyetértesz velem, Paul, ez elég hihetetlen volt.

---

KACSA.  *Szeretnék* játszani vele ma!

És, mint az Asteroids és a Battle Zone, és azok a különlegesen emlékezetes játékok az 1980-as évekből…

…mert ez egy oszcilloszkóp: vektorgrafika!

Nincs pixelláció, nincs különbség attól függően, hogy egy vonal 90 fokos, 30 fokos vagy 45 fokos.

És a hangvisszajelzés a vezérlők relékéből… ez nagyszerű!

Hihetetlen, hogy ez 1958 volt.

Visszakanyarodva az előzőhöz Ezen a héten a technikatörténetben, a tranzisztoros forradalom tetőpontján volt.

Úgy tűnik, a számítási fél termikus szelepek (vákuumcsövek) és relék keveréke volt.

És a kijelző áramköre mind tranzisztor alapú volt, Doug

Tehát az összes technológia keverékében volt: relék, szelepek és tranzisztorok, mindez egyetlen úttörő videojátékban.

---

DOUG.  Nagyon jó.

Nézd meg a Wikipédián: Tenisz kettőre.

Most pedig térjünk át az első történetünkre.

Paul, tudom, hogy nagyon ügyes vagy egy nagyszerű vers írásában…

…Írtam egy nagyon rövid verset, hogy bemutassam ezt az első történetet, ha megengedi.

---

KACSA.  Akkor ez két sor lesz, nem? [NEvet]

---

DOUG.  Kicsit így megy.

Nagyítás Mac-en/Nem értem eltérített.

[NAGYON HOSSZÚ CSEND]

Vége vers.

---

KACSA.  Ó, bocs!

Azt hittem, ez a cím, és hogy most megcsinálod a verset.

---

DOUG.  Szóval ez a vers.

---

KACSA.  OK.

[Érzelem NÉLKÜL] Kedves, Doug.

---

DOUG.  [IRONIC] Köszönöm.

---

KACSA.  A mondóka látványos volt!

De nem kell minden versnek rímelnie…

---

DOUG.  Ez igaz.

---

KACSA.  Nevezzük csak szabad versnek, igaz?

---

DOUG.  Rendben, kérem.

---

KACSA.  Sajnos ez egy ingyenes hátsó ajtó volt a Zoom for Mac számára.

[BŰNŰN ÉRT] Sajnálom, ez nem volt túl jó lépés, Doug.

[NEVESZ] Másnak a gyepén tapossz, gyakran kiakadsz…

---

DOUG.  Nem, ez jó!

A héten versekkel próbálkoztam; te próbálkozol a vonulatokkal.

Időnként ki kell lépnünk a komfortzónánkból.

---

KACSA.  Feltételezem, hogy ez egy olyan kód volt, amelyet a végső build elkészítésekor kellett lefordítani, de véletlenül benne maradt.

Csak a Zoom for Mac verzióhoz készült, és javítva lett, ezért győződjön meg róla, hogy naprakész.

Alapvetően bizonyos körülmények között, amikor egy videofolyam elindul, vagy a kamerát maga az alkalmazás aktiválta, véletlenül azt gondolná, hogy esetleg hibakeresést szeretne végezni a programban.

Mert hé, talán fejlesztő voltál! [NEvet]

Nyilvánvalóan ennek nem szabadna megtörténnie a kiadási összeállításokban.

Ez pedig azt jelentette, hogy a helyi hálózati interfészen nyitva maradt egy TCP hibakereső port.

Ez azt jelentette, hogy bárki, aki át tud küldeni csomagokat arra a portra, ami feltehetően bármely más, helyileg csatlakoztatott felhasználó lehet, így nem kell rendszergazdának lennie, vagy még neked sem… még vendégfelhasználónak sem.

Tehát egy támadó, akinek valamilyen proxy malware volt a számítógépén, amely képes csomagokat fogadni kívülről, és bejuttatni a helyi interfészbe, alapvetően parancsokat adhat ki a program zsigereinek.

És a tipikus dolgok, amelyeket a hibakereső felületek lehetővé tesznek, a következők: memória kiürítése; kivonat titkokat; változtassa meg a program viselkedését; állítsa be a konfigurációs beállításokat anélkül, hogy átmenne a szokásos felületen, hogy a felhasználó ne lássa; rögzítse az összes hangot anélkül, hogy szólna senkinek, anélkül, hogy felbukkanna a felvételi figyelmeztetés; minden ilyen cucc.

A jó hír az, hogy a Zoom magától megtalálta, és elég gyorsan kijavította.

De nagyszerű emlékeztető, hogy ahogy oly gyakran mondjuk: [NEVETÉS] „Sok csúszás van a pohár és az ajak között.”

---

DOUG.  Rendben, nagyon jó.

Maradjunk a patch train fedélzetén, és álljunk be a következő állomásra.

És ez a történet… a legutóbbi javítási kedd történetének talán legérdekesebb része az volt amit a Microsoft *nem* tartalmazott?

---

KACSA.  Sajnos azok a javítások, amelyeket valószínűleg mindenki várt – és egy nemrégiben megjelent podcastban azt gondoltuk: „Nos, úgy tűnik, hogy a Microsoft arra késztet bennünket, hogy még egy hetet várjunk a javítás keddjéig, és ne készítsünk sávon kívüli „korai kiadást” ” a legutóbbi memória két Exchange nulladik napja.

Ami E00F néven vált ismertté, ill Csere Dupla nulladik napi hiba az én terminológiámban, ill ProxyNotShell ahogy ezt talán kissé zavaróan ismerik a Twitter-szférában.

Tehát ez volt a nagy sztori az e havi Patch Kedden: ezt a két hibát látványosan nem javították ki.

És ezért nem tudjuk, hogy ez mikor fog megtörténni.

Meg kell győződnie arról, hogy alkalmazott-e bármilyen enyhítő intézkedést.

Ahogy azt hiszem, korábban is mondtuk, a Microsoft folyamatosan azt tapasztalta, hogy az általuk javasolt korábbi enyhítések… nos, talán nem voltak elég jók, és folyamatosan változtatták a dallamot, és adaptálták a történetet.

Tehát, ha kétségei vannak, lépjen vissza a nakedsecurity.sophos.com webhelyre, és keressen rá a kifejezésre ProxyNotShell (egy szó), majd menj és olvasd el a mondandónkat.

Ezenkívül linkelheti a Microsoft orvoslásának legújabb verzióját is…

…mert a Patch Tuesday összes dolga közül ez volt a legérdekesebb, ahogy mondod: mert nem volt ott.

---

DOUG.  OK, most kapcsoljunk a fokozatba nagyon elkeserítő történet.

Ez egy pofon egy nagy cégnek, amelynek a kiberbiztonsága annyira rossz, hogy észre sem vették, hogy megsértették!

---

KACSA.  Igen, ez egy olyan márka, amelyet a legtöbben valószínűleg SHEIN ("she-in") néven ismernek, egyetlen szóként írva, nagybetűkkel. (A jogsértés idején a cég Zoetop néven volt ismert.)

És ezek az úgynevezett „gyorsdivat”.

Tudod, felhalmozzák, és olcsón adják el, és nem vita nélkül, hogy honnan szerzik a terveket.

Online kiskereskedőként pedig talán azt várná, hogy az online kiskereskedelem kiberbiztonsági részleteit megtagadják.

De ahogy mondod, nem tették!

New York állam főügyészének hivatala pedig úgy döntött, hogy nem elégedett azzal, ahogyan a New York-i lakosokkal bántak, akik a jogsértés áldozatai voltak.

Ezért jogi lépéseket tettek ezzel a céggel szemben… és ez a baklövések, hibák és végső soron eltitkolások abszolút litániája volt – egyszóval Douglas, becstelenség.

Volt ez a szabálytalanság, amit nem vettek észre.

Ez, legalábbis a múltban, kiábrándítóan gyakori volt: a vállalatok csak akkor vették észre, hogy jogsértést elkövettek, amíg egy hitelkártya-kezelő vagy egy bank fel nem vette velük a kapcsolatot, és azt mondta: „Tudjátok mit, rettenetesen sokat kaptunk. az ügyfelek csalással kapcsolatos panaszai ebben a hónapban.”

„És ha visszatekintünk arra, amit CPP-nek hívnak, a közös vásárlási hely, az egyetlen kereskedő, akitől úgy tűnik, minden áldozat vásárolt valamit, te vagy. Úgy gondoljuk, hogy a szivárgás öntől származott."

És ebben az esetben még rosszabb volt.

Nyilván jött egy másik fizetési feldolgozó, és azt mondta: „Ó, mellesleg, egy egész részletet találtunk eladó hitelkártyaszámokból, amelyeket ellopottként kínáltak tőletek, srácok.”

Tehát egyértelmű bizonyítékuk volt arra vonatkozóan, hogy vagy tömegesen, vagy apránként megsértés történt.

---

DOUG.  Így biztosan, amikor ezt a cég tudomást szerzett erről, gyorsan intézkedtek a helyzet orvoslása érdekében, igaz?

---

KACSA.  Nos, ez attól függ, hogyan… [NEVETÉS] Nem szabad nevetnem, Doug, mint mindig.

Ez attól függ, hogy mit értesz „helyreigazítás” alatt.

---

DOUG.  [NEVETÉS] Ó, istenem!

---

KACSA.  Úgy tűnik tehát, hogy *meg* foglalkoztak a problémával… sőt, voltak olyan részek, amelyeket nagyon jól elfedtek.

Látszólag.

Úgy tűnik, hirtelen úgy döntöttek: „Hoppá, jobb lesz, ha PCI DSS-kompatibilis leszünk”.

Nyilvánvalóan nem, mert láthatóan hibakeresési naplókat vezettek, amelyekben a sikertelen tranzakciók hitelkártyaadatai voltak… mindent, amit nem szabad lemezre írni, ők írták.

Aztán rájöttek, hogy ez megtörtént, de nem találták, hol hagyták ezeket az adatokat a saját hálózatukban!

Tehát nyilvánvalóan tudták, hogy nem PCI DSS-kompatibilisek.

Úgy tűnik, hozzáláttak, hogy PCI DSS-kompatibilissé tegyék magukat, amit 2019-re sikerült elérniük. (A jogsértés 2018-ban történt.)

De amikor azt mondták nekik, hogy alá kell vetniük magukat egy auditnak, egy törvényszéki vizsgálatnak…

…a New York-i főügyész szerint szándékosan álltak a nyomozó útjába.

Alapvetően megengedték a nyomozóknak, hogy lássák a rendszert olyannak, amilyen volt *miután* megjavították, meghegesztették és polírozták, és azt mondták: "Ó, nem, nem látod a biztonsági másolatokat", ami nekem elég szemtelenül hangzik. .

---

DOUG.  UH Huh.

---

KACSA.  És az is, ahogyan felfedték ügyfeleiknek a jogsértést, jelentős haragot váltott ki New York államból.

Különösen úgy tűnik, hogy teljesen nyilvánvaló volt, hogy 39,000,000 5 XNUMX felhasználó adatait valamilyen módon eltüntették, beleértve a nagyon gyengén hasított jelszavakat: egy kétjegyű sót és egy kör MDXNUMX-öt.

Nem elég jó 1998-ban, nemhogy 2018-ban!

Tudták tehát, hogy ezzel a nagy számú felhasználóval probléma van, de láthatóan csak azon 6,000,000 millió felhasználóval vették fel a kapcsolatot, akik ténylegesen használták a fiókjukat és adtak le rendeléseket.

Aztán azt mondták: "Nos, legalább felvettük a kapcsolatot ezekkel az emberekkel."

És *akkor* kiderült, hogy valójában nem vették fel a kapcsolatot mind a 6,000,000 XNUMX XNUMX millió felhasználóval!

Éppen azokkal a hatmillió emberrel léptek kapcsolatba, akik történetesen Kanadában, az Egyesült Államokban vagy Európában éltek.

Szóval, ha a világ bármely pontjáról származol, balszerencse!

Amint elképzelhető, ez nem ment jól a hatóságoknak, a szabályozónak.

És be kell vallanom… meglepetésemre, Doug, 1.9 millió dolláros bírságot kaptak.

Ami egy ekkora cégnek…

---

DOUG.  Igen!

---

KACSA.  …és ilyen kirívó hibákat elkövetni, majd nem egészen tisztességesnek és őszintének lenni a történtekkel kapcsolatban, és megrovásban részesítette, hogy hazudott a jogsértésről, vagyis New York főügyésze?

Valahogy úgy képzeltem, hogy komolyabb sorsra juthatnak.

Talán még valami olyasmit is tartalmaz, amit nem lehetett csak úgy kifizetni, ha előteremt egy kis pénzt.

Ja, és a másik dolog, amit tettek, az az, hogy amikor nyilvánvaló volt, hogy vannak olyan felhasználók, akiknek a jelszava veszélyben van… mert mélyen feltörhetőek voltak, mivel két számjegyű só volt, ami azt jelenti, hogy 100 előre kiszámított szótárat tud készíteni. …

---

DOUG.  Ez gyakori?

Csak egy két számjegyű só nagyon kevésnek tűnik!

---

KACSA.  Nem, általában 128 bitet (16 bájt) vagy akár 32 bájtot szeretne.

Lazán szólva a feltörési sebességen egyébként nincs jelentős különbség, mert (a hash blokkméretétől függően) csak két plusz számjegyet adsz hozzá a mixhez.

Tehát még csak nem is olyan, mintha a hash-ek tényleges kiszámítása tovább tartana.

2016-ban a „hashcat” programot futtató nyolc GPU számítógépét használó emberek szerintem másodpercenként 200 milliárd MD5-öt tudtak csinálni.

Akkoriban! (Ez az összeg most körülbelül ötszöröse vagy tízszerese.)

Szóval nagyon-nagyon kiválóan feltörhető.

De ahelyett, hogy felvennék a kapcsolatot az emberekkel, és azt mondanák: „A jelszava veszélyben van, mert kiszivárogtattuk a hash-t, és ez nem volt túl jó, meg kellene változtatni” [NEVETÉS], csak azt mondták…

…nagyon nyálas szavak voltak, nem?

---

DOUG.  „A jelszava alacsony biztonsági szinttel rendelkezik, és valószínűleg veszélyben van. Kérjük, változtassa meg bejelentkezési jelszavát."

Aztán a következőre változtatták: „A jelszavad több mint 365 napja nem frissült. Az Ön védelme érdekében kérjük, frissítse most."

---

KACSA.  Igen, „Az Ön jelszavának biztonsági szintje alacsony…”

---

DOUG.  – MIATTUNK!

---

KACSA.  Ez nem csak pártfogás, igaz?

Ez az én szememben az áldozatok hibáztatásának határán vagy túl.

Különben is, ez számomra nem tűnt túl erős ösztönzőnek azon cégek számára, amelyek nem akarnak helyesen cselekedni.

---

DOUG.  Rendben, hallgassuk meg véleményét a megjegyzésekben!

Ennek a cikknek a neve: A SHEIN divatmárka 1.9 millió dolláros bírságot szabott ki adatszivárgásról szóló hazudozásért.

És egy másik elkeserítő történet…

.., egy másik nap, egy újabb figyelmeztető mese a megbízhatatlan bevitel feldolgozásáról!

---

KACSA.  Aaargh, tudom, mi lesz az, Doug.

Az a Apache Commons szöveg hiba, nem?

---

DOUG.  Ez!

---

KACSA.  Csak hogy világos legyen, ez nem az Apache webszerver.

Az Apache egy szoftveralap, amely egy sor termékkel és ingyenes eszközzel rendelkezik… és ezek valóban nagyon hasznosak, nyílt forráskódúak és nagyszerűek.

De az ökoszisztéma Java részében (az Apache Web Server httpd nem Java nyelven íródott, ezért ezt most hagyjuk figyelmen kívül – ne keverjük össze az Apache-t az Apache webszerverrel)…

…az elmúlt évben három hasonló problémánk volt az Apache Java könyvtáraiban.

Nálunk volt a aljas Log4Shell bogár az úgynevezett Log4J (Logging for Java) könyvtárban.

Aztán volt egy hasonló hiba, mi volt az?… Apache Commons konfiguráció, amely egy eszközkészlet mindenféle konfigurációs fájlok, mondjuk INI fájlok és XML fájlok kezelésére, mindezt szabványosított módon.

Most pedig egy még alacsonyabb szintű könyvtárban ún Apache Commons szöveg.

A hiba abban a dologban, amit a Java-ban általában „karakterlánc-interpolációnak” neveznek.

Programozók más nyelveken… ha olyan dolgokat használ, mint a PowerShell vagy a Bash, akkor ezt „karakterlánc-helyettesítésként” fogja tudni.

Itt varázslatosan egy karakterekkel teli mondatot egyfajta miniprogrammá varázsolhatsz.

Ha valaha is használta a Bash parancsértelmezőt, akkor tudni fogja, ha beírja a parancsot echo USER, visszhangozni fogja vagy kiírja a karakterláncot USER és látni fogja a képernyőn a FELHASZNÁLÓ feliratot.

De ha lefuttatja a parancsot echo $USER, akkor ez nem jelenti azt, hogy egy dollárjelet visszhangozzon, majd a USER.

Ez azt jelenti, hogy „Cserélje ki ezt a varázslatos karakterláncot a jelenleg bejelentkezett felhasználó nevére, és nyomtassa ki helyette.”

Tehát a számítógépemen, ha te echo USER, kapsz USER, de ha te echo $USER, érted a szót duck helyette.

És a Java karakterlánc-helyettesítések némelyike ​​ennél sokkal, sokkal, de sokkal tovább megy… mint bárki, aki elszenvedte a a Log4Shell javítása 2021 karácsonyán emlékezni fog!

Mindenféle okos kis miniprogram létezik, amelyeket beágyazhat a karakterláncokba, amelyeket aztán feldolgozhat ezzel a karakterlánc-feldolgozó könyvtárral.

Tehát ott van a nyilvánvaló: a felhasználónév elolvasásához, felteszed ${env: (az „olvasd el a környezetet”) user}… kanyargós zárójeleket használ.

Ez dollárjel; kancsal tartó; valami varázsparancs; squiggly zárójel, amely a varázslatos rész.

És sajnos ebben a könyvtárban ellenőrizetlen alapértelmezett mágikus parancsok állnak rendelkezésre, mint például: ${url:...}, amely lehetővé teszi, hogy rávegye a karakterlánc-feldolgozó könyvtárat, hogy elérje az internetet, letöltsen valamit, és a karakterlánc helyett azt írja ki, amit az adott webszervertől kap vissza. ${url:...}.

Tehát bár ez nem egészen kódbefecskendezés, mert ez csak nyers HTML, mégis azt jelenti, hogy mindenféle szemetet és furcsa és csodálatos megbízhatatlan dolgokat rakhatsz az emberek naplófájljaiba vagy weboldalaikra.

Van ${dns:...}, ami azt jelenti, hogy becsaphatja valakinek a szerverét, amely lehet egy üzleti logikai szerver a hálózaton belül…

…becsaphatja, hogy DNS-keresést végezzen egy elnevezett szerverre.

És ha az Ön tulajdonában van ez a tartomány, mint csaló, akkor az adott tartományhoz kapcsolódó DNS-kiszolgálót is Ön birtokolja és üzemelteti.

Szóval, ha a DNS-keresés megtörténik, mit gondol?

Ez a keresés véget ér *a szerverén*, és segíthet feltérképezni valakinek az üzleti hálózatának belsejét… nem csak a webszerverét, hanem a hálózat mélyén található dolgokat is.

És végül, és ami a legaggasztóbb, legalábbis a Java régebbi verzióinál volt… [NEvet], tudod, mi jön ide, Doug!

A parancs ${script:...}.

"Hé, hadd biztosítsam neked egy kis JavaScriptet, és kérlek, hogy futtasd le nekem."

És valószínűleg azt gondolod: „Mi?! Várjon, ez egy Java hiba. Mi köze a JavaScript-hez?"

Nos, egészen a közelmúltig… és ne feledjük, sok vállalkozás még mindig a Java Development Kit régebbi, még mindig támogatott verzióit használja.

Egészen a közelmúltig a Java… [NEVETÉS] (ismét nem szabad nevetnem)… a Java Development Kit magában foglalt egy teljes, működő JavaScript motort, Java nyelven írva.

A Java és a JavaScript között nincs kapcsolat, kivéve a négy „Java” betűt, de megteheti ${script:javascript:...}és futtassa a választott kódot.

És bosszantó módon az egyik dolog, amit megtehet a JavaScript motorban a Java futtatókörnyezeten belül, az az, hogy azt mondja a JavaScript motornak: „Hé, ezt a dolgot Java-n keresztül akarom futtatni.”

Így elérheti, hogy a Java meghívja *in* JavaScriptet, a JavaScript pedig lényegében *out* a Java-ba.

Ezután a Java-ból kiléphet a „Hé, futtassa ezt a rendszerparancsot”.

És ha megnézi a Naked Security cikket, látni fogja, hogy egy gyanúsított parancsot használok, hogy [KÖHÖHÖG BOCSÁNATBAN], Doug!

Természetesen egy HP RPN számológép, mert én csinálom a számológépet…

---

DOUG.  Ennek kell lennie, igen!

---

KACSA.  …ez egy HP-10.

Tehát bár a kockázat nem olyan nagyszerű, mint a Log4Shell, nem igazán zárhatja ki, ha ezt a könyvtárat használja.

A Naked Security cikkben található néhány útmutatás arról, hogyan tudhatja meg, hogy rendelkezik-e Commons szövegkönyvtárral… és előfordulhat, hogy – ahogyan azt sokan a Log4J esetében tették – anélkül, hogy észrevenné, mert lehet, hogy egy alkalmazással együtt érkezik.

Ezenkívül van néhány mintakódunk is, amellyel tesztelheti, hogy az Ön által bevezetett mérséklések beváltak-e.

---

DOUG.  Rendben, irány a Naked Security.

Ennek a cikknek a neve: Veszélyes lyuk az Apache Commons szövegben – mint a Log4Shell újra.

És egy kérdéssel zárjuk: "Mi történik, ha a titkosított üzenetek csak úgy vannak titkosítva?"

---

KACSA.  Ah, arra gondolsz, ami egy hivatalos hibajelentés volt, amelyet a finn WithSecure cég kiberbiztonsági kutatói nyújtottak be nemrég…

…a Microsoft Office beépített titkosításáról, pontosabban az Office 365 Message Encryption vagy OME nevű szolgáltatásról.

Nagyon praktikus, ha egy ilyen kis funkció be van építve az alkalmazásba.

---

DOUG.  Igen, egyszerűen és kényelmesen hangzik!

---

KACSA.  Igen, kivéve… ó, drágám!

Úgy tűnik, ennek az oka a visszafelé kompatibilitás, Doug…

…hogy a Microsoft azt szeretné, ha ez a funkció egészen azoknál az embereknél működne, akik még mindig az Office 2010-et használják, amely meglehetősen régi iskolai visszafejtési képességekkel rendelkezik.

Alapvetően úgy tűnik, hogy ez az OME-folyamat a fájl titkosítására AES-t használ, amely a legújabb és legjobb NIST szabványos titkosítási algoritmus.

De az AES-t rossz, úgynevezett titkosítási módban használja.

Az úgynevezett EKB-t, ill elektronikus kódkönyv mód.

És egyszerűen így utal a nyers AES-re.

Az AES egyszerre 16 bájtot titkosít… egyébként 16 bájtot titkosít, függetlenül attól, hogy AES-128-at, AES-192-t vagy AES-256-ot használsz.

Ne keverje össze a blokkméretet és a kulcsméretet – a blokkméret, a kriptográfiai motor forgattyúkarjának minden egyes elfordításakor összetört és titkosított bájtok száma mindig 128 bis vagy 16 bájt.

Mindenesetre elektronikus kódkönyv módban egyszerűen vesz 16 bájt bemenetet, egyszer megfordítja a forgattyúkart egy adott titkosítási kulcs alatt, és kiveszi a kimenetet, nyersen és feldolgozatlanul.

És ezzel az a probléma, hogy minden alkalommal, amikor ugyanazt a bemenetet kapja egy dokumentumban, ugyanarra a 16 bájtos határra igazítva…

…pontosan ugyanazokat az adatokat kapja a kimenetben.

Tehát a bemeneti minták megjelennek a kimenetben, ugyanúgy, mint az a Caesar rejtjel vagy a Vigenère rejtjel:

Nos, ez nem jelenti azt, hogy feltörheti a titkosítást, mert még mindig 128 bit széles darabokkal van dolgunk.

Az elektronikus kódkönyv mód problémája éppen azért merül fel, mert mintákat szivárogtat a nyílt szövegből a titkosított szövegbe.

Az ismert egyszerű szöveges támadások akkor lehetségesek, ha tudja, hogy egy adott bemeneti karakterlánc bizonyos módon titkosít, és a dokumentumban szereplő ismétlődő szövegek (például fejléc vagy cégnév) esetén ezek a minták tükröződnek.

És bár ezt hibaként jelentették a Microsoftnak, úgy tűnik, a cég úgy döntött, hogy nem fogja kijavítani, mert „nem felel meg a biztonsági javítás követelményeinek”.

És úgy tűnik, az ok: „Nos, rossz szolgálatot tennénk azoknak, akik még mindig az Office 2010-et használják.”

---

DOUG.  Hoppá!

---

KACSA.  Igen!

---

DOUG.  És ennek jegyében van egy olvasói megjegyzésünk erre a hétre ehhez a történethez.

A meztelen biztonsági olvasó Bill megjegyzései részben:

Erről a „bölcsőkre” jutnak eszembe, amelyeket a Bletchley Park kódtörői használtak a második világháború alatt. A nácik gyakran ugyanazzal a zárómondattal fejezték be az üzeneteket, és így a kódtörők vissza tudtak dolgozni ebből a titkosított karakterkészletből, tudva, hogy valószínűleg mit jelentenek. Kiábrándító, hogy 80 évvel később, úgy tűnik, ugyanazokat a hibákat ismételjük.

---

KACSA.  80 év!

Igen, ez valóban csalódás.

Úgy tudom, hogy más kiságyak, amelyeket a szövetséges kódtörők használhattak, különösen a náci titkosítású szövegeknél, szintén foglalkoztak a dokumentum *elejével.

Azt hiszem, ez a német időjárás-jelentésekre vonatkozott… volt egy vallási formátum, amit követtek, hogy megbizonyosodjanak arról, hogy pontosan adják meg az időjárás-jelentést.

És az időjárás-jelentések, amint elképzelhető, egy éjszakai légibombázással járó háború alatt nagyon fontos dolgok voltak!

Úgy tűnik, hogy ezek egy nagyon-nagyon szigorú mintát követtek, amelyet alkalmanként egy kriptográfiai „lazítónak” vagy egy éknek is lehetne használni, amellyel először is betörhettek.

És ez, amint Bill rámutat… pontosan ezért az AES, vagy bármilyen titkosítás elektronikus kódkönyv módban nem kielégítő a teljes dokumentumok titkosításához!

---

DOUG.  Rendben, köszönöm, hogy elküldted, Bill.

Ha van egy érdekes története, megjegyzése vagy kérdése, amelyet fel szeretne tenni, azt szívesen olvassuk a podcastban.

Írhat e-mailt a tips@sophos.com címre, kommentálhatja bármelyik cikkünket, vagy megkereshet minket a közösségi oldalon: @nakedsecurity.

Ez a mai műsorunk; köszönöm szépen, hogy meghallgattál.

Paul Ducklin számára Doug Aamoth vagyok, és emlékeztetem Önt a következő alkalomig, hogy…

---

MINDKÉT.  Maradjon biztonságban!