Komoly biztonság: A Microsoft Office 365-öt gyenge titkosítás miatt támadták meg

Jelenleg nem tudjuk pontosan, hogyan nevezzük, ezért a címben a hibrid néven hivatkoztunk rá Microsoft Office 365.

(Az „Office” név a Microsoft szövegszerkesztő, táblázatkezelő, prezentációs és együttműködési alkalmazásai gyűjtőneve. megölték a következő egy-két hónapban, hogy egyszerűen „Microsoft 365” legyen.)

Biztosak vagyunk benne, hogy az emberek továbbra is az egyes alkalmazások neveit fogják használni (szó, Excel, PowerPoint és a barátok) és a lakosztály beceneve Office sok éven át, bár a szoftver újoncai valószínűleg így fogják tudni 365, miután eldobta a mindenütt előforduló Microsoft előtagot.

Amint azt bizonyára tudja, az Office önálló alkalmazásai (amelyeket valójában helyben telepít, így nem kell az internetre kapcsolódnia ahhoz, hogy dolgozzon a dolgain) saját lehetőségük van a mentett dokumentumok titkosítására.

Ez egy extra biztonsági réteget jelent arra az esetre, ha később véletlenül vagy tervszerűen megosztaná ezeket a fájlokat valakivel, akinek nem kellett volna megkapnia azokat – ez meglepően könnyen megtehető véletlenül, ha e-mailben oszt meg mellékleteket.

Hacsak és amíg meg nem adja a címzettnek a fájl zárolásának feloldásához szükséges jelszót, ez csak annyi aprított káposzta a számukra.

Természetesen, ha megadja a jelszót az e-mail törzsében, akkor semmit nem nyer, de ha csak egy kicsit is óvatos a jelszó másik csatornán keresztüli megosztásával, akkor extra biztonságot vásárolt magának a szélhámosokkal szemben. , leskelődők és nemtörődömök, akik könnyen hozzáférhetnek a bizalmas tartalomhoz.

OME a reflektorfényben

Vagy van?

Szerint kutatók a finn kiberbiztonsági vállalatnál, a WithSecure-nál az Ön adatai sokkal kevesebb védelmet élvezhetnek, mint amit ésszerűen elvárhat.

A tesztelők által használt funkciót úgy emlegetik Office 365 üzenettitkosításvagy OME röviden.

Nem reprodukáltuk itt a kísérleteiket, azon egyszerű oknál fogva, hogy az Office alaptermékei, sajnálom, nem futnak natívan Linuxon, amit a munkához használunk. Az Office-eszközök webalapú verziói nem rendelkeznek ugyanazzal a funkciókészlettel, mint a teljes alkalmazások, így az általunk elért eredmények valószínűleg nem fognak összhangban lenni azzal, ahogy az Office legtöbb üzleti felhasználója, ah, 365 konfigurálta a Word, Excel, Outlook alkalmazásokat. és barátai Windows laptopjukon.

Ahogy a kutatók leírják:

Ezt a funkciót azért hirdetik, hogy a szervezetek biztonságos módon küldhessenek és fogadhassanak titkosított e-mail üzeneteket a szervezeten belüli és kívüli személyek között.

De arra is felhívják a figyelmet, hogy:

Sajnos az OME üzenetek nem biztonságos elektronikus kódkönyv (ECB) üzemmódban vannak titkosítva.

Az EKB kifejtette

Megmagyarázni.

Számos titkosítási algoritmus, különösen a Advanced Encryption Standard vagy AES, amelyet az OME használ, az úgynevezett blokk titkosítások, amelyek egyszerre nagyobb adatdarabokat kevernek össze, ahelyett, hogy az egyes biteket vagy bájtokat egymás után dolgoznák fel.

Általánosságban elmondható, hogy ez mind a hatékonyságot, mind a biztonságot szolgálja, mivel a titkosításnak több bemeneti adata van a keveréshez, aprításhoz és folyékonysághoz az algoritmust hajtó kriptográfiai forgattyúkar minden egyes fordulatánál, és minden fordulattal tovább visz. a titkosítani kívánt adatokon keresztül.

Az alapvető AES-algoritmus például egyszerre 16 bemeneti egyszerű szöveg bájtot (128 bitet) fogyaszt, és ezeket az adatokat titkosítási kulcs alatt összekeveri, hogy 16 titkosított rejtjelezett szöveg kimeneti bájtot állítson elő.

(Ne keverje össze blokk méret val vel kulcs mérete – Az AES titkosítási kulcsok 128 bitesek, 192 bitesek vagy 256 bitesek lehetnek, attól függően, hogy mennyire valószínűtlen, hogy kitalálják, de mindhárom kulcsméret 128 bites blokkon működik minden alkalommal, amikor az algoritmust „forgatják”.)

Ez azt jelenti, hogy ha kiválaszt egy AES-kulcsot (hosszúságtól függetlenül), majd az AES-rejtjelet közvetlenül egy adattömbön használja…

…akkor minden alkalommal, amikor ugyanazt a bemeneti darabot kapja, ugyanazt a kimeneti darabot kapja.

Mint egy igazán masszív kódkönyv

Ezért hívják ezt a közvetlen működési módot EKB, röviden elektronikus kódkönyv, mert ez olyan, mintha egy hatalmas kódkönyv lenne, amelyet keresőtáblaként lehetne használni a titkosításhoz és a visszafejtéshez.

(Teljes „kódkönyvet” soha nem lehet a való életben létrehozni, mert tárolnia kell egy adatbázist, amely 2¹²⁸ 16 bájtos bejegyzések minden lehetséges kulcshoz.)

Sajnos, különösen a számítógéppel formázott adatok esetében, bizonyos adattömbök ismétlődése gyakran elkerülhetetlen a használt fájlformátumnak köszönhetően.

Például az olyan fájlok, amelyek rutinszerűen kitömik az adatszakaszokat, hogy 512 bájtos határokon (gyakori szektorméret lemezre íráskor) vagy 4096 bájtos határokon (memóriafoglaláskor gyakori kiosztási egység mérete) illeszkedjenek, gyakran olyan fájlokat állítanak elő, amelyek nulla bájt hosszú lefutása.

Hasonlóképpen, az olyan szöveges dokumentumok is, amelyek sok sablont tartalmaznak, például fejléceket és láblécet minden oldalon, vagy a teljes cégnév ismételt említését, sok ismétlést tartalmaznak.

Minden alkalommal, amikor az AES-ECB titkosítási folyamatban egy ismétlődő egyszerű szöveges darab véletlenül sorakozik egy 16 bájtos határon, ezért megjelenik a titkosított kimenetben. mint pontosan ugyanaz a rejtjelezett szöveg.

Tehát még akkor is, ha formálisan nem tudja visszafejteni a titkosított szövegfájlt, azonnali, biztonságot romboló következtetéseket vonhat le belőle, köszönhetően annak, hogy a bemeneti minták (amelyeket ismerhet, vagy ki tud következtetni, vagy kitalálni) megmaradnak a kimenetben.

Íme egy példa egy közel kilenc évvel ezelőtt közzétett cikkünkön, amelyben elmagyaráztuk, hogy miért volt az Adobe most hírhedten használt EKB-módú titkosítása a felhasználói jelszavak „kivonatára” Nem jó ötlet:

Figyelje meg, hogy a bemenetben egyszínű fehér képpontok megbízhatóan ismétlődő mintát hoznak létre a kimenetben, és a kék részek kissé szabályosak maradnak, így az eredeti adatok szerkezete nyilvánvaló.

Ebben a példában az eredeti fájl minden képpontja pontosan 4 bájtot foglal el, így a bemeneti adatokban minden balról jobbra haladó 4 pixel 16 bájt hosszúságú, ami pontosan igazodik minden 16 bájtos AES titkosítási blokkhoz, így kiemelve az „EKB-hatás”.

---

Egyező titkosított szöveg minták

Még rosszabb, ha két olyan dokumentuma van, amelyekről tudja, hogy ugyanazzal a kulccsal vannak titkosítva, és véletlenül az egyiknek a szövege van, akkor átnézheti a titkosított szöveget, amelyet nem tud dekódolja, és próbálja meg egyesíteni a részeit a titkosított szöveg mintáival tud visszafejteni.

Ne feledje, hogy nincs szüksége kulcsra az első dokumentum „visszafejtéséhez”, ha már megvan a visszafejtett formában – ez nem meglepő módon ismert szöveges támadás.

Még akkor is, ha csak néhány olyan ártatlan szöveg található, amely önmagában nem titkos adat, az ellenfél ily módon kinyerhető tudása aranybánya lehet a szellemi tulajdonnal foglalkozó kémek, társadalommérnökök, törvényszéki nyomozók és egyebek számára.

Például még akkor is, ha fogalma sincs, mire utalnak egy dokumentum részletei, ha több fájl ismert egyszerű szöveges darabjait egyezteti, akkor is megállapíthatja, hogy egy látszólag véletlenszerű dokumentumgyűjtemény:

• Mindegyiket ugyanannak a címzettnek küldték, ha mindegyik tetején van egy közös köszöntés.
• Ugyanerre a projektre hivatkozva, ha van egy egyedi azonosító szöveg, amely folyamatosan felbukkan.
• azonos biztonsági besorolással rendelkezik, ha arra vágyik, hogy azokra a dolgokra összpontosítson, amelyek egyértelműen „titkosabbak”, mint a többi.

Mit kell tenni?

Ne használja az EKB módot!

Ha blokk titkosítást használ, válassza ki a blokk titkosítás üzemmód hogy:

• Tartalmazza az úgynevezett IV-t vagy inicializálási vektort, véletlenszerűen és egyedileg választva minden üzenethez.
• Szándékosan megszervezi a titkosítási folyamatot így az ismételt bemenetek minden alkalommal másként jönnek ki.

Ha AES-t használ, akkor manapság valószínűleg ezt a módot szeretné választani AES-GCM (Galois Counter Mode), amely nemcsak IV-t használ, hogy minden alkalommal más titkosítási adatfolyamot hozzon létre, még akkor is, ha a kulcs ugyanaz marad, hanem kiszámítja az úgynevezett Üzenet hitelesítési kód (MAC), vagy kriptográfiai ellenőrző összeget, az adatok titkosításával vagy feloldásával egyidejűleg.

Az AES-GCM nemcsak azt jelenti, hogy kerüli az ismétlődő rejtjeles szövegmintákat, hanem azt is, hogy mindig egy „ellenőrző összeg”-hez jut, amely jelzi, ha az imént dekódolt adatokat manipulálták az út során.

Ne feledje, hogy egy szélhámos, aki nem tudja, mit jelent valójában a rejtjelezett szöveg, ennek ellenére képes rávenni Önt, hogy megbízzon egy pontatlan visszafejtésben anélkül, hogy tudná (vagy törődne), hogy milyen hibás kimenetet kap.

A visszafejtési folyamat során, ugyanazon kulcs és IV alapján kiszámított MAC segít abban, hogy tudja, hogy a kapott rejtjelezett szöveg érvényes, és ezért szinte biztosan visszafejtette azt, amit a másik végén eredetileg betettek.

Alternatív megoldásként használjon dedikált folyam titkosítás amely egy pszeudo-véletlen byte-byte kulcsfolyamot hoz létre, amely lehetővé teszi az adatok titkosítását anélkül, hogy egyszerre 16 bájtot (vagy bármilyen blokkméretet) kellene feldolgoznia.

Az AES-GCM lényegében az AES-t folyamtitkosítóvá alakítja, és hitelesítést ad hozzá MAC formájában, de ha kifejezetten erre a célra tervezett adatfolyam-rejtjelet keres, javasoljuk, hogy Daniel Bernstein ChaCha20-Poly1305 (a Poly1305 rész a MAC), amint azt részletezi RFC 8439.

Az alábbiakban bemutatjuk, mit kaptunk az AES-128-GCM és a ChaCha20-Poly1305 használatával (itt elvetettük a MAC kódokat), valamint egy 95,040 330 RGBA bájtból (72 × 4, XNUMX bájt/pixel) álló „kép” Linux kernel pszeudo-véletlen generátor.

Ne feledje, hogy csak azért, mert az adatok strukturálatlannak tűnnek, nem jelenti azt, hogy valóban véletlenszerűek, de ha nem véletlenszerűnek tűnnek, mégis azt állítják, hogy titkosítva vannak, akkor azt is feltételezheti, hogy valami struktúra maradt mögötte, és a titkosítás gyanúsított:

Mi történik ezután?

A WithSecure szerint, a Microsoft nem tervezi kijavítani ezt a "sérülékenységet", nyilvánvalóan az Office 2010-el való visszamenőleges kompatibilitás miatt…

Az Office régebbi verzióihoz (2010) az AES 128 ECB szükséges, és az Office-dokumentumokat továbbra is ilyen módon védik az Office-alkalmazások.

…és…

A [WithSecure-kutatók] jelentését nem tekintették megfelelõnek a biztonsági szolgáltatásokra vonatkozó követelményeknek, és nem tekintik megsértésnek. Nem történt kódmódosítás, így ehhez a jelentéshez nem adtak ki CVE-t.

Röviden, ha jelenleg az OME-ra támaszkodik, érdemes lehet egy harmadik féltől származó titkosítóeszközre cserélni az érzékeny üzenetekhez, amely az üzeneteket létrehozó alkalmazásoktól függetlenül titkosítja az Ön adatait, és így a belső titkosítástól függetlenül működik. kód az Office tartományban.

Így választhat egy modern rejtjelezést és egy modern rejtjelezési módot anélkül, hogy vissza kellene térnie az Office 2010-be épített régi iskola dekódoló kódhoz.

---

HOGYAN KÉSZÜLTÜK A CIKKBAN A KÉPEKET Kezdje a sop330.png-vel, amelyet saját magának készíthet úgy, hogy a legfelső képről levágja a megtisztított SOPHOS logót, eltávolítja a 2 pixeles kék határvonalat, és elmenti PNG formátumba.  A képnek 330x72 pixelesnek kell lennie.
 Konvertálás RGBA-ra az ImageMagick segítségével: $ convert sop330.png sop.rgba A kimenet 330x72 pixel x 4 bájt/pixel = 95,040 XNUMX bájt.
 === Titkosítás a Lua és a LuaOSSL könyvtár használatával (a Pythonnak nagyon hasonló OpenSSL-kötése van): -- adatok betöltése > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- titkosítási objektumok létrehozása > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- jelszavak és IV-ek inicializálása -- Az AES-128-ECB-nek 128 bites jelszóra van szüksége, de nem egy 128 bájtos IV > aes:encrypt('THEPASSWORDIS128') > gcm:encrypt('THEPASSWORDIS12','andkrokeutiv') > cha:encrypt('THEPASSWORDIS20THEPASSWORDIS256','qlxmtosh12g') adatok a threecici fájl titkosításával > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- a stream titkosítás byte-onként állítja elő a kimenetet, -- tehát a titkosított szövegnek ugyanolyan hosszúnak kell lennie, mint a sima szövegnek > gcmout:len() 123 > chaout:len() 123 -- itt nem a GCM és a Poly123 MAC kódjait fogjuk használni, -- de minden titkosítás 123 bites (476 bájtos) "ellenőrző összeget" állít elő - - a visszafejtés hitelesítésére szolgál annak befejezése után, - annak észlelésére, hogy a bemeneti titkosított szöveg megsérül vagy feltörik - (a MAC a kulcstól függ, így a támadó nem tudja meghamisítani) > base.hex(gcm:getTag( 95040)) a95040f1305cd128bd16c16e70da204605cbc5e18 > base.hex(cha:getTag(9)) a4b36d9e74f16cb55a97be5fa9f3b9ef -- hozzon létre egy 3 "image = image" címet a következőből: r,/ndevet/rando misstrom fdat) -- mentse el az összeset - vegye figyelembe, hogy kifejezetten csonkoljuk az AES-ECB - blokk titkosítás kimenetét a pontos képhosszra, mert - az ECB-nek kitöltésre van szüksége, hogy a bemeneti méret megfeleljen a blokk méretének > misc.strtofile(aesout:sub(2) ,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha.rgba') > misc.strtofile(rndout,'rnd.rgba') === A fájlok normál képnézegetőbe való betöltéséhez veszteségmentesen vissza kell konvertálnia őket PNG formátumba: $ convert -depth 4 -size 040x56 aes.rgba aes.png $ convert -depth 95040 -size 1x8 gcm.rgba gcm.png $ convert -depth 330 -size 72x8 cha.rgba cha.png $ convert -depth 330 -size 72x8 rnd.rgba rnd.png === Tekintettel arra, hogy a titkosítási folyamat mind a négy bájtot kódolja minden RGBA pixelben, az eredmény a kép változó átlátszóságú (A = alfa, az átlátszóság rövidítése).
 Előfordulhat, hogy a képnézegető úgy dönt, hogy ezt a fajta képet sakktábla háttérrel jeleníti meg, ami megtévesztő módon a kép részének tűnik, de nem az.  Ezért a titkosított fájlok háttereként az eredeti kép Sophos kékjét használtuk, hogy megkönnyítsük a megtekintésüket.  Az általános kék árnyalat ezért nem része a képadatoknak.