Dipl.-Inform. Carsten Eilers

Der neue Angriff wurde von Bodo Möller, Thai Duong und Krzysztof Kotowicz von Google entdeckt und am 14. Oktober in einem Security Advisory (PDF) veröffentlicht.

Die Schwachstelle befindet sich im Protokoll selbst und betrifft dadurch alle SSL-nutzenden Implementierungen. Für OpenSSL hat sie die CVE-ID CVE-2014-3566 erhalten, dort wurde sie in Version 1.0.1j, 1.0.0o und 0.9.8zc durch die Implementierung von TLS_FALLBACK_SCSV (dazu unten mehr) verhindert.

SSLv3 wurde als "historical record" in RFC 6101 dokumentiert, da es nie offiziell als Standard veröffentlicht wurde.

Poodle ist die Abkürzung von "Padding Oracle On Downgraded Legacy Encryption" und nutzt wie der 2011 vorgestellte BEAST-Angriff das nicht ausreichend gesicherte Padding des CBC-Modus.

Ein Poodle-Angriff besteht wie oben schon erwähnt aus zwei Schritten: Zuerst erzwingt der Angreifer durch die Manipulation des Verbindungsaufbaus den Rückfall auf die Verwendung von SSLv3. Danach kann er die Schwachstellen darin ausnutzen, um Teile der verschlüsselt ausgetauschten Daten zu entschlüsseln.

Der Angriff ist nur möglich, wenn sich der Angreifer als Man-in-the-Middle in der Verbindung zwischen Client und Server befindet. Was zum Beispiel in einem offenen WLAN schnell passieren kann, von den Möglichkeiten von NSA und Co. ganz zu schweigen.

Schritt 1: Fallback auf SSLv3 provozieren

Um auch mit veralteten Servern kommunizieren zu können ist in den meisten TLS-Client ein "Downgrade Dance" implementiert: Im ersten Handshakeversuch wird die höchste vom Client unterstützte Protokollversion vorgeschlagen. Schlägt der Handshake fehl, wird die nächstniedrige unterstützte Protokollversion vorgeschlagen, und das so lange, bis der Server zustimmt (oder der Client keinen Vorschlag mehr zu machen hat und keine verschlüsselte Verbindung zu Stande kommt).

Anders als bei einer korrekten Aushandlung der Protokollversion, bei der zum Beispiel der Client TLS 1.2 vorschlägt und der Server mit TLS 1.0 antwortet, kann der Downgrade auch durch Netzwerkfehler ausgelöst werden. Oder einem Angreifer, der die Vorschläge des Servers unterdrückt, bis der Client freiwillig SSLv3 vorschlägt. Diesen Vorschlag lässt der Angreifer dann zu, so dass die Verbindung mit SSLv3 aufgebaut wird. Da sieht dann ungefähr so aus:

Schritt 2: Angriff auf die Verschlüsselung

Die Verschlüsselung in SSL 3.0 erfolgt entweder mit der Stream-Cipher RC4, die einige bekannte Schwachstellen enthält, oder einer Block-Cipher im CBC-Mode (Cipher-Block Chaining). Der neu entwickelte Angriff richtet sich gegen diese "Blockchiffre mit Blockverkettung" und setzt ebenso wie der 1. Schritt voraus, dass der Angreifer die Netzwerkverbindung manipulieren kann.

Bei einer Blockverschlüsselung müssen Daten, die kürzer als die verarbeitete Blocklänge bzw. Blockanzahl sind, auf die nötige Länge aufgefüllt werden ("Padding"). Das Problem der CBC-Verschlüsselung in SSL 3.0 besteht darin, dass dieses Padding nicht deterministisch ist und nicht vom MAC (Message Authentication Code) abgedeckt wird, mit dem ansonsten eine Manipulation der Daten erkannt wird. Dies führt dazu, dass die Integrität des Paddings bei der Entschlüsselung nicht geprüft werden kann.

Der Empfänger ignoriert das Padding, lediglich das letzte Byte muss die korrekte Länge des Paddings enthalten, da darüber die Position des MAC bestimmt wird. Stimmt diese Längenangabe nicht, wird der MAC von der falschen Stelle gelesen, also ein falscher Wert als MAC verwendet, und dessen Überprüfung schlägt natürlich fehl.

Für den Angriff muss der Angreifer JavaScript-Code in den Browser des Opfers einschleusen, was ihm als MitM ja problemlos möglich ist. Dieser Code sendet dann präparierte HTTPS-Requests an die Website, deren Session-Cookie ermittelt werden soll. Der Browser fügt den Requests automatisch den Cookie des Servers hinzu.

Diese Requests sind so konstruiert, dass das Padding einen ganzen Block ausfüllt (= den letzten) und das jeweils erste bisher unbekannte Byte des Cookies das letzte Byte eines vorhergehenden Blocks ist. Die Länge des Cookies ist dem Angreifer zwar zuerst unbekannt, er kann aber durch das Senden der Requests GET /, GET /A, GET /AA, ... feststellen, an welchem Punkt die Block-Grenze überschritten wird. Spätestens nach 16 solcher Requests ergibt sich die Padding-Größe und damit auch die Größe des Cookies.

Der Angreifer kann den Request nicht entschlüsseln, weiß aber, wie die Requests aufgebaut sind und welcher der verschlüsselten Blöcke das gewünschte Byte des Cookie als letztes Byte enthält. Diesen Block kopiert er nun ans Ende des verschlüsselten Requests an die Stelle, an der normalerweise das verschlüsselte Padding steht.

Der Server akzeptiert den Request nur, wenn das letzte Byte dekodiert die richtige Länge ergibt. In den meisten Fällen wird das nicht zutreffen und der Server den Request abweisen. Dann wird der Request abgeändert, so dass sich die Länge des Paddings ändert, und damit ein neuer Wert getestet. Das wird so lange wiederholt, bis der Request akzeptiert wird. Akzeptiert der Server den Request, weiß der Angreifer, dass der Wert des gesuchten Cookie-Bytes der aktuellen Länge des Paddings entspricht. Danach wird der Request so geändert, dass der Cookie um ein Byte weiter rückt, und damit das nächste Byte des Cookies ermittelt. Nach ein paar Tausend Abfragen ist dann der komplette Cookie ermittelt.

Wie schon beim BEAST-Angriff kann nicht die gesamte Verbindung entschlüsselt werden, sondern nur ausgewählte Teile davon. Aber das reicht schon für einen gefährlichen Angriff, denn mit dem ausgespähten Session-Cookie kann der Angreifer die laufende Session des Benutzers übernehmen. Und danach dann unter Umständen auch den kompletten Account des Benutzers.

Poodle-Angriffe abwehren

Die Abwehr der Angriffe ist eigentlich ganz einfach: Es muss nur auf die Verwendung von SSLv3 verzichtet werden. Da das aus Kompatibilitätsgründen nicht immer möglich ist, kann der TLS_FALLBACK_SCSV-Mechanismus (aus dem IETF-Draft TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) genutzt werden, der das Problem des "Downgrade Dance" generell löst.

Mit TLS_FALLBACK_SCSV wird von Clients in Fallback-Handshakes eine Kennung mitgeschickt, an der der Server einen Downgrade-Angriff erkennen kann. Auf der Server-Seite wird beim Erkennen dieser Kennung dafür gesorgt, dass nur die höchste vom Server unterstützte Protokollversion ausgehandelt werden kann. Der Versuch, eine niedrigere Version zu vereinbaren, löst einen "Fatal Alert" aus. Damit wird sicher gestellt, dass SSL 3.0 nur noch verwendet wird, wenn eine veraltete Implementierung wirklich kein neueres Protokoll unterstützt.

Kommen wir nun zur Unterstützung von SCSV und/oder dem Ausschalten von SSL 3.0:

Clients

• In Chrome ist TLS_FALLBACK_SCSV seit Februar (Chrome 33) implementiert.
  Wer SSL 3.0 in Chrome komplett ausschalten möchte, kann dafür das Kommandozeilen-Flag --ssl-version-min=tls1 verwenden.
• Im Firefox wird TLS_FALLBACK_SCSV erst in Version 35 implementiert, aber der Angriff wird schon in Firefox 34, der am 25. November veröffentlicht werden soll, durch das Entfernen von SSL 3.0 verhindert.
  Wer nicht so lange warten will, kann SSL 3.0 schon jetzt über die Erweiterung SSL Version Control oder manuell in der Konfiguration (about:config aufrufen und die Option security.tls.version.min auf 1 setzen) ausschalten.
• Wie man SSL 3.0 im Internet Explorer und Windows ausschaltet hat Microsoft in einem Security Advisory beschrieben. Im Internet Explorer wird dazu in den "Internetoptionen" im Reiter "Erweitert" der Haken vor der Option "SSL 3.0 verwenden" entfernt, außerdem kann SSL 3.0 über die Group Policy ausgeschaltet werden. In Windows erfolgt das Ausschalten durch eine Manipulation der Registry.
• Für Safari ist bisher keine Möglichkeit bekannt, um SSL 3.0 aus zu schalten.

Server

• TLS_FALLBACK_SCSV wurde in OpenSSL 1.0.1j, 1.0.0o und 0.9.8zc zur Verhinderung des Poodle-Angriffs implementiert.
• Im Apache httpd mit mod_ssl kann über die SSLProtocol Directive SSLProtocol All -SSLv2 –SSLv3 SSL 2.0 und 3.0 ausgeschaltet werden.
• In nginx kann über den Befehl ssl_protocols TLSv1 TLSv1.1 TLSv1.2 SSL 2.0 und 3.0 ausgeschaltet werden.
• Für den IIS 7 gibt es hier eine Anleitung zum Ausschalten von SSL 2.0 und 3.0.
• Für Windows Server 2008/2012 und Azure SSL/TLS gibt es hier eine Anleitung zum Härten samt Hinweisen zum Ausschalten von SSL 3.0.

Anleitungen für weitere Server und Dienste gibt es in diesem Eintrag im InfoSec Handlers Diary Blog des ISC. Weiter Anleitungen, zum Teil auch Copy&Paste-fähig, gibt es im Applied Crypto Hardening Guide (PDF) von BetterCrypto*org.

Tests - Ist eine Website oder ein Browser betroffen?

Webserver können über den SSL Server Test der Qualys SSL Labs getestet werden, der an den Poodle-Angriff angepasst wurde.

Ob ein Webbrowser betroffen ist, verrät die Website "SSLv3 Poodle Attack Check" des ISC, einmal mit JavaScript und einmal ohne. Auch der Client-Test der Qualys SSL Labs wurde an den Poodle-Angriff angepasst.

Carsten Eilers