Poodle: So funktioniert der Angriff auf die Verschlüsselung

Der neue Angriff auf Internet-Verschlüsselung kann nicht einfach alle verschlüsselten Daten dechiffrieren. Doch wenn einige Voraussetzungen erfüllt sind, kann der Angreifer durchaus etwa einen Online-Banking-Zugang kapern.

Der Poodle-Angriff richtet sich gegen verschlüsselte Internet-Verbindungen; der Angreifer muss sich dazu grundsätzlich in der Position eines Man in the Middle (MitM) befinden, bei dem alle Netzwerk-Pakete vorbei kommen. Das kann also die NSA mit einem entsprechenden Zugang am Internet-Knoten oder die nette junge Frau mit dem Laptop am Tisch nebenan sein, die ins gleiche WLAN eingebucht ist, wie Sie. Das Erzwingen von SSLv3 funktioniert deshalb, weil nahezu alle Server und Clients das noch als Fallback unterstützen und sich von der Gegenstelle darauf herunter handeln lassen.Verweigert eine der beiden Seiten den Einsatz von SSLv3, ist der Angriff nicht möglich.

Außerdem muss der Angreifer Script-Code auf dem Gerät des Opfers ausführen können. Den kann er als MitM etwa in eine unverschlüsselte Web-Seite einbauen, die der Anwender gerade öffnet. Er ist allerdings dann darauf angewiesen, dass der auch tatsächlich ausgeführt wird. Das dürfte bei den meisten Browsern der Fall sein; bei einem Mail-Programm oder dem Twitter-Client des Smartphones jedoch eher nicht.

Das Problem MAC-than-encrypt
Der MAC-Wert bezieht das Padding nicht mit ein.

Basis der SSLv3-Schwäche ist die Tatsache, dass Secure Socket Layer mehrere Aufgaben hat: Es soll die Daten nicht nur verschlüsseln sondern auch deren Integrität sicherstellen – also nachträgliche Änderungen verhindern. Letzteres geschieht über einen so genannten Message Authentication Code (MAC). Die Erfinder des Protokolls mussten sich damals entscheiden, in welcher Reihenfolge das passieren soll und legten sich auf das sogenannte MAC-then-encrypt fest. Dabei wird zunächst an die zu schützenden Klartextdaten der daraus berechnete MAC angehängt und das ganze dann erst verschlüsselt. Dieses MAC-then-encrypt hat sich seither als eine regelmäßige Quelle von Problemen erwiesen.

Das hat damit zu tun, dass Verschlüsselung sehr oft in Blöcken fester Länge passiert – etwa im Cipher Block Chaining (CBC) mit AES oder 3DES. Da die Länge der Daten nur selten exakt ein Vielfaches der Blockgröße ist, hängt man eben hinter dem MAC noch etwas dran, um den Block auf eine passende Länge aufzufüllen – das sogenannte Padding. Das wird zwar mit verschlüsselt, ist aber nicht durch den MAC geschützt. Anders als beim Nachfolger TLS 1.0 kann ein Angreifer das Padding sogar fast frei wählen; der Empfänger ignoriert die angehängten Daten einfach. Nur das letzte Byte muss die Länge des Paddings korrekt angeben – also zum Beispiel 15 Bytes. Mit einer falschen Längenangabe liest der Empfänger den MAC an der falschen Stelle und dessen Überprüfung schlägt fehl.
Beim Cipher Block Chaining werden immer Blöcke fester Größe verschlüsselt.
Bild: Wikipedia

Der Angriff funktioniert so, dass der Angreifer als MitM Script-Code in eine Web-Seite einschleust. Der feuert dann sehr viele, fast identische HTTPS-Anfragen an einen Server wie https://meinebank.com ab, die der Browser automatisch mit dem zugehörigen meinebank-Cookie versieht. Der Angreifer weiß dabei, welcher der verschlüsselten Blocks das Cookie enthält, kann den aber erstmal nicht dechiffrieren. In seiner Position als MitM kopiert er diesen Block an das Ende der SSL-Daten, wo normalerweise das verschlüsselte Padding steht.

Durchprobiert

Die Gegenstelle wird diese Daten genau dann akzeptieren, wenn das letzte Byte dekodiert die richtige Länge – im obigen Beispiel also den Wert 15 ergibt. Denn aus diesem Wert ermittelt sie die Position des MAC. Nimmt der Server das Paket also an, weiß der Angreifer, dass dieses Byte des Cookies den Wert 15 hat. Er kann damit sogar systematisch testen: Beschwert sich der Server über einen falschen MAC, probiert der Angreifer einen anderen Wert und sorgt für ein Padding der Länge 14. Außerdem kann er die Position des Cookies innerhalb der Blöcke verschieben und somit andere Bytes testen. Mit ein paar tausend geringfügig variierten https-Anfragen kann der Angreifer auf diesem Weg alle Bytes des Cookies ermitteln. Genauer erklärt Googles Krypto-Spezialist Adam Langley dieses Padding Oracle.

Der Angreifer kann also nicht die ganze SSLv3-Verbindung dechiffrieren sondern Byte-weise ausgewählte Teile davon. Doch mit dem Session-Cookie aus der verschlüsselten https-Verbindung, kann er etwa eine gerade offene Sitzung des Anwenders kapern oder sogar dessen Account komplett übernehmen und damit bereits einigen Schaden anrichten.

Richtig rum

Heute ist klar, dass encrypt-then-MAC, also Verschlüsseln und dann Sichern die bessere Wahl für SSL/TLS gewesen wäre. Doch dieses Wissen stand den Designern des Protokolls damals nicht zur Verfügung und wir müssen heute mit dessen Schwächen leben. TLS 1.0 macht übrigens ebenfalls noch das fatale Mac-then-encrypt und war deshalb auch bereits für BEAST- und Lucky13-Attacken anfällig. Allerdings darf da das Padding nicht frei gewählt werden, sodass zumindest der Poodle-Angriff mit TLS 1.0 nicht möglich ist. Wirklich beseitigt werden diese Probleme erst mit TLS-Version 1.2 durch Authenticated Encryption, bei der Verfahren wie der Galois/Counter Mode (GCM) Integritätsschutz und Verschlüsselung zusammenführen. Wie Sie sich jetzt schon schützen, erklärt der Artikel So wehren Sie Poodle-Angriffe ab (ju)