Dipl.-Inform. Carsten Eilers

Bei einem "block-wise chosen-plaintext"-Angriff kann der Angreifer blockweise Klartexte seiner Wahl verschlüsseln lassen. Aus dem ihm bekannten Klartext und dem beobachteten Schlüsseltext lässt sich dann auf die verwendete Entropie schließen. Dadurch reduziert sich der Aufwand zum Brechen der Verschlüsselung gewaltig. Gregory V. Bard hat sowohl die Schwachstelle in SSL (PDF) als auch einen Angriff darauf (PDF) bereits 2004 und 2006 beschrieben, außerdem gibt es eine Zusammenstellung der Schwachstellen in SSL und TLS 1.0 z.B. von Bodo Möller.

Bisher wurden weder der BEAST-Code noch das Paper dazu veröffentlicht. Es gibt lediglich ein Video der Live-Demo des Angriffs und eine Vorversion des Papers in Mozillas Bugzilla.

BEAST besteht aus zwei Teilen: JavaScript-Code oder Java-Applets, die im Browser des Opfers eingeschleust werden und präparierte Daten in die verschlüsselte Verbindung einschleusen, und einem Sniffer, der die z.B. über WLAN übertragenen Daten belauscht. Was genau dabei passiert, ist bisher relativ unklar. Inoffizielle Beschreibungen gibt es z.B. im Opera Security Blog, im Tor Blog und auf ImperialViolet.

Der Angriff, allgemein

Blockchiffren wie z.B. DES oder AES werden in verschiedenen Betriebsarten betrieben. In diesem Fall wird die Betriebsart "Cipher-Block Chaining" (CBC) angegriffen, die mit AES eingesetzt wird. Bei dieser "Blockchiffre mit Blockverkettung" wird vor dem Verschlüsseln jedes außer des ersten Blocks der Schlüsseltext des vorhergehenden Blocks zum Klartext modular addiert und beim Entschlüsseln entsprechend subtrahiert. Dadurch wird verhindert, dass ein Angreifer erkennt, wenn zwei identische Klartextblöcke verschlüsselt werden. Da es für den ersten Block keinen vorhergehenden Schlüsseltext gibt, kann ein Angreifer erkennen, ob zwei Klartexte mit den gleichen Blöcken beginnen. Um dies zu verhindern, wird der Zwischenspeicher mit einem zufälligen Wert initialisiert. Beim "block-wise chosen-plaintext"-Angriff wird durch das Einfügen präparierter Klartext-Blöcke auf den Klartext anderer Blöcke geschlossen. Konkret hat BEAST es dabei auf Session-Cookies abgesehen, die bei jedem Request automatisch an den Webserver geschickt werden. Indem der Reihe nach entsprechende Klartext-Blöcke eingefügt werden, kann nach und nach Zeichen für Zeichen des Cookies ermittelt werden (Opera Security Blog, Tor Blog und ImperialViolet).

Für einen Angriff müssen also eine Reihe von Voraussetzungen erfüllt sein:

• Der Angreifer muss die Netzwerkverbindung des Opfers beobachten können, z.B. in einem offene WLAN.
• Der Angreifer muss seinen Code in den Browser des Opfers einschleusen können.
• Der eingeschleuste Code des Angreifers muss HTTPS-Requests abschicken können.
• Nach dem Belauschen des erzeugten Requests müssen an diesen Request weitere Daten angehängt werden können.

Juliano Rizzo und Thai Duong konnten diese Voraussetzungen nach einigen Vorarbeiten erfüllen. Mit BEAST ist es möglich, auch die beim Einschleusen des Codes in den Browser bereits vorhandenen Cookies auszuspähen. Der eingeschleuste Code selbst hat keinen Zugriff darauf, da sie als HTTP-only markiert sind. Demonstriert wurde das Tool dann am Beispiel von PayPal. Nicht, weil diese Website eine Schwachstelle enthält, sondern gerade weil dort eigentlich alles richtig gemacht wird. Trotzdem kann der Session-Cookie von BEAST ausgespäht werden - und das in unter 3 Minuten. Und dabei geht es nicht um das einfache Lesen irgend welcher Daten im Browser, der Cookie wird aus den verschlüsselt übertragenen Daten extrahiert.

Gegenmaßnahmen problematisch

Die einfachste Gegenmaßnahmen bestünde darin, auf den Einsatz von SSL und TLS 1.0 zu verzichten. In TLS 1.1 wird der Angriff durch den Einsatz individueller Initialisierungsvektoren verhindert. Leider ist das weder auf Client- noch auf Server-Seite so einfach, da sehr viele Webserver noch auf diese alten Versionen setzen und auch manche Browser Probleme mit neueren Versionen haben.

Auch bei der Implementierung von alternativen Lösungen, zum Beispiel dem Einfügen leerer Blöcke, gibt es immer wieder Kompatibilitätsprobleme mit einigen Websites, wie z.B. Opera und Google für ihre Lösungen festgestellt haben. Die Firefox-Entwickler überlegen, an den Symptomen herum zu doktoren und das Java-Plugin zu blockieren. Das behebt natürlich nicht das eigentliche Problem, lediglich der von BEAST genutzter Angriffsvektor wird blockiert. Microsoft arbeitet an einem Update und hat vorerst ein Security Advisory veröffentlicht, in dem verschiedene Workarounds vorgeschlagen werden, z.B. die Priorisierung des RC4-Algorithmus und das Aktivieren von TLS 1.1 und/oder 1.2. Für letzteres stehen Fix it-Tools bereit.

Auch PhoneFactor schlägt vor, dass die Server RC4-SHA statt AES oder Triple-DES als Ciphersuite verwenden. Dann wird die CBC-Betriebsart nicht verwendet, und der Angriff läuft ins Leere. Ein Whitepaper beschreibt die nötigen Anpassungen.

Eine Übersicht der möglichen Gegenmaßnahmen sowie von Informationen über den Angriff hat Thierry Zoller zusammengestellt, die Browserhersteller diskutieren mögliche Lösungen im Eintrag in Mozillas Bugzilla.

Ein generelles Problem aller Gegenmaßnahmen, egal ob auf Client- oder Server-Seite, ist die Vielzahl vorhandener Protokollversionen und Konfigurationsoptionen. Bei jeder Änderung am vorhandenen Status besteht die Gefahr, Teile der Browser oder Websites nicht mehr zu unterstützen. Und das Risiko wollen natürlich weder Browserhersteller noch Website-Betreiber eingehen.

Wie gross ist die Gefahr?

Wie schon erwähnt, handelt es sich nicht um eine neue Schwachstelle, sondern "nur" um einen neuen Angriff auf eine seit langem bekannte (und eigentlich längst behobene) Schwachstelle. Nur wurde so ein Angriff bisher als nicht durchführbar angesehen, so dass ein Update auf TLS 1.1 oder höher nicht für notwendig gehalten wurde. Das ist nun anders. Die Gefahr eines erfolgreichen Angriffs ist m.E. gering. Ein Angreifer, der Code in den Browser des Opfers einschleusen kann, kann anderweitig mehr Schaden anrichten. BEAST ist nur dann interessant, wenn ein bereits vorhandener Cookie ausgespäht werden soll, und nur dann durchführbar, wenn die Voraussetzungen erfüllt sind. Bisher gab es nur eine Demonstration unter (mehr oder weniger) Laborbedingungen, Angriffe "in the wild" sind (natürlich) noch nicht beobachtet worden. Dafür ist der Angriff auch noch zu neu und es ist zu wenig darüber bekannt. Juliano Rizzo und Thai Duong haben auch einige Zeit gebraucht, um ihren Angriff zu entwickeln. Trotzdem sollten natürlich Gegenmaßnahmen ergriffen werden. Ab besten wäre es, alle Server würden mindestens auf TLS 1.1 "upgraden" - und alle Webbrowser würden diesen Standard dann auch unterstützen. Bis es soweit ist, muss man sich mit Notlösungen behelfen, z.B. dem Einsatz von RC4 statt AES/Triple-DES im CBC-Modus.

In der nächsten Folge geht es um einen neuen Angriff auf DSL-Router und Kabelmodems.

Carsten Eilers

Übersicht über alle Artikel zum Thema

WEP, WPA, WPA2 - WLAN-Schutz, aber richtig!

"Hole196" - Eine neue Schwachstelle in WPA2

DNS-Rebinding - Ein altbekannter Angriff kompromittiert Router

Von außen durch den Client in den Router

Ciscos "WPA Migration Mode" öffnet den Weg ins WLAN

NAT-Pinning, Angriffe auf Cisco-WLANs und ein Tool

Angriffe auf den WLAN-Client

BEAST - Ein neuer Angriff auf SSL und TLS 1.0

Konfigurationsänderungen am Router per UPnP - aus dem Internet

WLAN-Sicherheit - Stand der Dinge

WPS-Schwachstelle gefährdet WLANs