Ernstige beveiliging: Microsoft Office 365 aangevallen via zwakke versleuteling

We weten niet precies hoe we het nu moeten noemen, dus hebben we het in de kop genoemd met de hybride naam Microsoft Office 365.

(De naam "Office" als verzamelnaam voor de tekstverwerkings-, spreadsheet-, presentatie- en samenwerkingsapps van Microsoft wordt gedood in de komende twee maanden om simpelweg "Microsoft 365" te worden.)

We zijn er zeker van dat mensen de afzonderlijke app-namen zullen blijven gebruiken (Woord, Excel, PowerPoint en vrienden) en de naam van de suite Kantoor voor vele jaren, hoewel nieuwkomers in de software het waarschijnlijk zullen kennen als: 365, nadat het alomtegenwoordige Microsoft-voorvoegsel is verwijderd.

Zoals u wellicht weet, bevatten de zelfstandige Office-apps (degene die u daadwerkelijk lokaal installeert, zodat u niet online hoeft te gaan om aan uw spullen te werken) hun eigen optie om opgeslagen documenten te versleutelen.

Dit wordt verondersteld een extra beveiligingslaag toe te voegen voor het geval je later een van die bestanden, per ongeluk of ontwerp, deelt met iemand die ze niet had mogen ontvangen - iets dat verrassend gemakkelijk per ongeluk te doen is bij het delen van bijlagen via e-mail.

Tenzij en totdat je de ontvanger ook het wachtwoord geeft dat ze nodig hebben om het bestand te ontgrendelen, is het gewoon zoveel versnipperde kool voor hen.

Natuurlijk, als je het wachtwoord in de hoofdtekst van de e-mail opneemt, heb je niets gewonnen, maar als je zelfs maar een beetje voorzichtig bent met het delen van het wachtwoord via een ander kanaal, heb je wat extra veiligheid en beveiliging tegen schurken gekocht , snuffelaars en nietsnutten krijgen gemakkelijk toegang tot vertrouwelijke inhoud.

OME in de schijnwerpers

Of heb je?

Think onderzoekers bij het Finse cyberbeveiligingsbedrijf WithSecure genieten uw gegevens mogelijk veel minder bescherming dan u redelijkerwijs zou verwachten.

De functie die de testers gebruikten, is wat ze noemen: Office 365-berichtversleutelingof OME in het kort.

We hebben hun experimenten hier niet gereproduceerd, om de eenvoudige reden dat de kernproducten van Office, sorry, 365 niet native draaien op Linux, dat we voor ons werk gebruiken. De webversies van de Office-hulpprogramma's hebben niet dezelfde functieset als de volledige apps, dus de resultaten die we zouden kunnen verkrijgen, zullen waarschijnlijk niet overeenkomen met hoe de meeste zakelijke gebruikers van Office, ah, 365 Word, Excel, Outlook hebben geconfigureerd en vrienden op hun Windows-laptops.

Zoals de onderzoekers het omschrijven:

Deze functie wordt geadverteerd om organisaties in staat te stellen op een veilige manier versleutelde e-mailberichten te verzenden en ontvangen tussen mensen binnen en buiten uw organisatie.

Maar ze wijzen er ook op dat:

Helaas zijn de OME-berichten versleuteld in de onveilige elektronische codeboek (ECB)-modus.

ECB uitgelegd

Uitleggen.

Veel encryptie-algoritmen, met name de Advanced Encryption Standard of AES, die OME gebruikt, zijn wat bekend staat als blokcijfers, die grote hoeveelheden gegevens tegelijk door elkaar gooien, in plaats van afzonderlijke bits of bytes achter elkaar te verwerken.

Over het algemeen wordt verondersteld dat dit zowel de efficiëntie als de veiligheid ten goede komt, omdat het cijfer meer invoergegevens heeft om te mixen-gehakt-versnipperen-en-liquidiseren bij elke draai van de cryptografische kruk die het algoritme aandrijft, en elke draai brengt u verder door de gegevens die u wilt versleutelen.

Het kern-AES-algoritme verbruikt bijvoorbeeld 16 invoerbytes zonder opmaak (128 bits) per keer en versleutelt die gegevens onder een coderingssleutel om 16 gecodeerde coderingstekstuitvoerbytes te produceren.

(niet verwarren blok grootte Met sleutelgrootte – AES-coderingssleutels kunnen 128 bits, 192 bits of 256 bits lang zijn, afhankelijk van hoe onwaarschijnlijk u wilt dat ze raden, maar alle drie de sleutelgroottes werken op 128-bits blokken telkens wanneer het algoritme wordt "gecrankeerd".)

Wat dit betekent is dat als je een AES-sleutel kiest (ongeacht de lengte) en vervolgens de AES-codering rechtstreeks op een stuk gegevens gebruikt ...

…dan elke keer dat je hetzelfde invoerblok krijgt, krijg je hetzelfde uitvoerblok.

Als een echt enorm codeboek

Daarom heet deze directe werkingsmodus ECB, kort voor elektronisch codeboek, omdat het een beetje lijkt op het hebben van een enorm codeboek dat kan worden gebruikt als een opzoektabel voor het versleutelen en ontsleutelen.

(Een volledig "codeboek" zou in het echte leven nooit kunnen worden geconstrueerd, omdat u een database zou moeten opslaan die bestaat uit 2¹²⁸ 16-byte ingangen voor elke mogelijke sleutel.)

Helaas is, vooral bij computergeformatteerde gegevens, herhaling van bepaalde stukjes gegevens vaak onvermijdelijk, dankzij het gebruikte bestandsformaat.

Bestanden die bijvoorbeeld routinematig gegevenssecties opvullen zodat ze op een lijn liggen op 512-byte-grenzen (een gebruikelijke sectorgrootte bij het schrijven naar schijf) of op 4096-byte-grenzen (een algemene toewijzingseenheidsgrootte bij het reserveren van geheugen) zullen vaak bestanden produceren met lange runs van nul bytes.

Evenzo zullen tekstdocumenten die veel boilerplate bevatten, zoals kop- en voetteksten op elke pagina, of herhaalde vermelding van de volledige bedrijfsnaam, overvloedige herhalingen bevatten.

Elke keer dat een herhaald stuk platte tekst zich toevallig op een 16-byte grens in het AES-ECB-coderingsproces bevindt, zal het daarom verschijnen in de gecodeerde uitvoer als exact dezelfde cijfertekst.

Dus zelfs als u het cijfertekstbestand formeel niet kunt ontcijferen, kunt u er mogelijk onmiddellijke, veiligheidsverpletterende gevolgtrekkingen uit maken, dankzij het feit dat patronen in de invoer (die u misschien kent, of kunt afleiden, of om te raden) worden bewaard in de uitvoer.

Hier is een voorbeeld op basis van een artikel dat we bijna negen jaar geleden publiceerden toen we uitlegden waarom Adobe's nu beruchte gebruik van ECB-modusversleuteling om de wachtwoorden van zijn gebruikers te "hashen" Geen goed idee:

Merk op hoe de pixels die effen wit zijn in de invoer op betrouwbare wijze een herhalend patroon in de uitvoer produceren, en de blauwe delen enigszins regelmatig blijven, zodat de structuur van de originele gegevens duidelijk is.

In dit voorbeeld neemt elke pixel in het originele bestand precies 4 bytes in beslag, dus elke van links naar rechts uitgevoerde 4-pixel die in de invoergegevens wordt uitgevoerd, is 16 bytes lang, wat precies overeenkomt met elk 16-byte AES-coderingsblok, waardoor de nadruk wordt gelegd op het “ECB-effect”.

---

Overeenkomende cijfertekstpatronen

Erger nog, als je twee documenten hebt waarvan je weet dat ze versleuteld zijn met dezelfde sleutel, en je hebt toevallig de leesbare tekst van een van hen, dan kun je door de cijfertekst kijken die je kan niet decoderen, en probeer delen ervan te matchen met patronen in de cijfertekst die u wel ontcijferen.

Onthoud dat je de sleutel niet nodig hebt om het eerste document te "ontsleutelen" als je het al in ontsleutelde vorm hebt - dit staat, niet verwonderlijk, bekend als een bekende aanval in platte tekst.

Zelfs als er maar een paar overeenkomsten zijn van ogenschijnlijk onschuldige tekst die zelf geen geheime gegevens zijn, kan de kennis die een tegenstander op deze manier kan extraheren een goudmijn zijn voor spionnen op het gebied van intellectueel eigendom, sociale ingenieurs, forensische onderzoekers en meer.

Zelfs als u bijvoorbeeld geen idee heeft waar de details van een document naar verwijzen, kunt u, door bekende platte tekst-brokken over meerdere bestanden te matchen, misschien vaststellen dat een schijnbaar willekeurige verzameling documenten:

• Allemaal naar dezelfde ontvanger gestuurd, als er een gemeenschappelijke begroeting bovenaan staat.
• Zie hetzelfde project, als er een unieke identificerende tekstreeks is die steeds verschijnt.
• Hebben dezelfde beveiligingsclassificatie, als je je graag wilt concentreren op de dingen die duidelijk "geheimer" moeten zijn dan de rest.

Wat te doen?

Gebruik de ECB-modus niet!

Als u een blokcijfer gebruikt, kiest u een bedrijfsmodus blokcijfer dat:

• Omvat een zogenaamde IV of initialisatievector, willekeurig en uniek gekozen voor elk bericht.
• Regelt bewust het encryptieproces zodat herhaalde invoer elke keer anders uitkomt.

Als je AES gebruikt, is de modus die je tegenwoordig waarschijnlijk wilt kiezen: AES-GCM (Galois Counter Mode), die niet alleen een IV gebruikt om elke keer een andere coderingsgegevensstroom te creëren, zelfs als de sleutel hetzelfde blijft, maar ook berekent wat bekend staat als een Verificatiecode bericht (MAC), of cryptografische controlesom, tegelijkertijd met het versleutelen of ontsleutelen van de gegevens.

AES-GCM betekent niet alleen dat u herhaalde cijfertekstpatronen vermijdt, maar ook dat u altijd een "controlesom" krijgt die u vertelt of er onderweg met de gegevens die u zojuist hebt gedecodeerd is geknoeid.

Onthoud dat een oplichter die niet weet wat de cijfertekst eigenlijk betekent, u toch kan misleiden om een ​​onnauwkeurige decodering te vertrouwen zonder ooit te weten (of zich zorgen te maken) met wat voor soort onjuiste uitvoer u eindigt.

Een MAC die wordt berekend tijdens het decoderingsproces, op basis van dezelfde sleutel en IV, zal ervoor zorgen dat u weet dat de cijfertekst die u hebt ontvangen geldig is, en daarom dat u vrijwel zeker hebt gedecodeerd wat er oorspronkelijk aan de andere kant was ingevoerd.

U kunt ook een speciale stream cijfer die een pseudo-willekeurige byte-by-byte keystream produceert waarmee u gegevens kunt versleutelen zonder dat u 16 bytes (of wat de blokgrootte ook mag zijn) tegelijk hoeft te verwerken.

AES-GCM zet AES in wezen om in een stream-codering en voegt authenticatie toe in de vorm van een MAC, maar als u op zoek bent naar een speciale stream-codering die speciaal is ontworpen om op die manier te werken, raden we Daniel Bernstein's ChaCha20-Poly1305 (het Poly1305-deel is de MAC), zoals beschreven in RFC 8439.

Hieronder hebben we laten zien wat we kregen met AES-128-GCM en ChaCha20-Poly1305 (we hebben de MAC-codes hier weggegooid), samen met een "afbeelding" bestaande uit 95,040 RGBA-bytes (330 × 72 bij 4 bytes per pixel) van de Linux-kernel pseudo-willekeurige generator.

Onthoud dat alleen omdat gegevens er ongestructureerd uitzien, niet betekent dat ze echt willekeurig zijn, maar als het er niet willekeurig uitziet, maar toch beweert versleuteld te zijn, kun je net zo goed aannemen dat er een structuur achterblijft en dat de codering is verdachte:

Wat gebeurt er nu?

Volgens WithSecure, Microsoft is niet van plan om deze "kwetsbaarheid" te verhelpen, blijkbaar om redenen van achterwaartse compatibiliteit met Office 2010...

Voor oudere versies van Office (2010) is AES 128 ECB vereist en Office-documenten worden nog steeds op deze manier beschermd door Office-apps.

…en…

Het rapport van [WithSecure-onderzoekers] werd niet beschouwd als het voldoen aan de lat voor beveiligingsservices en wordt ook niet als een inbreuk beschouwd. Er is geen codewijziging doorgevoerd en er is dus geen CVE uitgegeven voor dit rapport.

Kortom, als u momenteel op OME vertrouwt, kunt u overwegen deze te vervangen door een versleutelingstool van derden voor gevoelige berichten die uw gegevens versleutelt onafhankelijk van de apps die deze berichten hebben gemaakt, en dus onafhankelijk werkt van de interne versleuteling code in het Office-assortiment.

Op die manier kunt u een moderne codering en een moderne coderingsmodus kiezen, zonder terug te vallen op de ouderwetse decoderingscode die in Office 2010 is ingebouwd.

---

HOE WE DE AFBEELDINGEN IN HET ARTIKEL MAKEN Begin met sop330.png, die u voor uzelf kunt maken door het opgeschoonde SOPHOS-logo uit de bovenste afbeelding bij te snijden, de blauwe grens van 2 pixels te verwijderen en op te slaan in PNG-indeling.  De afbeelding moet eindigen op 330x72 pixels.
 Converteren naar RGBA met ImageMagick: $ convert sop330.png sop.rgba Uitvoer is 330x72 pixels x 4 bytes/pixel = 95,040 bytes.
 === Versleutel met Lua en de LuaOSSL-bibliotheek (Python heeft een zeer vergelijkbare 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') -- initialiseer wachtwoorden en IV's -- AES-128-ECB heeft een 128-bits wachtwoord nodig, maar geen IV -- AES-128-GCM heeft een 128-bits wachtwoord en een 12-byte IV nodig -- ChaCha20 heeft een 256-bits wachtwoord nodig en a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- versleutel de bestandsgegevens met de drie cijfers > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- een stroomcodering produceert byte-voor-byte uitvoer, -- dus cijfertekst moet dezelfde lengte hebben als platte tekst > gcmout:len() 95040 > chaout:len() 95040 -- we zullen hier niet de MAC-codes van GCM en Poly1305 gebruiken, -- maar elke cipher produceert een 128-bit (16-byte) "checksum" -- gebruikt om de decodering te verifiëren nadat deze is voltooid, -- om te detecteren of de ingevoerde gecodeerde tekst beschadigd of gehackt is -- (de MAC hangt af van de sleutel, dus een aanvaller kan het niet vervalsen) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -/outomd > maak een rechte / 95040 "afbeelding misc.filetostr('/dev/random',#fdat) -- sla ze allemaal op - merk op dat we de AES-ECB expliciet afkappen -- blokcijferuitvoer naar de exacte vereiste afbeeldingslengte, omdat -- ECB opvulling nodig heeft om overeen te komen met de invoergrootte met de blokgrootte > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === Om de bestanden in een gewone afbeeldingsviewer te laden, moet u ze mogelijk zonder verlies terug converteren naar PNG-indeling: $ 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 === Aangezien het coderingsproces alle vier de bytes in elke RGBA-pixel vervormt , de resulterende afbeelding heeft variabele transparantie (A = alpha, afkorting voor transparantie).
 Uw afbeeldingsviewer kan besluiten om dit soort afbeeldingen weer te geven met een schaakbordachtergrond, die verwarrend lijkt op een deel van de afbeelding, maar dat niet is.  We hebben daarom het Sophos-blauw van de originele afbeelding gebruikt als achtergrond voor de versleutelde bestanden om ze gemakkelijker te kunnen bekijken.  De algehele blauwe tint maakt daarom geen deel uit van de beeldgegevens.