Ernste Sicherheit: Angriff auf Microsoft Office 365 wegen schwacher Verschlüsselung

Wir sind uns im Moment nicht ganz sicher, wie wir es nennen sollen, also haben wir es in der Überschrift mit dem hybriden Namen bezeichnet Microsoft Office 365.

(Der Name „Office“ als Sammelbegriff für die Textverarbeitungs-, Tabellenkalkulations-, Präsentations- und Zusammenarbeits-Apps von Microsoft wird ausrotten in den nächsten ein bis zwei Monaten, um einfach „Microsoft 365“ zu werden.)

Wir sind sicher, dass die Leute weiterhin die individuellen App-Namen verwenden werden (Word, Excel, Powerpoint und Freunde) und den Spitznamen der Suite Office für viele Jahre, obwohl Neulinge in der Software es wahrscheinlich am Ende kennen werden 365, nachdem das allgegenwärtige Microsoft-Präfix gelöscht wurde.

Wie Sie vielleicht wissen, enthalten die eigenständigen Office-Apps (die Sie tatsächlich lokal installieren, damit Sie nicht online gehen müssen, um an Ihren Sachen zu arbeiten) eine eigene Option zum Verschlüsseln gespeicherter Dokumente.

Dies soll eine zusätzliche Sicherheitsebene hinzufügen, falls Sie später versehentlich oder absichtlich eine dieser Dateien mit jemandem teilen, der sie nicht erhalten sollte – etwas, das überraschend leicht versehentlich passiert, wenn Sie Anhänge per E-Mail teilen.

Sofern und bis Sie dem Empfänger auch das Passwort geben, das er zum Entsperren der Datei benötigt, ist es für ihn nur so viel zerkleinerter Kohl.

Wenn Sie das Passwort in den Text der E-Mail einfügen, haben Sie natürlich nichts gewonnen, aber wenn Sie auch nur ein wenig vorsichtig sind, das Passwort über einen anderen Kanal zu teilen, haben Sie sich zusätzliche Sicherheit und Schutz vor Schurken gekauft , Schnüffler und Taugenichtse erhalten einfachen Zugriff auf vertrauliche Inhalte.

OME im Rampenlicht

Oder hast du?

Laut Forscher Beim finnischen Cybersicherheitsunternehmen WithSecure genießen Ihre Daten möglicherweise viel weniger Schutz, als Sie vernünftigerweise erwarten könnten.

Die Funktion, die die Tester verwendeten, ist das, was sie bezeichnen Office 365-Nachrichtenverschlüsselung, oder OME kurz gesagt.

Wir haben ihre Experimente hier nicht reproduziert, aus dem einfachen Grund, dass die Kernprodukte von Office, sorry, 365 nicht nativ auf Linux laufen, das wir für die Arbeit verwenden. Die webbasierten Versionen der Office-Tools haben nicht denselben Funktionsumfang wie die vollständigen Apps, sodass die Ergebnisse, die wir möglicherweise erhalten, wahrscheinlich nicht mit der Konfiguration der meisten Geschäftsbenutzer von Office, äh, 365, Word, Excel, Outlook übereinstimmen und Freunde auf ihren Windows-Laptops.

Wie die Forscher es beschreiben:

Dieses Feature wird beworben, um es Organisationen zu ermöglichen, verschlüsselte E-Mail-Nachrichten zwischen Personen innerhalb und außerhalb Ihrer Organisation auf sichere Weise zu senden und zu empfangen.

Sie weisen aber auch darauf hin:

Leider werden die OME-Nachrichten im unsicheren Betriebsmodus des elektronischen Codebuchs (ECB) verschlüsselt.

EZB erklärt

Erklären.

Viele Verschlüsselungsalgorithmen, insbesondere die Advanced Encryption Standard oder AES, die OME verwendet, sind die sogenannten Blockchiffren, die große Datenblöcke gleichzeitig verwürfeln, anstatt einzelne Bits oder Bytes nacheinander zu verarbeiten.

Im Allgemeinen soll dies sowohl der Effizienz als auch der Sicherheit dienen, da die Chiffre bei jeder Drehung der kryptografischen Kurbel, die den Algorithmus antreibt, mehr Eingabedaten zum Mischen, Hacken, Schreddern und Liquidieren hat, und jede Drehung bringt Sie weiter durch die Daten, die Sie verschlüsseln möchten.

Der AES-Kernalgorithmus verbraucht beispielsweise 16 Eingabe-Klartext-Bytes (128 Bit) gleichzeitig und verschlüsselt diese Daten unter einem Verschlüsselungsschlüssel, um 16 verschlüsselte Chiffretext-Ausgabebytes zu erzeugen.

(Nicht verwechseln Block Größe mit Schlüsselgröße – AES-Verschlüsselungsschlüssel können 128 Bit, 192 Bit oder 256 Bit lang sein, je nachdem, wie unwahrscheinlich es sein soll, dass sie erraten werden, aber alle drei Schlüsselgrößen arbeiten jedes Mal auf 128-Bit-Blöcken, wenn der Algorithmus „gekurbelt“ wird.)

Das bedeutet, wenn Sie einen AES-Schlüssel (unabhängig von der Länge) auswählen und dann die AES-Chiffre direkt auf einen Datenblock anwenden …

…dann Jedes Mal, wenn Sie denselben Input-Chunk erhalten, erhalten Sie denselben Output-Chunk.

Wie ein wirklich riesiges Codebuch

Deshalb heißt diese direkte Betriebsart EZB, kurz für elektronisches Codebuch, weil es so ist, als hätte man ein riesiges Codebuch, das als Nachschlagetabelle zum Verschlüsseln und Entschlüsseln verwendet werden könnte.

(Ein vollständiges „Codebuch“ könnte im wirklichen Leben niemals erstellt werden, da Sie eine Datenbank speichern müssten, die aus 2¹²⁸ 16-Byte-Einträge für jeden möglichen Schlüssel.)

Leider ist insbesondere bei computerformatierten Daten die Wiederholung bestimmter Datenblöcke aufgrund des verwendeten Dateiformats oft unvermeidlich.

Beispielsweise erzeugen Dateien, die routinemäßig Datenabschnitte ausfüllen, sodass sie an 512-Byte-Grenzen (eine übliche Sektorgröße beim Schreiben auf die Festplatte) oder an 4096-Byte-Grenzen (eine übliche Größe der Zuordnungseinheit beim Reservieren von Speicher) ausgerichtet sind, häufig Dateien mit lange Folgen von null Bytes.

Ebenso werden Textdokumente, die viele Textbausteine ​​enthalten, wie Kopf- und Fußzeilen auf jeder Seite oder die wiederholte Erwähnung des vollständigen Firmennamens, reichlich Wiederholungen enthalten.

Jedes Mal, wenn ein wiederholter Klartext-Chunk im AES-ECB-Verschlüsselungsprozess zufällig an einer 16-Byte-Grenze auftaucht, taucht er daher in der verschlüsselten Ausgabe auf als genau derselbe Chiffretext.

Selbst wenn Sie also die Chiffretextdatei nicht formell entschlüsseln können, können Sie daraus möglicherweise sofortige, sicherheitszerstörende Rückschlüsse ziehen, dank der Tatsache, dass Muster in der Eingabe (die Sie vielleicht kennen oder ableiten können, oder zu erraten) werden in der Ausgabe beibehalten.

Hier ist ein Beispiel, das auf einem Artikel basiert, den wir vor fast neun Jahren veröffentlicht haben, als wir erklärten, warum Adobes mittlerweile berüchtigte Verwendung der ECB-Modus-Verschlüsselung zum „Hashen“ der Passwörter seiner Benutzer so war Keine gute Idee:

Beachten Sie, dass die durchgehend weißen Pixel in der Eingabe zuverlässig ein sich wiederholendes Muster in der Ausgabe erzeugen und die blauen Teile einigermaßen regelmäßig bleiben, sodass die Struktur der Originaldaten offensichtlich ist.

In diesem Beispiel nimmt jedes Pixel in der Originaldatei genau 4 Bytes ein, sodass jeder 4-Pixel-Lauf von links nach rechts in den Eingabedaten 16 Bytes lang ist, was genau mit jedem 16-Byte-AES-Verschlüsselungsblock übereinstimmt und somit akzentuiert Der „EZB-Effekt“.

---

Passende Chiffretextmuster

Schlimmer noch, wenn Sie zwei Dokumente haben, von denen Sie wissen, dass sie mit demselben Schlüssel verschlüsselt sind, und Sie zufällig den Klartext von einem davon haben, dann können Sie den verschlüsselten Text durchsehen, den Sie haben kann nicht entschlüsseln und versuchen, Teile davon mit Mustern in dem Chiffretext abzugleichen, den Sie haben kann entschlüsseln.

Denken Sie daran, dass Sie den Schlüssel zum „Entschlüsseln“ des ersten Dokuments nicht benötigen, wenn Sie es bereits in entschlüsselter Form haben – dies wird wenig überraschend als bekannter Klartextangriff.

Selbst wenn es nur wenige Übereinstimmungen mit scheinbar harmlosem Text gibt, die selbst keine geheimen Daten sind, kann das Wissen, das ein Angreifer auf diese Weise extrahieren kann, eine Goldgrube für Spione des geistigen Eigentums, Sozialingenieure, forensische Ermittler und mehr sein.

Selbst wenn Sie beispielsweise keine Ahnung haben, worauf sich die Details eines Dokuments beziehen, können Sie durch den Abgleich bekannter Klartext-Chunks in mehreren Dateien möglicherweise feststellen, dass eine scheinbar zufällige Sammlung von Dokumenten:

• Wurden alle an denselben Empfänger gesendet, wenn oben auf jedem eine gemeinsame Anrede steht.
• Verweisen Sie auf dasselbe Projekt, wenn es eine eindeutige identifizierende Textzeichenfolge gibt, die immer wieder auftaucht.
• die gleiche Sicherheitsklassifizierung haben, wenn Sie sich auf die Dinge konzentrieren möchten, die eindeutig „geheimer“ sein sollen als der Rest.

Was ist zu tun?

Verwenden Sie nicht den ECB-Modus!

Wenn Sie eine Blockchiffre verwenden, wählen Sie a Betriebsart der Blockchiffre dass:

• Enthält einen sogenannten IV- oder Initialisierungsvektor, zufällig und einzigartig für jede Nachricht ausgewählt.
• Arrangiert bewusst den Verschlüsselungsprozess sodass wiederholte Eingaben jedes Mal anders ausfallen.

Wenn Sie AES verwenden, möchten Sie heutzutage wahrscheinlich den Modus wählen AES-GCM (Galois Counter Mode), der nicht nur mit einem IV jedes Mal einen anderen verschlüsselten Datenstrom erzeugt, auch wenn der Schlüssel gleich bleibt, sondern auch einen sogenannten a berechnet Nachrichtenauthentifizierungscode (MAC) oder kryptografische Prüfsumme, gleichzeitig mit dem Verschlüsseln oder Entschlüsseln der Daten.

AES-GCM bedeutet nicht nur, dass Sie sich wiederholende Chiffretextmuster vermeiden, sondern auch, dass Sie am Ende immer eine „Prüfsumme“ erhalten, die Ihnen sagt, ob die gerade entschlüsselten Daten unterwegs manipuliert wurden.

Denken Sie daran, dass ein Gauner, der nicht weiß, was der Chiffretext tatsächlich bedeutet, Sie dennoch dazu bringen kann, einer ungenauen Entschlüsselung zu vertrauen, ohne jemals zu wissen (oder sich darum zu kümmern), welche Art von falscher Ausgabe Sie erhalten.

Ein MAC, der während des Entschlüsselungsprozesses basierend auf demselben Schlüssel und IV berechnet wird, hilft sicherzustellen, dass Sie wissen, dass der erhaltene Chiffretext gültig ist und Sie daher mit ziemlicher Sicherheit entschlüsselt haben, was ursprünglich am anderen Ende eingegeben wurde.

Verwenden Sie alternativ eine dedizierte Stream Chiffre Dadurch wird ein pseudozufälliger Byte-für-Byte-Schlüsselstrom erzeugt, mit dem Sie Daten verschlüsseln können, ohne 16 Bytes (oder was auch immer die Blockgröße sein mag) gleichzeitig verarbeiten zu müssen.

AES-GCM wandelt AES im Wesentlichen in eine Stream-Chiffre um und fügt eine Authentifizierung in Form eines MAC hinzu, aber wenn Sie nach einer dedizierten Stream-Chiffre suchen, die speziell dafür entwickelt wurde, empfehlen wir die von Daniel Bernstein ChaCha20-Poly1305 (der Poly1305-Teil ist der MAC), wie in beschrieben RFC 8439.

Unten haben wir gezeigt, was wir mit AES-128-GCM und ChaCha20-Poly1305 erhalten haben (wir haben die MAC-Codes hier verworfen), zusammen mit einem „Bild“, das aus 95,040 RGBA-Bytes (330 × 72 bei 4 Bytes pro Pixel) besteht Linux-Kernel-Pseudozufallsgenerator.

Denken Sie daran, nur weil Daten unstrukturiert aussehen, bedeutet das nicht, dass sie wirklich zufällig sind, aber wenn sie nicht zufällig aussehen, aber behaupten, verschlüsselt zu sein, können Sie genauso gut davon ausgehen, dass eine Struktur zurückbleibt und dass die Verschlüsselung ist vermuten:

Was passiert als nächstes?

Laut WithSecure, Microsoft plant nicht, diese „Schwachstelle“ zu beheben, anscheinend aus Gründen der Abwärtskompatibilität mit Office 2010…

Legacy-Versionen von Office (2010) erfordern AES 128 ECB, und Office-Dokumente werden weiterhin auf diese Weise von Office-Apps geschützt.

…und…

Der Bericht [von WithSecure-Forschern] wurde nicht als Erfüllung der Messlatte für Sicherheitsdienste angesehen und wird auch nicht als Verstoß angesehen. Es wurde keine Codeänderung vorgenommen und daher wurde für diesen Bericht kein CVE ausgegeben.

Kurz gesagt, wenn Sie sich derzeit auf OME verlassen, sollten Sie erwägen, es durch ein Verschlüsselungstool eines Drittanbieters für vertrauliche Nachrichten zu ersetzen, das Ihre Daten unabhängig von den Apps verschlüsselt, die diese Nachrichten erstellt haben, und somit unabhängig von der internen Verschlüsselung funktioniert Code im Office-Bereich.

Auf diese Weise können Sie eine moderne Verschlüsselung und einen modernen Verschlüsselungsmodus auswählen, ohne auf den in Office 2010 integrierten Entschlüsselungscode der alten Schule zurückgreifen zu müssen.

---

WIE WIR DIE BILDER IN DEM ARTIKEL ERSTELLT HABEN Beginnen Sie mit sop330.png, das Sie selbst erstellen können, indem Sie das bereinigte SOPHOS-Logo aus dem obersten Bild zuschneiden, die blaue 2-Pixel-Grenze entfernen und im PNG-Format speichern.  Das Bild sollte am Ende eine Größe von 330 x 72 Pixel haben.
 Mit ImageMagick in RGBA konvertieren: $ convert sop330.png sop.rgba Die Ausgabe beträgt 330 x 72 Pixel x 4 Bytes/Pixel = 95,040 Bytes.
 === Verschlüsseln mit Lua und der LuaOSSL-Bibliothek (Python hat eine sehr ähnliche OpenSSL-Bindung): -- Daten laden > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- Cipher-Objekte erstellen > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- Passwörter und IVs initialisieren -- AES-128-ECB benötigt ein 128-Bit-Passwort, aber kein IV -- AES-128-GCM benötigt ein 128-Bit-Passwort und ein 12-Byte-IV -- ChaCha20 benötigt ein 256-Bit-Passwort und a 12-Byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- verschlüsselt die Dateidaten mit den drei Chiffren > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- eine Stream-Chiffre erzeugt byteweise Ausgabe, -- also sollte der Chiffretext die gleiche Länge wie der Klartext haben > gcmout:len() 95040 > chaout:len() 95040 -- wir werden hier nicht die MAC-Codes von GCM und Poly1305 verwenden, -- aber Jede Chiffre erzeugt eine 128-Bit (16-Byte) "Prüfsumme" -- wird verwendet, um die Entschlüsselung nach Abschluss zu authentifizieren, -- um zu erkennen, ob der eingegebene Chiffretext beschädigt oder gehackt wird -- (der MAC hängt vom Schlüssel ab, so ein Angreifer kann es nicht fälschen) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- erstellt ein 95040 "Image" direkt aus /dev/random > rndout = misc.filetostr('/dev/random',#fdat) -- speichere sie alle - beachte, dass wir die AES-ECB -- Blockverschlüsselungsausgabe ausdrücklich auf die genaue benötigte Bildlänge kürzen, weil -- ECB Padding benötigt, um mit dem übereinzustimmen Eingabegröße mit der Blockgröße > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === Um die Dateien in einem normalen Bildbetrachter zu laden, müssen Sie sie möglicherweise verlustfrei zurück in das PNG-Format konvertieren: $ convert -depth 8 -size 330x72 aes .rgba aes.png $ konvertieren -Tiefe 8 -Größe 330x72 gcm.rgba gcm.png $ konvertieren -Tiefe 8 -Größe 330x72 cha.rgba cha.png $ konvertieren -Tiefe 8 -Größe 330x72 rnd.rgba rnd.png === Da der Verschlüsselungsprozess alle vier Bytes in jedem RGBA-Pixel verschlüsselt , hat das resultierende Bild eine variable Transparenz (A = Alpha, kurz für Transparenz).
 Ihr Bildbetrachter entscheidet sich möglicherweise dafür, diese Art von Bild mit einem Schachbretthintergrund anzuzeigen, der verwirrenderweise wie ein Teil des Bildes aussieht, es aber nicht ist.  Wir haben daher das Sophos-Blau aus dem Originalbild als Hintergrund für die verschlüsselten Dateien verwendet, um sie besser sichtbar zu machen.  Der gesamte Blauton ist daher nicht Bestandteil der Bilddaten.