Resna varnost: Microsoft Office 365 napaden zaradi šibkega šifriranja PlatoBlockchain Data Intelligence. Navpično iskanje. Ai.

Resna varnost: Microsoft Office 365 napaden zaradi šibkega šifriranja

Trenutno nismo povsem prepričani, kako bi ga poimenovali, zato smo ga v naslovu navedli s hibridnim imenom Microsoft Office 365.

(Ime »Office« kot skupni samostalnik za Microsoftove aplikacije za obdelavo besedil, preglednice, predstavitve in sodelovanje ubil v naslednjem mesecu ali dveh postati preprosto »Microsoft 365«.)

Prepričani smo, da bodo ljudje še naprej uporabljali imena posameznih aplikacij (beseda, Excel, PowerPoint in prijatelji) in vzdevek apartmaja Office več let, čeprav jo bodo novinci v programski opremi verjetno na koncu poznali kot 365, potem ko smo opustili vseprisotno Microsoftovo predpono.

Kot morda veste, Officeove samostojne aplikacije (tiste, ki jih dejansko namestite lokalno, tako da vam ni treba iti v splet, da bi delali na svojih stvareh) vključujejo lastno možnost šifriranja shranjenih dokumentov.

To naj bi dodalo dodatno raven varnosti v primeru, da boste katero od teh datotek kasneje delili, po naključju ali namerno, z nekom, ki jih ne bi smel prejeti – nekaj, kar je presenetljivo enostavno storiti po pomoti, ko delite priloge po e-pošti.

Razen če in dokler prejemniku ne daste tudi gesla, ki ga potrebuje za odklepanje datoteke, je to zanj le toliko strganega zelja.

Seveda, če geslo vključite v telo e-poštnega sporočila, ne pridobite ničesar, a če ste vsaj malo previdni pri delitvi gesla prek drugega kanala, ste si zagotovili nekaj dodatne varnosti in zaščite pred prevaranti , vohljalci in nevšečniki, ki dobijo enostaven dostop do zaupne vsebine.

OME pod žarometi

Ali pa ste?

Glede na raziskovalci pri finskem podjetju za kibernetsko varnost WithSecure bi lahko vaši podatki uživali veliko manj zaščite, kot bi razumno pričakovali.

Funkcijo, ki so jo uporabili preizkuševalci, imenujejo Šifriranje sporočil Office 365ali OME na kratko.

Tukaj nismo reproducirali njihovih poskusov iz preprostega razloga, ker osnovni izdelki Office, oprostite, 365 ne delujejo izvorno v sistemu Linux, ki ga uporabljamo za delo. Spletne različice Officeovih orodij nimajo enakega nabora funkcij kot polne aplikacije, zato rezultati, ki jih lahko dobimo, verjetno ne bodo usklajeni s tem, kako je večina poslovnih uporabnikov Officea, ah, 365 konfigurirala Word, Excel, Outlook in prijatelji na svojih prenosnikih Windows.

Kot opisujejo raziskovalci:

Ta funkcija se oglašuje, da bi organizacijam omogočila varno pošiljanje in prejemanje šifriranih e-poštnih sporočil med osebami znotraj in zunaj vaše organizacije.

Poudarjajo pa tudi, da:

Na žalost so sporočila OME šifrirana v nevarnem načinu delovanja elektronskega šifranta (ECB).

pojasnila ECB

Razložiti.

Številni šifrirni algoritmi, zlasti Advanced Encryption Standard ali AES, ki jih uporablja OME, so znani kot blokovne šifre, ki premešajo velike kose podatkov naenkrat, namesto da bi obdelovali posamezne bite ali bajte v zaporedju.

Na splošno naj bi to pripomoglo k učinkovitosti in varnosti, saj ima šifra več vhodnih podatkov za mešanje-zmletje-razdrobitev-in-utekočinjenje ob vsakem obratu kriptografske ročice, ki poganja algoritem, in vsak obrat vas pripelje dlje prek podatkov, ki jih želite šifrirati.

Osnovni algoritem AES na primer porabi 16 vhodnih bajtov golega besedila (128 bitov) naenkrat in te podatke premeša pod šifrirnim ključem, da proizvede 16 šifriranih izhodnih bajtov šifriranega besedila.

(Ne zamenjujte velikost bloka z velikost ključa – Šifrirni ključi AES so lahko dolgi 128 bitov, 192 bitov ali 256 bitov, odvisno od tega, kako malo verjetno želite, da bi uganili, vendar vse tri velikosti ključev delujejo na 128-bitnih blokih vsakič, ko se algoritem »zažene«.)

To pomeni, da če izberete ključ AES (ne glede na dolžino) in nato uporabite šifro AES neposredno na delu podatkov ...

... potem vsakič, ko dobite isti vhodni del, boste dobili enak izhodni del.

Kot resnično ogromen šifrant

Zato se ta neposredni način delovanja imenuje ECB, kratek za elektronski šifrant, ker je nekako tako, kot da bi imeli ogromno kodno knjigo, ki bi jo lahko uporabili kot iskalno tabelo za šifriranje in dešifriranje.

(Popolnega »šifarnika« v resničnem življenju nikoli ne bi bilo mogoče sestaviti, ker bi morali shraniti bazo podatkov, sestavljeno iz 2128 16-bajtni vnosi za vsak možni ključ.)

Na žalost je zaradi uporabljenega formata datoteke ponavljanje določenih delov podatkov pogosto neizogibno, zlasti pri računalniško oblikovanih podatkih.

Na primer, datoteke, ki rutinsko zapolnijo podatkovne odseke, tako da se poravnajo na 512-bajtnih mejah (običajna velikost sektorja pri pisanju na disk) ali na 4096-bajtnih mejah (običajna velikost dodelitvene enote pri rezerviranju pomnilnika), bodo pogosto ustvarile datoteke z dolgi nizi nič bajtov.

Podobno bodo besedilni dokumenti, ki vsebujejo veliko šablon, kot so glave in noge na vsaki strani, ali večkratna omemba polnega imena podjetja, vsebovali veliko ponovitev.

Vsakič, ko se ponovljeni kos odprtega besedila le slučajno poravna na 16-bajtni meji v procesu šifriranja AES-ECB, se bo pojavil v šifriranem izhodu kot popolnoma enako šifrirano besedilo.

Torej, tudi če ne morete formalno dešifrirati datoteke s šifriranim besedilom, boste morda lahko iz nje naredili takojšnje sklepe, ki rušijo varnost, zahvaljujoč dejstvu, da vzorci v vnosu (ki jih morda poznate ali lahko sklepate, ali ugibati) se ohranijo v izpisu.

Tu je primer, ki temelji na članku, ki smo ga objavili pred skoraj devetimi leti, ko smo razložili, zakaj je Adobejeva zdaj razvpita uporaba šifriranja v načinu ECB za »zgoščevanje« gesel svojih uporabnikov Ni dobra ideja:

Resna varnost: Microsoft Office 365 napaden zaradi šibkega šifriranja PlatoBlockchain Data Intelligence. Navpično iskanje. Ai.
Levo. Izvirna slika RGBA.
Prav. Slikovni podatki šifrirani z AES-128-ECB.

Upoštevajte, kako slikovne pike, ki so v vhodu popolnoma bele, zanesljivo ustvarijo ponavljajoč se vzorec v izhodu, modri deli pa ostanejo nekoliko pravilni, tako da je struktura izvirnih podatkov očitna.

V tem primeru vsaka slikovna pika v izvirni datoteki zavzema natanko 4 bajte, tako da je vsak potek 4 slikovnih pik v vhodnih podatkih od leve proti desni dolg 16 bajtov, kar je natančno poravnano z vsakim 16-bajtnim šifrirnim blokom AES in tako poudarja »učinek ECB«.


Ujemanje vzorcev šifriranih besedil

Še huje, če imate dva dokumenta, za katera veste, da sta šifrirana z istim ključem, in slučajno imate odprto besedilo enega od njiju, potem lahko pogledate šifrirano besedilo, ki ga ne more dešifrirate in poskusite njegove dele povezati z vzorci v šifriranem besedilu, ki ste ga lahko dešifrirati.

Ne pozabite, da ne potrebujete ključa za »dešifriranje« prvega dokumenta, če ga že imate v dešifrirani obliki – to ni presenetljivo znano kot napad z znanim odprtim besedilom.

Tudi če obstaja le nekaj ujemanj navidezno nedolžnega besedila, ki samo po sebi ni tajni podatek, je lahko znanje, ki ga lahko nasprotnik pridobi na ta način, zlata jama za vohune za intelektualno lastnino, socialne inženirje, forenzične preiskovalce in druge.

Na primer, tudi če nimate pojma, na kaj se nanašajo podrobnosti dokumenta, lahko z ujemanjem znanih kosov odprtega besedila v več datotekah ugotovite, da navidezno naključna zbirka dokumentov:

  • Vse so bile poslane istemu prejemniku, če je na vrhu vsakega skupen pozdrav.
  • Glej isti projekt, če obstaja edinstven identifikacijski besedilni niz, ki se nenehno pojavlja.
  • Imeti enako varnostno klasifikacijo, če se želite osredotočiti na stvari, ki so očitno »bolj tajne« od ostalih.

Kaj storiti?

Ne uporabljajte načina ECB!

Če uporabljate blokovno šifro, izberite a način delovanja blokovne šifre da:

  • Vključuje tisto, kar je znano kot IV ali inicializacijski vektor, izbrani naključno in edinstveno za vsako sporočilo.
  • Namerno ureja postopek šifriranja tako da se ponovljeni vnosi vsakič izkažejo drugače.

Če uporabljate AES, je način, ki ga verjetno želite izbrati v teh dneh AES-GCM (Galois Counter Mode), ki ne uporablja samo IV za vsakokratno ustvarjanje drugačnega toka šifriranih podatkov, tudi če ključ ostane enak, ampak tudi izračuna tisto, kar je znano kot Koda za preverjanje pristnosti sporočila (MAC) ali kriptografsko kontrolno vsoto, hkrati s kodiranjem ali dekodiranjem podatkov.

AES-GCM ne pomeni samo, da se izognete ponavljajočim se vzorcem šifriranega besedila, ampak tudi, da vedno dobite »kontrolno vsoto«, ki vam bo povedala, ali so bili podatki, ki ste jih pravkar dešifrirali, med potjo spremenjeni.

Ne pozabite, da vas lahko prevarant, ki ne ve, kaj šifrirano besedilo dejansko pomeni, kljub temu lahko pretenta, da zaupate nenatančnemu dešifriranju, ne da bi sploh vedel (ali da bi ga skrbelo), kakšen napačen izhod imate na koncu.

MAC, ki se izračuna med postopkom dešifriranja na podlagi istega ključa in IV, vam bo pomagal zagotoviti, da veste, da je šifrirano besedilo, ki ste ga prejeli, veljavno, in torej, da ste skoraj zagotovo dešifrirali tisto, kar je bilo prvotno vstavljeno na drugi strani.

Druga možnost je, da uporabite namensko tokovna šifra ki ustvari psevdo-naključni tok ključev bajt za bajtom, ki vam omogoča šifriranje podatkov, ne da bi morali obdelati 16 bajtov (ali ne glede na velikost bloka) naenkrat.

AES-GCM v bistvu pretvori AES v pretočno šifro in doda avtentikacijo v obliki MAC, a če iščete namensko pretočno šifro, zasnovano posebej za takšno delovanje, predlagamo Daniela Bernsteina ChaCha20-Poly1305 (del Poly1305 je MAC), kot je podrobno opisano v RFC 8439.

Spodaj smo pokazali, kaj smo dobili z uporabo AES-128-GCM in ChaCha20-Poly1305 (tukaj smo zavrgli kode MAC), skupaj s »sliko«, ki vsebuje 95,040 bajtov RGBA (330×72 pri 4 bajtih na slikovno piko) iz Psevdonaključni generator jedra Linuxa.

Zapomnite si, da samo zato, ker so podatki videti nestrukturirani, še ne pomeni, da so resnično naključni, če pa niso videti naključni, vendar trdijo, da so šifrirani, lahko domnevate, da je nekaj strukture ostalo zadaj in da je šifriranje osumljenec:

Kaj sledi?

Glede na WithSecure, Microsoft ne namerava odpraviti te "ranljivosti", očitno zaradi združljivosti s prejšnjimi različicami sistema Office 2010 ...

Podedovane različice Officea (2010) zahtevajo AES 128 ECB in Officeovi dokumenti so še vedno zaščiteni na ta način z Officeovimi aplikacijami.

… In…

Poročilo [raziskovalcev WithSecure] ni veljalo za izpolnjevanje meril za varnostne storitve, niti se ne šteje za kršitev. Koda ni bila spremenjena, zato za to poročilo ni bil izdan CVE.

Skratka, če se trenutno zanašate na OME, boste morda želeli razmisliti o zamenjavi z orodjem za šifriranje občutljivih sporočil tretje osebe, ki šifrira vaše podatke neodvisno od aplikacij, ki so ta sporočila ustvarile, in tako deluje neodvisno od notranjega šifriranja kodo v ponudbi Office.

Tako lahko izberete sodobno šifro in sodoben način delovanja šifre, ne da bi se morali vrniti na kodo za dešifriranje stare šole, vgrajeno v Office 2010.


KAKO SMO IZDELALI SLIKE V ČLANKU Začnite s sop330.png, ki ga lahko ustvarite sami tako, da obrežete očiščen logotip SOPHOS z najvišje slike, odstranite modro mejo z 2 slikovnimi pikami in shranite v formatu PNG.  Slika naj bo na koncu velikosti 330x72 slikovnih pik.
 Pretvorite v RGBA z uporabo ImageMagick: $ convert sop330.png sop.rgba Izhod je 330 x 72 slikovnih pik x 4 bajtov/piksel = 95,040 bajtov.
 === Šifrirajte z Lua in knjižnico LuaOSSL (Python ima zelo podobno vezavo OpenSSL): -- naloži podatke > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- ustvari šifrirane objekte > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- inicializirajte gesla in IV-je -- AES-128-ECB potrebuje 128-bitno geslo, ne pa IV -- AES-128-GCM potrebuje 128-bitno geslo in 12-bajtno IV -- ChaCha20 potrebuje 256-bitno geslo in 12-bajtni IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- šifriranje podatkov datoteke s tremi šiframi > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- pretočna šifra ustvari izhod bajt za bajtom, -- zato mora biti šifrirano besedilo enako dolgo kot navadno besedilo > gcmout:len() 95040 > chaout:len() 95040 -- tukaj ne bomo uporabljali kod MAC iz GCM in Poly1305, -- vendar vsaka šifra ustvari 128-bitno (16-bajtno) "kontrolno vsoto" - - uporablja se za preverjanje pristnosti dešifriranja, ko je končano, -- za odkrivanje, ali se vhodno šifrirano besedilo poškoduje ali vdre -- (MAC je odvisen od ključa, zato ga napadalec ne more ponarediti) > base.hex(gcm:getTag( 16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- ustvarite "sliko" 95040 neposredno iz /dev/random > rndout = misc.filetostr('/dev/random', #fdat) -- shranite jih vse - upoštevajte, da eksplicitno skrajšamo izhod blokovne šifre AES-ECB na točno zahtevano dolžino slike, ker -- ECB potrebuje oblazinjenje, da se velikost vnosa ujema z velikostjo bloka > misc.strtofile(aesout:sub(1 ,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha.rgba') > misc.strtofile(rndout,'rnd.rgba') === Če želite datoteke naložiti v običajen pregledovalnik slik, jih boste morda morali brez izgub pretvoriti nazaj v format PNG: $ 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 === Glede na to, da postopek šifriranja kodira vse štiri bajte v vsaki slikovni piki RGBA, je nastala slika ima spremenljivo prosojnost (A = alfa, okrajšava za prosojnost).
 Vaš pregledovalnik slik se lahko odloči za prikaz te vrste slike z ozadjem šahovnice, ki je videti kot del slike, vendar ni.  Zato smo kot ozadje za šifrirane datoteke uporabili Sophosovo modro iz izvirne slike, da bi jih lažje videli.  Celoten modri odtenek torej ni del slikovnih podatkov. 

Časovni žig:

Več od Gola varnost