TLS-Design Schwachstelle:


In [1] ist eine Schwachstelle beim Design des TLS-Protokolls einschliesslich SSL v3 und früherer Protokolle beschrieben worden. An dieser Stelle werden die wichtigsten Ergebnisse der Arbeit beschrieben.

 

Historie: 

  • 11.11.2009: Erste Version
  • 17.11.2009: Ergänzungen zu aktuellen Angriffsszenarien und Lösungen

 

Grundlagen:


Aufbau einer TLS-gesicherten Verbindung: Der Client sendet einen "Client Hello" Request zum Server, bei dem er die unterstützten kryptographischen Verfahren (Cipher Suites) dem Server bekannt gibt. Dieser antwortet mit einem "Server Hello", das die TLS-Version und Cipher Suite zum initialen Aushandeln der TLS-Session beinhaltet. Danach sendet der Server sein Zertifikat zum Client und schließt den Verbindungsaufbau mit der Nachricht "Server Hello Done ab". Im Anschluß wird ein kryptographischer Schlüssel zwischen Client und Server ausgehandelt und die Verschlüsselung für die TLS-Session aktiviert. Eine "Finish"-Nachricht vom Server schließt den Aufbau der TLS-Verbindung ab.

Der Standard ermöglicht es sowohl dem Server als auch dem Client, die Verbindungsdaten neu auszuhandeln (Renegotiation). Dies geschieht wieder über "Hello"-Nachrichten, die je nachdem ob der Client oder der Server die Verbindung neu aufbauen will von diesem gesendet werden. Ergebnis ist der Neuaufbau der TLS-Verbindung mit einer neu erzeugten Session-ID und einer entsprechenden Cipher Suite. Eine Anwendung der Renegotiation tritt bei Webservern auf, bei denen Verzeichnisse unterschiedliche Sicherheitsniveaus haben. Greift der Client auf diese Inhalte zu, kann der Server eine neue TLS-Verbindung mit verbesserter Sicherheit (zum Beispiel andere Cipher Suite) anfordern. Weiterhin sieht der Standard vor, eine ältere TLS-Verbindung unter Angabe der zugehörigen Session-ID per "Resumption" fortzuführen.

 

Schwachstelle:


Die Ursache der Schwachstelle liegt im Zusammenspiel von TLS und darüber liegenden Protokollen (zum Beispiel HTTP). Dabei kann ein Angreifer über den die Verbindung läuft (man-in-the-middle) eine Lücke in der Authentifizierung ausnutzen. Dies wird in [1] als "Authentication Gap" bezeichnet. Die Schwachstelle liegt in dem Vorgang der Renegotiation und ermöglicht einem Angreifer, eigene Inhalte in die kryptographisch gesicherte TLS-Verbindung einzubringen. Aus der Sicht des Servers stammen diese Inhalte vom Client. Allerdings ermöglicht diese Schwachstelle dem Angreifer nicht, die Verschlüsselung der Verbindung zwischen Client und Server zu brechen. Das heißt, der Angreifer ist nicht in der Lage, die Antwort vom Server oder den legitimen Request vom Client zu entschlüsseln.

Angriffsszenario beim HTTP-Protokoll:

 

  1. Der Client baut eine TLS-Verbindung zum Server auf ("Client Hello"). Der Angreifer (man-in-the-middle) leitet den Request zum initialen TLS-Aufbau zum Server weiter und baut anschließend die  TLS-Verbindung anstelle des Clients auf. Der Client sieht dabei keine Antwort vom Server.
  2. Der Angreifer sendet einen oder mehrere HTTP-Requests über die TLS-Verbindung zum Server, deren Bearbeitung eine Renegotiation der TLS-Parameter erfordern.
  3. Jetzt leitet der Angreifer zum zweiten Mal das "Client Hello" zum Server weiter (Replay) und erlaubt beiden Seiten, die TLS-Verbindung aufzubauen. Der Client reagiert entsprechend auf die Aufforderung des Servers und authentifiziert sich.

  4. Der Client sendet jetzt den eigentlichen HTTP-Request zum Server. Wie in [1] gezeigt wurde, wird dabei der HTTP-Request des Angreifers nicht verworfen und die HTTP-Requests werden zu einem kombiniert (dies wird in [1] als Request Splicing bezeichnet). Damit hat der Angreifer sein Ziel erreicht, den eigenen Request im Rahmen der authentifizierten TLS-Session zum Server zu senden. In dem Angriffsszenario in [1] endet der HTTP-Request des Angreifers mit einem nicht terminierten "x-ignore"-Header. Werden beide Requests zusammengefügt, wird der GET-Request-Header des Clients dem "x-ignore" zugefügt und damit ignoriert. Das heißt, der vom Server ausgewertete GET-Request stammt vom Angreifer, der vom Client wird ignoriert.

Auswirkungen der Schwachstelle:


Die Auswirkung ist, dass ein Angreifer als Man-in-the-Middle eigene Daten in eine TLS-Verbindung einfügen kann. Es kann also die Integrität des Datenstroms gebrochen werden. Die Vertraulichkeit der Daten ist allerdings nicht gefährdet. Die Konsequenzen hängen dabei von dem unter TLS liegenden Protokoll ab.

In [1] werden die Auswirkungen für das HTTP-Protokoll beschrieben: Ein Angreifer kann hier HTTP-Requests eines legitimen Benutzers manipulieren. Im Beispiel in [1] wird gezeigt, wie ein Angreifer die URI im HTTP-Request eines Benutzers beliebig fälschen kann. Dieser Request wird dann mit den Authentifizierungsdaten des Benutzers zum Server gesendet. Die Auswirkungen hängen dabei von der Web-Anwendung ab und beinhalten alle Aktionen, die der Angreifer durch Senden eines HTTP-Requests ausführen kann. Im schlimmsten Fall kann der Angreifer beispielsweise das Passwort des Benutzers ändern, oder an vertrauliche Informationen gelangen. Allerdings ist der Angreifer nicht in der Lage, die verschlüsselten Daten direkt anzugreifen, die innerhalb der TLS-Verbindung gesendet werden. Dies sind der HTTP-Request des Benutzers und die Antwort vom Webserver. Es ist also nicht möglich, per HTTP-Request auf bestimmte Ressourcen zuzugreifen und diese dann in der Serverantwort zu lesen. Der Angreifer kann aber unter Umständen diese Einschränkung umgehen. Im Fall eines Webmailers könnte der HTTP-Request beispielsweise die Weiterleitung einer vertraulichen E-Mail veranlassen. Ob dies möglich ist, hängt wie bereits oben geschrieben von der Implementierung der Webmail-Anwendung ab. In dem konkreten Fall ist das davon abhängig, wie Inhalte der E-Mail und andere Parameter in HTTP-Requests kodiert und behandelt werden.

 

Angriffe gegen die Twitter API

Ein konkretes Angriffsszenario gegen die Twitter REST API ist jetzt in [2] veröffentlicht worden. In diesem Fall verwendet der Angreifer eine etwas andere Strategie. Dieser injiziert einen Post-Request auf ein Forum, zum Beispiel:

 POST /forum/send.php HTTP/1.1
 message=POST /statuses/update.xml HTTP/1.0
 Host: ....
 Authorization: Basic dmljdGltQGV4YW1wbGUuY29tOnNlY3VyZXB3
 ....

Der nachfolgende Request des Clients (im oben Beispiel fett gedruckt) wird an das "message=" angefügt. Folge des Angriffs ist, dass der Request des Client als Nachricht an das Forum gesendet wird. Der Angreifer kann so auf den Request zugreifen, der zwar verschlüsselt an das Forum gesendet wird, dort aber im Klartext abgelegt wird. Falls wie in dem obigen Beispiel die Twitter API die Methode "HTTP Basic Authentication" verwendet, werden der Benutzernamen und Passwort im HTTP-Header ohne eigene Verschlüsselung übertragen. Oben sind diese Daten fett und kursiv gedruckt. Die Daten liegen im Klartext vor, sobald diese von der Base64-Kodierung in ASCII umgewandelt werden. 

Allerdings sind andere Authentifizierungsmechnismen vermutlich nicht betroffen. Beispielsweise bietet OAuth in [3] einen eigenen Schutz gegenüber Man-in-the-Middle Angriffen, indem die Requests signiert werden. Die digitale Signatur ermöglicht es dem Server, die Integrität der HTTP-Requests zu überprüfen. Das verhindert also, dass ein "Man-in-the-Middle" Requests manipulieren kann, wie es bei dem aktuellen Angriff gemacht wird. Voraussetzung ist allerdings, dass die Signatur-Methode "Plaintext" nicht verwendet wird. Die Signatur-Methode "Plaintext bietet keinen Schutz der Integrität von HTTP-Requests.

 

Angriffe gegen SMTP

Wietse Venema untersucht in [4], unter welchen Bedingungen das Protokoll SMTP von der TLS-Schwachstelle betroffen ist. Spezielles Szenario ist ein SMTP-Server, der sich durch TLS gegenüber dem Client authentifiziert und die Verbindung absichert. Das heisst, aus der Sicht des Client sollte eine sichere Verbindung zum Server bestehen, der die Integrität der versendeten E-Mail absichert. Laut [4] kann ein Angriff auf SMTP auf die folgende Weise unter mehreren Voraussetzungen durchgeführt werden:

  • Der Angreifer baut eine eigene TLS-Verbindung zum Server auf.
  • Im Nächsten Schritt fängt der Angreifer das TLS-Hello vom Client ab und konstruiert ein TCP-Paket, das aus SMTP Kommandos zum Versenden einer Mail (Hello, Mail, RCPT und Data) und aus dem TLS-Hello Request des legitimen Client besteht. Das heisst, der Angreifer versucht zusätzlich zu dem TLS-Hello Request des Client eigene SMTP Kommandos zum Versenden einer E-Mail an den Server zu senden. 
  • Der Server bearbeitet das TCP-Paket des Angreifers. Damit der Angriff erfolgreich ist, muss der Server den TLS-Hello Request vor der Antwort auf die SMTP Kommandos des Angreifers bearbeiten. Dies führt dazu, dass Server und Client eine neue Verbindung aushandeln (Renegotiation) und der Server die  SMTP Kommandos im Rahmen dieser Verbindung auswertet. Das bedeutet, dass für den Server diese Kommandos vom legitimen Client stammen. Antwortet der Server vorher auf die SMTP Kommandos, würden diese nicht mehr im Rahmen der TLS-Session ausgewertet werden, die der legitime Client aufbaut. In diesem Fall kann der Angreifer also keine Daten in die TLS-Session des Clients einfügen.

Ein erfolgreicher Angriff kann beispielsweise E-Mails des Clients umleiten oder diese modifizieren. Allerdings weist Wietse Venema in [4] darauf hin, dass Postfix nicht betroffen ist.

Wer ist betroffen?

 

Das läßt sich zur Zeit noch nicht pauschal beantworten. Grundsätzlich sind alle Anwendungen unter den folgenden Bedingungen nicht betroffen:

 

  •  Muss sich der Client vor dem ausgeführten Protokoll-Request authentifizieren, ist die Anwendung nicht betroffen.
  •  Werden alle Inhalte, die in der TLS-Session gesendet wurden, nach einer TLS-Renegotiation verworfen, ist die Anwendung auch nicht betroffen.

In wie weit andere Protokolle betroffen sind, wird in [5] zusammengefasst.

 

Lösungen:

 

Bislang ist die Schwachstelle noch nicht vollständig geschlossen worden. Als Workaround wurde in OpenSSL 0.9.8l die TLS-Renegotiation per Default deaktiviert. Allerdings können dadurch Anwendungen fehlerhaft reagieren, die diese Nachverhandlung der TLS-Parameter verwenden. 

Die technisch vollständige Behebung dieser Schwachstelle im TLS-Protokoll ist in dem Draft der IETF in [6] beschrieben worden.  Lösung ist es, Neuverhandlungen (Renegotiation) cryptographisch an die bereits etablierte TLS-Verbindung zu binden. In diesem Fall ist es für einen Angreifer unmöglich, eine TLS-Verbindung mit dem Server aufzubauen, die durch die Renegotiation dann vom Client übernommen wird. Der Server würde also bemerken, dass keine gültige TLS-Verbindung mit dem Client bestand, über die Renegotiation durchgeführt werden soll. Auf der anderen Seite kann der Client nachvollziehen, dass eine Renegotiation für eine bereits etablierte Verbindung durchgeführt werden soll, die aus dessen Sicht aber nicht besteht. Technisch wird dafür eine TLS-Erweiterung (Extension)  "renegotiation_info" eingeführt. Da SSLv3 keine Erweiterungen kennt, ist diese Lösung nur für TLS geeignet.

Referenzen:

 

[1] Marsh Ray, Steve Dispensa, "Renegotiating TLS", November 2009,

http://extendedsubset.com/?p=8

[2] Anil Kurmus,  "The Secure Goose: TLS renegotiation vulnerability (CVE-2009-3555)", Blog Eintrag vom November 2009, http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html

[3]  OAuth Core 1.0, http://oauth.net/core/1.0/

[4] Wietse Venema, "Redirecting and modifying SMTP mail with TLS",
http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pdf

[5] Thierry Zoller, "TLS and SSLv3 vulnerabilities explained",
http://www.g-sec.lu/practicaltls.pdf

[6] EITF-Draft, "Transport Layer Security (TLS) Renegotiation Indication Extension",
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

 

Weitere Links:

http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html

http://www.links.org/?p=780

http://www.ietf.org/mail-archive/web/tls/current/msg03948.html

http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

http://www.heise.de/security/meldung/Schwachstelle-im-SSL-TLS-Protokoll-851104.html

http://isc.sans.org/diary.html?storyid=7534