TC Blog

SSL/TLS-Renegotiation-Schwachstelle – Erklärung und Auswirkungen

17. November 2009 Kategorien:

Heiwei, was hat die SSL/TLS Schwachstelle Wellen geschlagen. Wenn man die Berichterstattung verfolgt, sich in Foren tummelt und Kundenanfragen hierzu bekommt wird klar: Aufklärung ist notwendig. Wie funktioniert die Schwachstelle und welche Auswirkungen hat sie.
Hinweis: Dieser Artikel fußt natürlich auf diversen Informationsquellen, insbesondere dem originalen Dokument mit der Beschreibung der Schwachstelle, diese sind am Ende gelistet.

Die meisten interessieren sich für die Auswirkungen, daher die
Zusammenfassung
vorab:
Mit den neuartigen Angriffen ist es möglich, dass ein Angreifer bestimmt, welche Anfrage an einen Server gesendet wird. Dies ist nur in einem Man-in-the-Middle Szenario möglich. Durch den neuen Angriffsvektor ist es dem Angreifer jedoch zu keinem Zeitpunkt möglich:

• die ursprüngliche Anfrage im Klartext zu sehen
• die Antwort im Klartext zu sehen
• Antwortdaten zu verändern

Allerdings

ist es ihm ggf. durch Schwachstellen der Webanwendung und dem Zweck der Webanwendung, auf die ein Client zugreift möglich Transaktionen durchzuführen oder Daten zu versenden (siehe Beispiele).

Wie funktioniert’s?
Leider sind zunächst einige technische Grundlagen nötig:

Session Renegotiation
Kurzbeschreibung: Erstellt einen neuen kryptographischen Kontext.
Beschreibung: Nach dem Aufbau einer verschlüsselten Verbindung zwischen Server und Client kann jede Seite eine “Session Renegotiation” initialisieren, die vollständig im
verschlüsselten Kanal abläuft. Hierbei werden die Verschlüsselungsparameter neu verhandelt. Jedes Session erhält eine Session-ID.

Session resumption
Kurzbeschreibung: Performance-Optimiering, um eine vorhandene Session wieder nutzen zu können.
Beschreibung: TLS erlaubt die Fortsetzung (resumption) einer Session. Hierbei gibt der Client die Session-ID an und die Session wird ohne Neuaushandlung der Parameter weitergeführt. Es ist also kein Sicherheitsmerkmal, sondern dient der Performance-Steigerung.

Das Problem
Bei einer Session Renegotiation (kann entweder der Client oder der Server anfragen) wird ein vollständig neuer kryptografischer Kontext erstellt. Das heißt, dass zwischen der Anfrage vor und der Anfrage nach einer Session Renegotiation keine logische Verbindung besteht, wenn auch beide verschlüsselt sind.
Kurzbeispiel: Ein Client sendet eine unvollständige HTTPS-Anfrage an den Webserver, veranlasst eine Session Renegotiation und sendet dann den Rest der HTTPS-Anfrage. Der Webserver erhält vom SSL-Modul dann die vollständige Anfrage und “merkt” nicht, dass diese aufgeteilt war.
Da zwischen den beiden Sessions wie gesagt keine logische Verbindung besteht, kann der erste Teil der Anfrage von einem Angreifer kommen, der zweite Teil der Anfrage vom Opfer. Hierfür muss der Angreifer in der Lage sein Anfragen von einem Opfer abzufangen, es ist also eine Man-in-the-Middle-Szenario erforderlich.

Beispiel zertifikatsbasierte Client-Authentisierung
Die Authentisierung des Clients kann verzeichnisspezifisch erfolgen. Daher muss der Server erst die Anfrage des Pfades kennen, um die Gültigkeit des Zertifikats zu prüfen. Auf welches Verzeichnis der Client zugreifen möchte, ist also erst nach einer verschlüsselten Sitzung für den Server ersichtlich. Es wird also zunächst immer eine TLS-Verbindung ohne client-seitige Authentisierung aufgebaut und sofern der Client auf ein geschütztes Verzeichns zugreifen möchte, muss der Server die TLS-Verbindung neu verhandeln, um das Client-Zertifikat erneut zu erhalten. Bei der Neuverhandlung besteht durch die fehlenden logische Verknüpfung zwischen den Anfragen eine Authentisierungslücke zwischen der ursprünglichen Anfrage und der Authentisierung: Es wird in der Folge die ursprüngliche Anfrage, die nicht authentisiert ist, durch den Server durchgeführt.

Konkret gesprochen:

Das Opfer sendet eine Anfrage an den Webserver (Session 0) und fragt z. B. im Verzeichnis “secret” die Datei “1″ an. Der Angreifer speichert die Anfrage zwischen.
Der Angreifer baut seinerseits eine neue Verbindung zum Webserver auf (Session 1) und fragt im Verzeichnis “secret” die Datei “2″ an.
Der Webserver erkennt, dass für Anfragen im Verzeichnis secret eine Client-Authentisierung erforderlich ist und initialisiert eine Session Renegotiation mit einer “Server-Hello” Nachricht.
Der Angreifer nutzt die ursprüngliche “Client-Hello” Nachricht des Opfers zur Beantwortung des “Server-Hello”, im Bild Session 0′. Im nicht für den Angreifer einsehbaren Datenstrom zwischen Opfer und Webserver erhält das Opfer nun die Antwort auf die in Session 1 durch den Angreifer gesendete Anfrage, also Datei 2. Damit ist es einem Angreifer möglich, sofern er in der priveligierten Stellung zur Durchführung von MitM-Angriffen ist, die Anfrage des Clients mit seiner eigenen zu ersetzen, auch wenn er die die Antwort nicht sehen kann.

Beispiel Bank (Theorie)
Nehmen wir an, eine Bank lässt Transaktionen zu, ohne eine TAN zu verlangen. So würde folgender Aufruf 10 EUR an das Zielkonto 12345 mit der BLZ 99999 versenden. Dieses gehört dem Angreifer:

GET /banking/ueberweise.jsp?knr=12345&blz=99999&amount=10&cur=EUR

Das Opfer meldet sich an und ruft irgendeine Seite des Bankung aus, z. B.
GET /banking/umsaetze.jsp
Cookie: cookie_des_opfers

Der Angreifer verändert diese Anfrage nun wie folgt:
GET /banking/ueberweise.jsp?knr=12345&blz=99999&amount=10&cur=EUR
X-Ignoriere-dies: GET /banking/umsaetze.jsp
Cookie: cookie_des_opfers
Ein X-Header wird immer vom Webserver ignoriert. Mit diesem Angriff wird also an die “böse” GET-Anfrage des Angreifers die GET-Anfrage des Clients angehängt. Sofern der Angreifer Kenntnis der Webanwendung hat und durch einen Aufruf, nicht mehrere, eine “böse” Aktion auslösen kann, ist die Schwachstelle praxisrelevant. Sofern im Beispiel also eine TAN im Nachgang abgefragt würde (und das Opfer sich wundert, warum er eine TAN für eine Überweisung eingeben soll, die er nicht veranlasst hat), bekommt der Angreifer keine 10 EUR, da der Angriff nicht mit nur einem Aufruf erfolgreich wäre.

Beispiel Twitter (echte Welt)
Twitter hat(te) ein Problem. Dies kommt aber erst nur durch die neue Schwachstelle zum Tragen. Dabei zeigt sich, dass der Angriffsvektor vergleichbar mit Cross Site Request Forgery (CSRF, siehe hier und hier).
Mit dem neuartigen Angriff kann man wie beschrieben vor die Anfrage des Opfers seine eigene Anfrage schreiben.

Man kann hierbei nicht nur GET-Parameter verarbeiten, sondern auch POST-Parameter, sofern die Webanwendung mit Formularen arbeitet. Im Falle der Twitter-API wird mit Hilfe einer POST-Anfrage die Statusmeldung aktualisiert:
$curl -u "benutzer:passwort" -d "status=Schreibe einen Blog-Artikel" https://twitter.com/statuses/update.xml
Die Option “-d” gibt an, dass es sich um eine POST-Anfrage handelt. Mit Hilfe der Schwachstelle kann ein Angreifer die ersten 140 Zeichen (maximale Länge einer Twitter-Nachricht) in sein Tweet posten.
Das Opfer sendet die oben stehende Anfrage, der Angreifer hängt die Anfrage des Opfers an seine eigene, folgende Anfrage:
"POST /statuses/update.xml HTTP/1.1\r\n" \
"Authorization: Basic %s\r\n" \
"Host: twitter.com\r\n"\
"Accept: */*\r\n"\
"User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8\r\n"\
"Content-Length: 147\r\n"\
"Content-Type: application/x-www-form-urlencoded\r\n\r\n"\
"status="

Als Statusnachricht wird also die die POST-Anfrage des Opfers angegeben. Die ersten 140 Zeichen der POST-Anfrage werden daher in das Tweet des Angreifers geschrieben. Darin enthalten ist die Base64-codierte Kombination aus Benutzername und Passwort des Opfers für die API.
Wichtig: Der Angreifer hat auch hier zu keiner Zeit die Antwort auf die Anfrage des Opfers einsehen können! Die sensitiven Daten wurden durch die Anfrage in der Webanwendung gespeichert und wurden dadurch erst einsehbar. Digest-Authentication fällt dem Angriff also nicht in jedem Szenario, sondern nur in sehr speziellen Szenarien zum Opfer.

Quellen/Weitere Informationen
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
http://extendedsubset.com/?p=8 (unbedingt die “helpful protocol diagrams” beachten!)
http://www.links.org/?p=780
http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html
http://blogs.iss.net/archive/stealingcookieswiths.html
http://blog.g-sec.lu/2009/11/tls-sslv3-renegotiation-vulnerability.html

/gt