Allvarlig säkerhet: Microsoft Office 365 attackerades över svag kryptering

Vi är inte riktigt säkra på vad vi ska kalla det just nu, så vi hänvisade till det i rubriken med hybridnamnet Microsoft Office 365.

(Namnet "Office" som samlingssubstantiv för Microsofts ordbehandlings-, kalkylblads-, presentations- och samarbetsappar håller på att avdödad under de kommande månaderna eller två, för att helt enkelt bli "Microsoft 365".)

Vi är säkra på att folk kommer att fortsätta använda de individuella appnamnen (ord, excel, PowerPoint och vänner) och svitens namn Office under många år, även om nykomlingar till programvaran förmodligen kommer att känna till det som 365, efter att ha tappat det allestädes närvarande Microsoft-prefixet.

Som du kanske vet innehåller de fristående Office-apparna (de du faktiskt installerar lokalt så att du inte behöver gå online för att arbeta med dina saker) ett eget alternativ för att kryptera sparade dokument.

Detta är tänkt att lägga till ett extra lager av säkerhet ifall du senare delar någon av dessa filer, av misstag eller design, med någon som inte var tänkt att ta emot dem – något som är förvånansvärt lätt att göra av misstag när du delar bilagor via e-post.

Om inte och tills du också ger mottagaren lösenordet de behöver för att låsa upp filen, är det bara så mycket strimlad kål för dem.

Naturligtvis, om du inkluderar lösenordet i e-postmeddelandet, har du inte vunnit någonting, men om du ens är lite försiktig med att dela lösenordet via en annan kanal, har du köpt dig lite extra säkerhet och säkerhet mot skurkar , snoops och ne'er-do-wells får enkel tillgång till konfidentiellt innehåll.

OME i rampljuset

Eller har du det?

Enligt forskare hos det finska cybersäkerhetsföretaget WithSecure kan dina data åtnjuta mycket mindre skydd än du rimligen kan förvänta dig.

Funktionen som testarna använde är vad de refererar till som Office 365 meddelandekryptering, eller ÖK för korta.

Vi har inte reproducerat deras experiment här, av den enkla anledningen att kärnan i Office, tyvärr, 365-produkter inte körs inbyggt på Linux, som vi använder för arbete. De webbaserade versionerna av Office-verktygen har inte samma funktionsuppsättning som de fullständiga apparna, så det är osannolikt att några resultat vi får kommer att överensstämma med hur de flesta företagsanvändare av Office, ah, 365 har konfigurerat Word, Excel, Outlook och vänner på sina bärbara Windows-datorer.

Som forskarna beskriver det:

Den här funktionen marknadsförs för att tillåta organisationer att skicka och ta emot krypterade e-postmeddelanden mellan personer inom och utanför din organisation på ett säkert sätt.

Men de påpekar också att:

Tyvärr är OME-meddelanden krypterade i insecure Electronic Codebook (ECB) driftläge.

ECB förklarade

Att förklara.

Många krypteringsalgoritmer, särskilt Advanced Encryption Standard eller AES, som OME använder, är vad som kallas blockchiffer, som förvränger stora bitar av data åt gången, snarare än att bearbeta enskilda bitar eller byte i sekvens.

Generellt sett är detta tänkt att hjälpa både effektiviteten och säkerheten, eftersom chifferet har mer indata att blanda-mala-strimma-och-vätske vid varje varv av det kryptografiska vevhandtaget som driver algoritmen, och varje varv tar dig längre genom data du vill kryptera.

Kärn-AES-algoritmen, till exempel, förbrukar 16 inmatade klartextbyte (128 bitar) åt gången, och förvränger dessa data under en krypteringsnyckel för att producera 16 krypterade chiffertextutdatabytes.

(Förväxla inte block storlek med nyckelstorlek – AES-krypteringsnycklar kan vara 128 bitar, 192 bitar eller 256 bitar långa, beroende på hur osannolikt du vill att de ska vara att gissa, men alla tre nyckelstorlekarna fungerar på 128 bitars block varje gång algoritmen "vevs".)

Vad detta betyder är att om du väljer en AES-nyckel (oavsett längd) och sedan använder AES-chifferet direkt på en bit data...

…sedan varje gång du får samma ingångsbit får du samma utgångsbit.

Som en riktigt massiv kodbok

Det är därför detta direkta driftsätt kallas ECB, Förkortning av elektronisk kodbok, för det är ungefär som att ha en enorm kodbok som skulle kunna användas som en uppslagstabell för kryptering och dekryptering.

(En fullständig "kodbok" skulle aldrig kunna konstrueras i verkligheten, eftersom du skulle behöva lagra en databas bestående av 2¹²⁸ 16-byte-poster för varje möjlig nyckel.)

Tyvärr, särskilt i datorformaterad data, är upprepning av vissa bitar av data ofta oundvikligt, tack vare filformatet som används.

Till exempel kommer filer som rutinmässigt fyller ut datasektioner så att de radas upp på 512-byte-gränser (en vanlig sektorstorlek när man skriver till disk) eller till 4096-byte-gränser (en vanlig tilldelningsenhetsstorlek när man reserverar minne) ofta producera filer med långa serier av noll byte.

Likaså kommer textdokument som innehåller massor av texter, såsom sidhuvuden och sidfötter på varje sida, eller upprepade omnämnanden av det fullständiga företagsnamnet, att innehålla många upprepningar.

Varje gång en upprepad klartextbit bara råkar hamna på en 16-byte-gräns i AES-ECB-krypteringsprocessen, kommer den därför att dyka upp i den krypterade utgången som exakt samma chiffertext.

Så även om du inte formellt kan dekryptera chiffertextfilen, kanske du kan göra omedelbara, säkerhetskrossande slutsatser från den, tack vare det faktum att mönster i inmatningen (som du kanske känner till eller kan härleda, eller för att gissa) bevaras i utgången.

Här är ett exempel baserat på en artikel som vi publicerade för nästan nio år sedan när vi förklarade varför Adobes nu ökända användning av kryptering i ECB-läge för att "hasha" sina användares lösenord var Inte en bra idé:

Lägg märke till hur pixlarna som är helt vita i ingången på ett tillförlitligt sätt producerar ett repetitivt mönster i utmatningen, och de blå delarna förblir något regelbundna, så att strukturen hos originaldata är uppenbar.

I det här exemplet tar varje pixel i originalfilen upp exakt 4 byte, så varje körning på 4 pixlar från vänster till höger i indata är 16 byte lång, vilket är exakt i linje med varje 16-byte AES-krypteringsblock, vilket accentuerar "ECB-effekten".

---

Matchande chiffertextmönster

Ännu värre, om du har två dokument som du vet är krypterade med samma nyckel, och du bara råkar ha klartexten av ett av dem, då kan du titta igenom chiffertexten som du kan inte dekryptera och försök matcha delar av det med mönster i chiffertexten som du Kan Avkryptera.

Kom ihåg att du inte behöver nyckeln för att "dekryptera" det första dokumentet om du redan har det i dekrypterad form – detta är föga förvånande känt som en känd-klartextattack.

Även om det bara finns ett fåtal matchningar av uppenbarligen oskyldig text som inte i sig är hemlig data, kan den kunskap en motståndare kan extrahera på detta sätt vara en guldgruva för immaterialrättsspioner, sociala ingenjörer, kriminaltekniska utredare och mer.

Till exempel, även om du inte har någon aning om vad detaljerna i ett dokument hänvisar till, genom att matcha kända klartextbitar över flera filer, kan du kanske fastställa att en till synes slumpmässig samling av dokument:

• Alla skickades till samma mottagare, om det finns en gemensam hälsning överst på var och en.
• Hänvisa till samma projekt, om det finns en unik identifierande textsträng som hela tiden dyker upp.
• har samma säkerhetsklassificering, om du är angelägen om att fokusera på saker som tydligt är menade att vara "mer hemliga" än resten.

Vad göra?

Använd inte ECB-läge!

Om du använder ett blockchiffer, välj ett blockchiffer driftläge att:

• Inkluderar vad som kallas en IV, eller initialiseringsvektor, vald slumpmässigt och unikt för varje meddelande.
• Ordnar medvetet krypteringsprocessen så att upprepade ingångar kommer ut olika varje gång.

Om du använder AES är det läge du förmodligen vill välja nu för tiden AES-GCM (Galois Counter Mode), som inte bara använder en IV för att skapa en annan krypteringsdataström varje gång, även om nyckeln förblir densamma, utan också beräknar vad som kallas en Meddelandeautentiseringskod (MAC), eller kryptografisk kontrollsumma, samtidigt som kryptering eller avkodning av data.

AES-GCM innebär inte bara att du undviker upprepade chiffertextmönster, utan också att du alltid får en "kontrollsumma" som talar om för dig om den data du just dekrypterade har manipulerats på vägen.

Kom ihåg att en skurk som inte vet vad chiffertexten faktiskt betyder kanske ändå kan lura dig att lita på en inexakt dekryptering utan att någonsin veta (eller bry sig om) vilken sorts felaktig utdata du slutar med.

En MAC som beräknas under dekrypteringsprocessen, baserat på samma nyckel och IV, kommer att hjälpa till att säkerställa att du vet att chiffertexten du fick är giltig, och därför att du nästan säkert har dekrypterat det som ursprungligen lades in i andra änden.

Alternativt, använd en dedikerad strömciffer som producerar en pseudoslumpmässig byte-för-byte-nyckelström som låter dig kryptera data utan att behöva bearbeta 16 byte (eller vad blockstorleken kan vara) åt gången.

AES-GCM konverterar i huvudsak AES till ett strömchiffer och lägger till autentisering i form av en MAC, men om du letar efter ett dedikerat strömchiffer designat specifikt för att fungera på det sättet, föreslår vi Daniel Bernsteins ChaCha20-Poly1305 (Poly1305-delen är MAC), som beskrivs i RFC 8439.

Nedan har vi visat vad vi fick med AES-128-GCM och ChaCha20-Poly1305 (vi kasserade MAC-koderna här), tillsammans med en "bild" bestående av 95,040 330 RGBA-byte (72×4 vid XNUMX byte per pixel) från Linux-kärna pseudo-slumpgenerator.

Kom ihåg att bara för att data ser ostrukturerad ut betyder det inte att den verkligen är slumpmässig, men om den inte ser slumpmässig ut, men ändå påstår sig vara krypterad, kan du lika gärna anta att det finns någon struktur kvar och att krypteringen är misstänka:

Vad händer härnäst?

Enligt WithSecure, Microsoft planerar inte att fixa denna "sårbarhet", uppenbarligen på grund av bakåtkompatibilitet med Office 2010...

Äldre versioner av Office (2010) kräver AES 128 ECB, och Office-dokument skyddas fortfarande på detta sätt av Office-appar.

…och…

[WithSecure-forskarnas] rapport ansågs inte uppfylla kraven för säkerhetsservice och anses inte heller vara ett brott. Ingen kodändring gjordes och därför utfärdades ingen CVE för denna rapport.

Kort sagt, om du för närvarande förlitar dig på OME, kanske du vill överväga att ersätta det med ett krypteringsverktyg från tredje part för känsliga meddelanden som krypterar din data oberoende av apparna som skapade dessa meddelanden, och därmed fungerar oberoende av den interna krypteringen kod i Office-intervallet.

På så sätt kan du välja ett modernt chiffer och ett modernt läge för chifferoperation, utan att behöva gå tillbaka till den gamla skolans dekrypteringskod som är inbyggd i Office 2010.

---

HUR VI GJORDE BILDERNA I ARTIKELN Börja med sop330.png, som du kan skapa själv genom att beskära den rensade SOPHOS-logotypen från den översta bilden, ta bort den blå gränsen på 2 pixlar och spara i PNG-format.  Bilden ska hamna på 330x72 pixlar i storlek.
 Konvertera till RGBA med ImageMagick: $ convert sop330.png sop.rgba Utdata är 330x72 pixlar x 4 byte/pixel = 95,040 XNUMX byte.
 === Kryptera med Lua och LuaOSSL-biblioteket (Python har en mycket liknande OpenSSL-bindning): -- ladda data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- skapa chifferobjekt > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- initialisera lösenord och IVs -- AES-128-ECB behöver ett 128-bitars lösenord, men ingen IV -- AES-128-GCM behöver ett 128-bitars lösenord och en 12-byte IV -- ChaCha20 behöver ett 256-bitars lösenord och a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g fildata med tre krypteringsfildata') -- > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- ett strömchiffer producerar utdata byte-för-byte, -- så chiffertext bör ha samma längd som klartext > gcmout:len() 95040 > chaout:len() 95040 -- vi kommer inte att använda MAC-koderna från GCM och Poly1305 här, -- men varje chiffer producerar en 128-bitars (16-byte) "checksumma" -- används för att autentisera dekrypteringen efter att den är klar, -- för att upptäcka om den inmatade chiffertexten blir skadad eller hackad -- (MAC:n beror på nyckeln, så en angriparen kan inte förfalska det) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b " = 56b95040d1e8f330cb72a8be330fa72f8b " /330ef72b image rakt ut från " /8frandom" misc.filetostr('/dev/random',#fdat) -- spara dem alla - observera att vi uttryckligen trunkerar AES-ECB -- blockchifferutdata till den exakta bildlängden som krävs, eftersom -- ECB behöver utfyllnad för att matcha mata in storlek med blockstorleken > misc.strtofile(aesout:sub(330,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === För att ladda filerna i en vanlig bildvisare kan du behöva konvertera dem förlustfritt tillbaka till PNG-format: $ convert -depth 72 -size XNUMXxXNUMX aes .rgba aes.png $ convert -depth XNUMX -storlek XNUMXxXNUMX gcm.rgba gcm.png $ convert -depth XNUMX -size XNUMXxXNUMX cha.rgba cha.png $ convert -depth XNUMX -size XNUMXxXNUMX rnd.rgba rnd.png === Med tanke på att krypteringsprocessen förvränger alla fyra byte i varje RGBA-pixel , har den resulterande bilden variabel transparens (A = alfa, förkortning för transparens).
 Din bildvisare kan välja att visa den här typen av bild med en rutbrädebakgrund, som förvirrande nog ser ut som en del av bilden, men inte är det.  Vi använde därför Sophos blå från originalbilden som bakgrund för de krypterade filerna för att göra dem lättare att se.  Den övergripande blå nyansen är därför inte en del av bilddata.