Seriøs sikkerhed: Microsoft Office 365 angrebet over svag kryptering

Vi er ikke helt sikre på, hvad vi skal kalde det lige nu, så vi henviste til det i overskriften med hybridnavnet Microsoft Office 365.

(Navnet "Office" som det kollektive navneord for Microsofts tekstbehandlings-, regnearks-, præsentations- og samarbejdsapps bliver dræbt af i løbet af den næste måned eller to, for blot at blive "Microsoft 365".)

Vi er sikre på, at folk vil blive ved med at bruge de individuelle appnavne (ord, Excel, PowerPoint og venner) og suitens moniker Office i mange år, selvom nytilkomne til softwaren nok vil ende med at kende det som 365, efter at have droppet det allestedsnærværende Microsoft-præfiks.

Som du måske ved, inkluderer de selvstændige Office-apps (dem du faktisk installerer lokalt, så du ikke behøver at gå online for at arbejde på dine ting) deres egen mulighed for at kryptere gemte dokumenter.

Dette formodes at tilføje et ekstra lag af sikkerhed, hvis du senere deler nogen af ​​disse filer, ved et uheld eller design, med nogen, der ikke skulle modtage dem – noget, der er overraskende nemt at gøre ved en fejl, når du deler vedhæftede filer via e-mail.

Medmindre og indtil du også giver modtageren den adgangskode, de skal bruge for at låse filen op, er det bare så meget strimlet kål for dem.

Selvfølgelig, hvis du inkluderer adgangskoden i e-mailens brødtekst, har du ikke opnået noget, men hvis du er en smule forsigtig med at dele adgangskoden via en anden kanal, har du købt dig en ekstra sikkerhed mod slyngler. , snoops og ne'er-do-wells får nem adgang til fortroligt indhold.

OME under rampelyset

Eller har du?

Ifølge forskere hos det finske cybersikkerhedsfirma WithSecure nyder dine data muligvis meget mindre beskyttelse, end du med rimelighed kunne forvente.

Den funktion, som testerne brugte, er det, de omtaler som Office 365-meddelelseskryptering eller OME for kort.

Vi har ikke gengivet deres eksperimenter her, af den simple grund, at de centrale Office-produkter, undskyld, 365-produkter ikke kører indbygget på Linux, som vi bruger til arbejde. De webbaserede versioner af Office-værktøjerne har ikke det samme funktionssæt som de komplette apps, så det er usandsynligt, at de resultater, vi opnår, stemmer overens med, hvordan de fleste forretningsbrugere af Office, ah, 365 har konfigureret Word, Excel, Outlook og venner på deres bærbare Windows-computere.

Som forskerne beskriver det:

Denne funktion annonceres for at give organisationer mulighed for at sende og modtage krypterede e-mail-beskeder mellem personer i og uden for din organisation på en sikker måde.

Men de påpeger også, at:

Desværre er OME-meddelelserne krypteret i en usikker elektronisk kodebog (ECB) driftstilstand.

ECB forklarede

At forklare.

Mange krypteringsalgoritmer, især Advanced Encryption Standard eller AES, som OME bruger, er det, der er kendt som blok chiffer, som forvrider store bidder af data ad gangen i stedet for at behandle individuelle bits eller bytes i rækkefølge.

Generelt formodes dette at hjælpe både effektiviteten og sikkerheden, fordi chifferen har flere inputdata til at blande-hakke-makulere-og-væske ved hver drejning af det kryptografiske håndsving, der driver algoritmen, og hver drejning bringer dig videre gennem de data, du ønsker at kryptere.

Kerne-AES-algoritmen bruger for eksempel 16 input-bytes (128 bit) ad gangen og forvrider disse data under en krypteringsnøgle for at producere 16 krypterede chiffertekst-outputbytes.

(Lad være med at forvirre blok størrelse med nøglestørrelse – AES-krypteringsnøgler kan være 128 bit, 192 bit eller 256 bit lange, afhængigt af hvor usandsynligt du vil have dem til at gætte, men alle tre nøglestørrelser fungerer på 128 bit blokke, hver gang algoritmen "krankes".)

Hvad dette betyder, er, at hvis du vælger en AES-nøgle (uanset længde) og derefter bruger AES-chifferet direkte på en del af data...

…derefter hver gang du får den samme input-chunk, får du den samme output-chunk.

Som en virkelig massiv kodebog

Det er derfor denne direkte driftsform kaldes ECB, forkortelse for elektronisk kodebog, fordi det er ligesom at have en enorm kodebog, der kunne bruges som opslagstabel til kryptering og dekryptering.

(En fuld "kodebog" kunne aldrig konstrueres i det virkelige liv, fordi du skal gemme en database bestående af 2¹²⁸ 16-byte indgange for hver mulig nøgle.)

Desværre, især i computerformaterede data, er gentagelse af visse bidder af data ofte uundgåelig, takket være det anvendte filformat.

For eksempel vil filer, der rutinemæssigt udfylder datasektioner, så de er opstillet på 512-byte-grænser (en almindelig sektorstørrelse, når der skrives til disk) eller til 4096-byte-grænser (en fælles tildelingsenhedsstørrelse ved reservation af hukommelse) ofte producere filer med lange kørsler på nul bytes.

Ligeledes vil tekstdokumenter, der indeholder masser af kedelplade, såsom sidehoveder og sidefødder på hver side, eller gentagne omtale af det fulde firmanavn, indeholde mange gentagelser.

Hver gang en gentagen klartekst-klump tilfældigvis lige er på linje på en 16-byte-grænse i AES-ECB-krypteringsprocessen, vil den derfor dukke op i den krypterede udgang som nøjagtig samme chiffertekst.

Så selvom du ikke formelt kan dekryptere chiffertekstfilen, kan du muligvis lave øjeblikkelige, sikkerhedsknusende slutninger fra den, takket være det faktum, at mønstre i inputtet (som du måske kender eller kan udlede, eller for at gætte) bevares i outputtet.

Her er et eksempel baseret på en artikel, vi publicerede for næsten ni år siden, da vi forklarede, hvorfor Adobes nu berygtede brug af ECB-mode kryptering til at "hash" sine brugeres adgangskoder var Ikke en god ide:

Bemærk, hvordan pixels, der er ensfarvet hvide i inputtet, pålideligt producerer et gentaget mønster i outputtet, og de blå dele forbliver noget regelmæssige, så strukturen af ​​de originale data er tydelig.

I dette eksempel fylder hver pixel i den originale fil præcis 4 bytes, så hver venstre-til-højre 4-pixel kørsel i inputdataene er 16 byte lang, hvilket flugter nøjagtigt med hver 16-byte AES-krypteringsblok, hvilket accentuerer "ECB-effekten".

---

Matchende chiffertekstmønstre

Endnu værre, hvis du har to dokumenter, som du ved er krypteret med den samme nøgle, og du bare tilfældigvis har klarteksten af ​​et af dem, så kan du se den chiffertekst igennem, som du kan ikke dekrypter, og prøv at matche dele af det med mønstre i chifferteksten, som du kan dekryptere.

Husk, at du ikke behøver nøglen til at "dekryptere" det første dokument, hvis du allerede har det i dekrypteret form - det er ikke overraskende kendt som en kendt klartekst-angreb.

Selvom der kun er et par matcher af tilsyneladende uskyldig tekst, der ikke i sig selv er hemmelige data, kan den viden, en modstander kan udvinde på denne måde, være en guldgrube for spioner for intellektuelle ejendomsrettigheder, sociale ingeniører, retsmedicinske efterforskere og mere.

For eksempel, selvom du ikke har nogen idé om, hvad detaljerne i et dokument refererer til, ved at matche kendte bidder i klartekst på tværs af flere filer, kan du muligvis bestemme, at en tilsyneladende tilfældig samling af dokumenter:

• Blev alle sendt til samme modtager, hvis der er en fælles hilsen øverst på hver enkelt.
• Henvis til samme projekt, hvis der er en unik identificerende tekststreng, der bliver ved med at dukke op.
• har samme sikkerhedsklassificering, hvis du er opsat på at fokusere på de ting, der tydeligvis er ment som "mere hemmelige" end resten.

Hvad skal jeg gøre?

Brug ikke ECB-tilstand!

Hvis du bruger en blokchiffer, skal du vælge en blok chiffer driftstilstand at:

• Indeholder det, der er kendt som en IV eller initialiseringsvektor, valgt tilfældigt og unikt for hver besked.
• Arrangerer bevidst krypteringsprocessen så gentagne input kommer forskelligt ud hver gang.

Hvis du bruger AES, er den tilstand, du sandsynligvis vil vælge i disse dage AES-GCM (Galois Counter Mode), som ikke kun bruger en IV til at skabe en anden krypteringsdatastrøm hver gang, selvom nøglen forbliver den samme, men også beregner det, der er kendt som en Beskedgodkendelseskode (MAC), eller kryptografisk kontrolsum, samtidig med at kryptere eller afkode dataene.

AES-GCM betyder ikke kun, at du undgår gentagne chiffertekstmønstre, men også at du altid ender med en "checksum", der fortæller dig, om de data, du lige har dekrypteret, er blevet pillet ved undervejs.

Husk, at en skurk, der ikke ved, hvad chifferteksten rent faktisk betyder, måske alligevel kan narre dig til at stole på en upræcis dekryptering uden nogensinde at vide (eller bekymre sig om), hvilken slags forkert output du ender med.

En MAC, der beregnes under dekrypteringsprocessen, baseret på samme nøgle og IV, vil være med til at sikre, at du ved, at den chiffertekst, du har modtaget, er gyldig, og at du derfor næsten helt sikkert har dekrypteret, hvad der oprindeligt blev sat ind i den anden ende.

Alternativt kan du bruge en dedikeret stream chiffer der producerer en pseudo-tilfældig byte-for-byte nøglestrøm, der giver dig mulighed for at kryptere data uden at skulle behandle 16 bytes (eller hvad blokstørrelsen måtte være) ad gangen.

AES-GCM konverterer i det væsentlige AES til en stream-chiffer og tilføjer autentificering i form af en MAC, men hvis du leder efter en dedikeret stream-ciffer designet specifikt til at fungere på den måde, foreslår vi Daniel Bernsteins ChaCha20-Poly1305 (Poly1305-delen er MAC), som beskrevet i RFC 8439.

Nedenfor har vi vist, hvad vi fik ved hjælp af AES-128-GCM og ChaCha20-Poly1305 (vi kasserede MAC-koderne her), sammen med et "billede" bestående af 95,040 RGBA-bytes (330×72 ved 4 bytes pr. pixel) fra Linux-kerne pseudo-tilfældig generator.

Husk, at bare fordi data ser ustrukturerede ud, betyder det ikke, at det virkelig er tilfældigt, men hvis det ikke ser tilfældigt ud, men alligevel hævder at være krypteret, kan du lige så godt antage, at der er en eller anden struktur tilbage, og at krypteringen er formode:

Hvad sker der nu?

Ifølge WithSecure, Microsoft planlægger ikke at rette denne "sårbarhed", tilsyneladende på grund af bagudkompatibilitet med Office 2010...

Ældre versioner af Office (2010) kræver AES 128 ECB, og Office-dokumenter er stadig beskyttet på denne måde af Office-apps.

…og…

[WithSecure-forskernes] rapport blev ikke anset for at opfylde kravene til sikkerhedsservice, og den anses heller ikke for at være et brud. Der blev ikke foretaget nogen kodeændring, og der blev derfor ikke udstedt nogen CVE for denne rapport.

Kort sagt, hvis du i øjeblikket er afhængig af OME, kan du overveje at erstatte det med et tredjeparts krypteringsværktøj til følsomme meddelelser, der krypterer dine data uafhængigt af de apps, der har oprettet disse meddelelser, og dermed fungerer uafhængigt af den interne kryptering kode i Office-området.

På den måde kan du vælge en moderne krypteringskode og en moderne chifferfunktion uden at skulle gå tilbage til den gamle dekrypteringskode, der er indbygget i Office 2010.

---

SÅDAN LAGEDE VI BILLEDERNE I ARTIKLEN Start med sop330.png, som du kan oprette til dig selv ved at beskære det ryddede SOPHOS-logo fra det øverste billede, fjerne den 2-pixel blå grænse og gemme i PNG-format.  Billedet skal ende på 330x72 pixels i størrelse.
 Konverter til RGBA ved hjælp af ImageMagick: $ convert sop330.png sop.rgba Output er 330x72 pixels x 4 bytes/pixel = 95,040 bytes.
 === Krypter ved hjælp af Lua og LuaOSSL-biblioteket (Python har en meget lignende OpenSSL-binding): -- indlæs data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- opret chifferobjekter > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- initialiser adgangskoder og IV'er -- AES-128-ECB har brug for en 128-bit adgangskode, men ingen IV -- AES-128-GCM har brug for en 128-bit adgangskode og en 12-byte IV -- ChaCha20 har brug for en 256-bit adgangskode og a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g-fildataene') -- med de tre krypteringsfiler > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- en strømchiffer producerer output byte-for-byte, -- så chiffertekst skal have samme længde som almindelig tekst > gcmout:len() 95040 > chaout:len() 95040 -- vi vil ikke bruge MAC-koderne fra GCM og Poly1305 her, -- men hver chiffer producerer en 128-bit (16-byte) "checksum" -- bruges til at autentificere dekrypteringen, efter den er færdig, -- for at opdage om input chifferteksten bliver ødelagt eller hacket -- (MAC'en afhænger af nøglen, så en angriberen kan ikke forfalske det) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b "=opret avnrand" ---opret avnrandud" /56ef95040b" misc.filetostr('/dev/random',#fdat) -- gem dem alle - bemærk, at vi eksplicit afkorter AES-ECB -- blokchiffer-output til den nøjagtige billedlængde, der kræves, fordi -- ECB har brug for polstring for at matche inputstørrelse med blokstørrelsen > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === For at indlæse filerne i en almindelig billedfremviser, skal du muligvis konvertere dem tabsfrit tilbage til PNG-format: $ convert -depth 8 -størrelse 330x72 aes .rgba aes.png $ convert -depth 8 -størrelse 330x72 gcm.rgba gcm.png $ convert -depth 8 -size 330x72 cha.rgba cha.png $ convert -depth 8 -size 330x72 rnd.rgba rnd.png === Givet at krypteringsprocessen forvrider alle fire bytes i hver RGBA-pixel , har det resulterende billede variabel gennemsigtighed (A = alfa, forkortelse for transparens).
 Din billedfremviser kan beslutte at vise denne slags billede med en skakternet baggrund, som til forveksling ligner en del af billedet, men ikke er det.  Vi brugte derfor Sophos blå fra det originale billede som baggrund for de krypterede filer for at gøre dem nemmere at se.  Den overordnede blå nuance er derfor ikke en del af billeddataene.