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.

Of course, if you include the password in the body of the email, you’ve gained nothing, but if you’re even slightly cautious about sharing the password via a different channel, you’ve bought yourself some extra safety and security against rogues, snoops and ne’er-do-wells getting easy access to confidential content.

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, which scramble largeish chunks of data at a time, rather than processing individual bits or bytes in sequence.

Á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 – AES encryption keys can be 128 bits, 192 bits or 256 bits long, depending on how unlikely you want them to be to guess, but all three key sizes work on 128 bit blocks each time the algorithm is “cranked”.)

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, because it’s sort of like having an enormous code book that could be used as a lookup table for encrypting and decrypting.

(A full “codebook” could never be constructed in real life, because you’d need to store a database consisting of 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.

Likewise, text documents that contain lots of boilerplate, such as headers and footers on every page, or repeated mention of the full company name, will contain plentiful repeats.

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.

So, even if you can’t fornmally decrypt the ciphertext file, you may be able to make immediate, security-crushing inferences from it, thanks to the fact that patterns in the input (which you may know, or be able to infer, or to guess) are preserved in the output.

Í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.

Remember that you don’t need the key to “decrypt” the first document if you already have it in decrypted form – this is known, unsurprisingly, as a ismert szöveges támadás.

Even if there are only a few matches of apparently innocent text that isn’t itself secret data, the knowledge an adversary can extract this way can be a gold-mine for intellectual property spies, social engineers, forensic investigators, and more.

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, if you are keen on focusing on the stuff that’s clearly meant to be “more secret” than the rest.

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), or cryptographic checksum, at the same time as scrambling or unscrambling the data.

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 MAC that is calculated during the decryption process, based on the same key and IV, will help ensure that you know that the ciphertext you received is valid, and therefore that you have almost certainly decrypted what was originally put in at the other end.

Alternatively, use a dedicated folyam titkosítás that produces a pseudo-random byte-by-byte keystream that allows you to encrypt data without having to process 16 bytes (or whatever the block size might be) at a time.

AES-GCM essentially converts AES into a stream cipher and adds authentication in the form of a MAC, but if you’re looking for a dedicated stream cipher designed specifically to work that way, we suggest Daniel Bernstein’s ChaCha20-Poly1305 (a Poly1305 rész a MAC), amint azt részletezi RFC 8439.

Below, we’ve shown what we got using AES-128-GCM and ChaCha20-Poly1305 (we discarded the MAC codes here), along with an “image” consisting 95,040 RGBA bytes (330×72 at 4 bytes per pixel) from the Linux kernel pseudo-random generator.

Remember that just because data looks unstructured doesn’t mean that it is truly random, but if it doesn’t look random, yet it claims to be encrypted, you might as well assume that there’s some structure left behind, and that the encryption is suspect:

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.

---

HOW WE MADE THE IMAGES IN THE ARTICLE 

Start with sop330.png, which you can create for 
yourself by cropping the cleaned-up SOPHOS logo 
from the topmost image, removing the 2-pixel 
blue boundary, and saving in PNG format.  A képnek 330x72 pixelesnek kell lennie.
 Convert to RGBA using ImageMagick:

$ convert sop330.png sop.rgba  

Output is 330x72 pixels x 4 bytes/pixel = 95,040 bytes.
 ===

Encrypt using Lua and the LuaOSSL library (Python has a very 
similar OpenSSL binding):

-- load data
> fdat = misc.filetostr('sop.rgba')
> fdat:len()
95040

-- create cipher objects
> aes = openssl.cipher.new('AES-128-ECB')
> gcm = openssl.cipher.new('AES-128-GCM')
> cha = openssl.cipher.new('ChaCha20-Poly1305')

-- initialise passwords and IVs
-- AES-128-ECB needs a 128-bit password, but no IV
-- AES-128-GCM needs a 128-bit password and a 12-byte IV
-- ChaCha20 needs a 256-bit password and a 12-byte IV
> aes:encrypt('THEPASSWORDIS123')
> gcm:encrypt('THEPASSWORDIS123','andkrokeutiv')
> cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g')

-- encrypt the file data with the three ciphers
> aesout = aes:final(fdat)
> gcmout = gcm:final(fdat)
> chaout = cha:final(fdat)

-- a stream cipher produces output byte-by-byte,
-- so ciphertext should be same length as plaintext
> gcmout:len()
95040
> chaout:len()
95040

-- we won't be using the MAC codes from GCM and Poly1305 here,
-- but each cipher produces a 128-bit (16-byte) "checksum"
-- used to authenticate the decryption after it's finished,
-- to detect if the input ciphertext gets corrupted or hacked
-- (the MAC depends on the key, so an attacker can't forge it)
> base.hex(gcm:getTag(16))
a70f204605cd5bd18c9e4da36cbc9e74
> base.hex(cha:getTag(16))
a55b97d5e9f3cb9a3be2fa4f040b56ef

-- create a 95040 "image" straight from /dev/random
> rndout = misc.filetostr('/dev/random',#fdat)

-- save them all - note that we explicity truncate the AES-ECB
-- block cipher output to the exact image length required, because
-- ECB needs padding to match the input size with the block size
> misc.strtofile(aesout:sub(1,#fdat),'aes.rgba')
> misc.strtofile(gcmout,'gcm.rgba')
> misc.strtofile(chaout,'cha.rgba')
> misc.strtofile(rndout,'rnd.rgba')

===

To load the files in a regular image viewer, you may 
need to convert them losslessly back into PNG format:

$ convert -depth 8 -size 330x72 aes.rgba aes.png
$ convert -depth 8 -size 330x72 gcm.rgba gcm.png
$ convert -depth 8 -size 330x72 cha.rgba cha.png
$ convert -depth 8 -size 330x72 rnd.rgba rnd.png

===

Given that the encryption process scrambles all four 
bytes in each RGBA pixel, the resulting image has 
variable transparency (A = alpha, short for tranparency).
 Your image viewer may decide to display this sort of
image with a checkerboard background, which confusingly 
looks like part of the image, but isn't.  We therefore
used the Sophos blue from the original image as a 
background for the encrypted files to make them easier
to view.  The overall blue hue is therefore not part of 
the image data.