Alvorlig sikkerhet: Microsoft Office 365 angrep over svak kryptering

Vi er ikke helt sikre på hva vi skal kalle det akkurat nå, så vi refererte til det i overskriften med hybridnavnet Microsoft Office 365.

(Navnet "Office" som samlesubstantivet for Microsofts tekstbehandlings-, regneark-, presentasjons- og samarbeidsapper blir drept av i løpet av de neste månedene eller to, for å bli ganske enkelt "Microsoft 365".)

Vi er sikre på at folk vil fortsette å bruke de individuelle appnavnene (ord, Excel, PowerPoint og venner) og suitens moniker Office i mange år, selv om nykommere til programvaren sannsynligvis vil ende opp med å vite det som 365, etter å ha droppet det allestedsnærværende Microsoft-prefikset.

Som du kanskje vet, inkluderer de frittstående Office-appene (de du faktisk installerer lokalt slik at du ikke trenger å gå på nettet for å jobbe med tingene dine) sine egne alternativer for å kryptere lagrede dokumenter.

Dette er ment å legge til et ekstra lag med sikkerhet i tilfelle du senere deler noen av disse filene, ved et uhell eller design, med noen som ikke skulle motta dem – noe som er overraskende enkelt å gjøre ved en feiltakelse når du deler vedlegg via e-post.

Med mindre og til du også gir mottakeren passordet de trenger for å låse opp filen, er det bare så mye strimlet kål for dem.

Selvfølgelig, hvis du inkluderer passordet i brødteksten i e-posten, har du ikke fått noe, men hvis du til og med er litt forsiktig med å dele passordet via en annen kanal, har du kjøpt deg litt ekstra sikkerhet og sikkerhet mot useriøse , snoops og ne'er-do-wells får enkel tilgang til konfidensielt innhold.

OME under søkelyset

Eller har du det?

Ifølge forskere hos det finske cybersikkerhetsselskapet WithSecure kan dataene dine ha mye mindre beskyttelse enn du med rimelighet kunne forvente.

Funksjonen som testerne brukte er det de omtaler som Office 365 meldingskrypteringeller OME for kort.

Vi har ikke gjengitt eksperimentene deres her, av den enkle grunn at kjernen i Office, beklager, 365-produktene ikke kjører naturlig på Linux, som vi bruker til arbeid. De nettbaserte versjonene av Office-verktøyene har ikke samme funksjonssett som de fullstendige appene, så det er usannsynlig at noen resultater vi oppnår vil stemme overens med hvordan de fleste forretningsbrukere av Office, ah, 365 har konfigurert Word, Excel, Outlook og venner på sine Windows-bærbare datamaskiner.

Slik forskerne beskriver det:

Denne funksjonen er annonsert for å tillate organisasjoner å sende og motta krypterte e-postmeldinger mellom personer i og utenfor organisasjonen din på en sikker måte.

Men de påpeker også at:

Dessverre er OME-meldingene kryptert i usikker elektronisk kodebok (ECB) modus.

ECB forklarte

Å forklare.

Mange krypteringsalgoritmer, spesielt Advanced Encryption Standard eller AES, som OME bruker, er det som kalles blokkeringssiffer, som krypterer store biter av data om gangen, i stedet for å behandle individuelle biter eller byte i rekkefølge.

Generelt sett er dette ment å hjelpe både effektivitet og sikkerhet, fordi chifferen har flere inngangsdata for å blande-hakke-makulere-og-væske ved hver omdreining av det kryptografiske sveivhåndtaket som driver algoritmen, og hver sving kommer deg videre gjennom dataene du ønsker å kryptere.

Kjerne-AES-algoritmen bruker for eksempel 16 klartekst-byte (128 biter) om gangen, og krypterer disse dataene under en krypteringsnøkkel for å produsere 16 krypterte utdatabyte for chiffertekst.

(Ikke forvirre blokkstørrelse med nøkkelstørrelse – AES-krypteringsnøkler kan være 128 bits, 192 bits eller 256 bits lange, avhengig av hvor usannsynlige du vil at de skal være til å gjette, men alle tre nøkkelstørrelsene fungerer på 128 bits blokker hver gang algoritmen "sveivs".)

Hva dette betyr er at hvis du velger en AES-nøkkel (uansett lengde) og deretter bruker AES-chifferet direkte på en del av data ...

…deretter hver gang du får den samme inngangsdelen, får du den samme utdatadelen.

Som en virkelig massiv kodebok

Det er derfor denne direkte driftsmodusen kalles ECB, kort for elektronisk kodebok, fordi det er på en måte som å ha en enorm kodebok som kan brukes som en oppslagstabell for kryptering og dekryptering.

(En full "kodebok" kan aldri konstrueres i det virkelige liv, fordi du må lagre en database som består av 2¹²⁸ 16-byte oppføringer for hver mulig nøkkel.)

Dessverre, spesielt i dataformaterte data, er repetisjon av visse biter av data ofte uunngåelig, takket være filformatet som brukes.

For eksempel vil filer som rutinemessig fyller ut dataseksjoner slik at de er på linje på 512-byte-grenser (en vanlig sektorstørrelse når du skriver til disk) eller til 4096-byte-grenser (en vanlig tildelingsenhetsstørrelse når du reserverer minne) ofte produsere filer med lange serier med null byte.

På samme måte vil tekstdokumenter som inneholder mye tekst, for eksempel topptekster og bunntekster på hver side, eller gjentatt omtale av hele firmanavnet, inneholde mange gjentakelser.

Hver gang en gjentatt klartekstdel tilfeldigvis stiller opp på en 16-byte-grense i AES-ECB-krypteringsprosessen, vil den derfor dukke opp i den krypterte utgangen som nøyaktig samme chiffertekst.

Så selv om du ikke formelt kan dekryptere chiffertekstfilen, kan du kanskje gjøre umiddelbare, sikkerhetsknusende slutninger fra den, takket være det faktum at mønstre i inndataene (som du kanskje kjenner, eller kan utlede, eller for å gjette) er bevart i utgangen.

Her er et eksempel basert på en artikkel vi publiserte for nesten ni år siden da vi forklarte hvorfor Adobes nå beryktede bruk av ECB-modus kryptering for å "hash" brukernes passord var Ikke en god idé:

Legg merke til hvordan pikslene som er helhvite i inngangen produserer pålitelig et repeterende mønster i utdataene, og de blå delene forblir noe regelmessige, slik at strukturen til de originale dataene er tydelig.

I dette eksemplet tar hver piksel i den opprinnelige filen opp nøyaktig 4 byte, så hver venstre-til-høyre 4-piksel kjøring i inngangsdataene er 16 byte lang, noe som justeres nøyaktig med hver 16-byte AES-krypteringsblokk, og dermed fremheve «ECB-effekten».

---

Matchende chiffertekstmønstre

Enda verre, hvis du har to dokumenter som du vet er kryptert med samme nøkkel, og du tilfeldigvis har renteksten til ett av dem, så kan du se gjennom chifferteksten som du kan ikke dekrypter, og prøv å matche deler av den med mønstre i chifferteksten du kan dekryptere.

Husk at du ikke trenger nøkkelen for å "dekryptere" det første dokumentet hvis du allerede har det i dekryptert form – dette er ikke overraskende kjent som en kjent klartekstangrep.

Selv om det bare er noen få treff med tilsynelatende uskyldig tekst som ikke i seg selv er hemmelige data, kan kunnskapen en motstander kan trekke ut på denne måten være en gullgruve for åndsverkspioner, sosiale ingeniører, rettsmedisinske etterforskere og mer.

For eksempel, selv om du ikke aner hva detaljene i et dokument refererer til, ved å matche kjente klartekstbiter på tvers av flere filer, kan du kanskje fastslå at en tilsynelatende tilfeldig samling av dokumenter:

• Alle ble sendt til samme mottaker, hvis det er en felles hilsen på toppen av hver enkelt.
• Referer til samme prosjekt, hvis det er en unik identifiserende tekststreng som stadig dukker opp.
• har samme sikkerhetsklassifisering, hvis du er opptatt av å fokusere på ting som tydeligvis er ment å være "mer hemmelig" enn resten.

Hva gjør jeg?

Ikke bruk ECB-modus!

Hvis du bruker et blokkchiffer, velg en driftsmodus for blokkchiffer at:

• Inkluderer det som er kjent som en IV, eller initialiseringsvektor, valgt tilfeldig og unikt for hver melding.
• Ordner med vilje krypteringsprosessen slik at gjentatte innspill kommer ut forskjellig hver gang.

Hvis du bruker AES, er modusen du sannsynligvis vil velge i disse dager AES-GCM (Galois Counter Mode), som ikke bare bruker en IV for å lage en annen krypteringsdatastrøm hver gang, selv om nøkkelen forblir den samme, men som også beregner det som kalles en Meldingsautentiseringskode (MAC), eller kryptografisk sjekksum, samtidig som du krypterer eller opphever dataene.

AES-GCM betyr ikke bare at du unngår gjentatte chiffertekstmønstre, men også at du alltid ender opp med en «sjekksum» som vil fortelle deg om dataene du nettopp dekrypterte ble tuklet med underveis.

Husk at en kjeltring som ikke vet hva chifferteksten egentlig betyr, kan likevel være i stand til å lure deg til å stole på en unøyaktig dekryptering uten å vite (eller bry seg om) hva slags feil utgang du ender opp med.

En MAC som beregnes under dekrypteringsprosessen, basert på samme nøkkel og IV, vil bidra til å sikre at du vet at chifferteksten du mottok er gyldig, og derfor at du nesten helt sikkert har dekryptert det som opprinnelig ble satt inn i den andre enden.

Alternativt kan du bruke en dedikert strøm chiffer som produserer en pseudo-tilfeldig byte-for-byte nøkkelstrøm som lar deg kryptere data uten å måtte behandle 16 byte (eller hva blokkstørrelsen måtte være) om gangen.

AES-GCM konverterer i hovedsak AES til et strømchiffer og legger til autentisering i form av en MAC, men hvis du leter etter et dedikert strømchiffer designet spesielt for å fungere på den måten, foreslår vi Daniel Bernsteins ChaCha20-Poly1305 (Poly1305-delen er MAC), som beskrevet i RFC 8439.

Nedenfor har vi vist hva vi fikk med AES-128-GCM og ChaCha20-Poly1305 (vi forkastet MAC-kodene her), sammen med et "bilde" bestående av 95,040 330 RGBA-byte (72×4 ved XNUMX byte per piksel) fra Linux-kjerne pseudo-tilfeldig generator.

Husk at bare fordi data ser ustrukturerte ut, betyr det ikke at det virkelig er tilfeldig, men hvis det ikke ser tilfeldig ut, men likevel hevder å være kryptert, kan du like gjerne anta at det er noe struktur igjen, og at krypteringen er mistenkt:

Hva skjer videre?

I følge WithSecure, Microsoft planlegger ikke å fikse denne "sårbarheten", tilsynelatende på grunn av bakoverkompatibilitet med Office 2010...

Eldre versjoner av Office (2010) krever AES 128 ECB, og Office-dokumenter er fortsatt beskyttet på denne måten av Office-apper.

…og…

Rapporten [WithSecure-forskerne] ble ikke ansett som å oppfylle kravene for sikkerhetsservice, og den anses heller ikke som et brudd. Ingen kodeendring ble gjort, og det ble derfor ikke utstedt noen CVE for denne rapporten.

Kort sagt, hvis du for øyeblikket er avhengig av OME, kan det være lurt å vurdere å erstatte det med et tredjeparts krypteringsverktøy for sensitive meldinger som krypterer dataene dine uavhengig av appene som opprettet disse meldingene, og dermed fungerer uavhengig av den interne krypteringen kode i Office-området.

På den måten kan du velge en moderne chiffer og en moderne modus for chifferoperasjon, uten å måtte gå tilbake til den gamle dekrypteringskoden som er innebygd i Office 2010.

---

HVORDAN VI LAGET BILDENE I ARTIKKELEN Start med sop330.png, som du kan lage selv ved å beskjære den ryddede SOPHOS-logoen fra det øverste bildet, fjerne den blå 2-pikslers grensen og lagre i PNG-format.  Bildet skal ende opp på 330x72 piksler i størrelse.
 Konverter til RGBA ved hjelp av ImageMagick: $ convert sop330.png sop.rgba Utdata er 330x72 piksler x 4 byte/piksel = 95,040 XNUMX byte.
 === Krypter ved hjelp av Lua og LuaOSSL-biblioteket (Python har en veldig lik OpenSSL-binding): -- last inn data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- lag chifferobjekter > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- initialiser passord og IV-er -- AES-128-ECB trenger et 128-biters passord, men ingen IV -- AES-128-GCM trenger et 128-biters passord og en 12-byte IV -- ChaCha20 trenger et 256-biters passord og a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g-fildataene') -- med de tre krypteringsfilene > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- en strømchiffer produserer utdata byte-for-byte, -- så chiffertekst bør ha samme lengde som ren tekst > gcmout:len() 95040 > chaout:len() 95040 -- vi kommer ikke til å bruke MAC-kodene fra GCM og Poly1305 her, -- men hver chiffer produserer en 128-biters (16-byte) "sjekksum" -- brukes til å autentisere dekrypteringen etter at den er ferdig, -- for å oppdage om inndatachifferteksten blir ødelagt eller hacket -- (MAC-en avhenger av nøkkelen, så en angriperen kan ikke forfalske det) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b image " = 56f95040b rett ut fra /1f8b image misc.filetostr('/dev/random',#fdat) -- lagre dem alle - merk at vi eksplisitt avkorter AES-ECB -- blokkchifferutgang til nøyaktig bildelengde som kreves, fordi -- ECB trenger utfylling for å matche skriv inn størrelse med blokkstørrelsen > misc.strtofile(aesout:sub(330,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === For å laste filene i en vanlig bildeviser, må du kanskje konvertere dem tapsfritt tilbake til PNG-format: $ convert -depth 72 -størrelse 8x330 aes .rgba aes.png $ convert -depth 72 -størrelse 8x330 gcm.rgba gcm.png $ convert -depth 72 -size 8x330 cha.rgba cha.png $ convert -depth 72 -size XNUMXxXNUMX rnd.rgba rnd.png === Gitt at krypteringsprosessen krypterer alle fire byte i hver RGBA-piksel , har det resulterende bildet variabel gjennomsiktighet (A = alfa, forkortelse for transparency).
 Bildeviseren din kan bestemme seg for å vise denne typen bilder med en sjakkbrettbakgrunn, som til forveksling ser ut som en del av bildet, men ikke er det.  Vi brukte derfor Sophos-blåen fra originalbildet som bakgrunn for de krypterte filene for å gjøre dem lettere å se.  Den generelle blåfargen er derfor ikke en del av bildedataene.