Original-URL des Artikels: https://www.golem.de/news/tls-cookie-clutter-und-virtual-host-confusion-bedrohen-https-1408-108393.html    Veröffentlicht: 06.08.2014 22:09    Kurz-URL: https://glm.io/108393

TLS

Cookie Cutter und Virtual Host Confusion bedrohen HTTPS

Antoine Delignat-Lavaud präsentierte auf der Black Hat 2014 mehrere neue Sicherheitsprobleme in HTTPS, die zum Großteil auf bekannten Schwächen basieren. Es sind Ergebnisse eines Forschungsprojekts, das versucht, die Sicherheit von TLS mathematisch zu formalisieren.

"The Beast wins again" betitelte Antoine Delignat-Lavaud seinen Vortrag auf der Black Hat - in Anspielung auf die BEAST-Attacke. Die BEAST-Attacke wurde 2011 entdeckt und läutete eine ganze Reihe von ähnlichen Angriffen ein, die Schwächen im TLS-Protokoll aufzeigten.

Ein Forschungsprojekt, an dem Delignat-Lavaud beteiligt ist, versucht seit einiger Zeit, diesen grundsätzlichen Problemen in TLS systematisch auf die Spur zu kommen. Das miTLS-Projekt, das von Microsoft-Mitarbeitern und dem französischen Forschungsinstitut Inria entwickelt wurde, hat dafür eine Implementierung von TLS erstellt und versucht, deren Sicherheitseigenschaften mathematisch zu beweisen. Ein erstes Ergebnis dieser Untersuchungen war der Triple-Handshake-Angriff, der im März veröffentlicht wurde. Auf der Black Hat präsentierte Delignat-Lavaud nun eine Reihe weiterer Probleme in TLS im Zusammenhang mit HTTPS-Webseiten.

Cookie Cutter durch gezielte Verbindungsabbrüche

Zunächst präsentierte Delignat-Lavaud den Cookie-Cutter-Angriff. Ein immer wiederkehrendes Problem von HTTPS-gesicherten Webanwendungen ist der Umgang mit Session-Cookies. Denn üblicherweise gelten dieselben Cookies für HTTP- und für HTTPS-Verbindungen. Auch wenn ein Sitzungscookie per HTTPS gesetzt wurde, kann es ein Angreifer mitlesen, falls es später unverschlüsselt per HTTP übertragen wird. Um dieses Problem zu beheben, kann man für Cookies ein Secure-Flag setzen - in dem Fall überträgt der Browser das Cookie nicht bei unverschlüsselten Verbindungen.

Das Problem dabei: Das Secure-Flag wird an ein Cookie hinten angehängt. Wenn sich nun ein solches Cookie über zwei TLS-Pakete verteilt, kann ein aktiver Angreifer die Übertragung des zweiten Pakets unterbinden. Das Ergebnis: Das Cookie kommt beim Nutzer an - aber ohne das Secure-Flag. Anschließend kann der Angreifer das Cookie abgreifen, falls eine einzige Verbindung zum selben Server über HTTP aufgebaut wird. Ein solcher Verbindungsaufbau kann ein Angreifer auch gezielt herbeiführen, wenn er das Opfer auf eine von ihm kontrollierte Webseite weiterleitet.

Webseiten, die nur über HTTPS erreichbar sind, setzen heutzutage häufig einen Header, der dem Browser signalisiert, dass HTTP-Verbindungen zu dieser Webseite nicht zulässig sind. Diese Funktion namens HTTP Strict Transport Security (HSTS) würde einen solchen Angriff in der Form unterbinden. Das Problem dabei: Auch HSTS ist anfällig für den Cookie-Cutter-Angriff. Wenn die Verbindung an der richtigen Stelle abgebrochen wird, ist der HSTS-Header nur für einige Sekunden gültig und somit quasi nutzlos.

Der Cookie-Cutter-Angriff baut auf bekannten Problemen auf, die Kollegen von Delignat-Lavaud zuvor auf der Black Hat 2013 präsentiert hatten. Die Grundidee für derartige Angriffe ist allerdings viel älter: Sie wurde von David Wagner bereits 1996 erörtert.

Die meisten Browserhersteller haben inzwischen Gegenmaßnahmen gegen derartige Angriffe implementiert. Sie akzeptieren unvollständige HTTP-Header und abgebrochene TLS-Verbindungen nicht mehr. Delignat-Lavaud sieht ein Grundproblem darin, dass Protokollparser häufig sehr tolerant darin sind, was sie als Eingabe akzeptieren. Dieses Grundprinzip ist sogar als "Robustness Principle" im IETF-Standard RFC 1122 festgehalten: "Be liberal in what you accept, and conservative in what you send." ("Sei liberal in dem, was du akzeptierst und konservativ in dem, was du sendest"). Laut Delignat-Lavaud müsse man sich von dieser Idee verabschieden und bei fehlerhaften oder unvollständigen Daten besser einen Fehler ausgeben.

Virtual Host Confusion

Ein weiteres Problem in TLS, welches das Team von Delignat-Lavaud ausgemacht hat, nennt er Virtual Host Confusion. Setzen verschiedene HTTPS-Hosts Zertifikate ein, die auch für andere Server gültig sind, kann ein Angreifer dies unter Umständen ausnutzen. Relevant ist hierbei, dass Webserver üblicherweise eine Default-Seite ausgeben, wenn man sich mit ihnen über einen unbekannten Hostnamen verbindet.

Als Beispiel zeigte Delignat-Lavaud einen Angriff auf Dropbox. Die normale Dropbox-Seite befindet sich unter www.dropbox.com. Unter dl-web.dropbox.com wiederum kann ein Nutzer eigene Daten ablegen - beispielsweise HTML-Dateien, die einen Cross-Site-Scripting-Angriff durchführen. Die Seite dl-web.dropbox.com hat ein Zertifikat, welches für *.dropbox.com ausgestellt ist, es ist also auch für www.dropbox.com gültig. Ein aktiver Angreifer kann nun durch einen aktiven Angriff dafür sorgen, dass sich der Nutzer, der www.dropbox.com aufruft, in Wirklichkeit mit dl-web.dropbox.com verbindet. Durch weitere Tricks kann der Angreifer dafür sorgen, dass dort die von ihm abgelegte HTML-Datei abgerufen wird. Sie wird dann im Kontext von www.dropbox.com ausgeführt und kann dazu genutzt werden, den Account des Opfers zu übernehmen.

Inzwischen hat Dropbox das Problem behoben. Eine Verbindung zu dl-web.dropbox.com ohne korrekten Hostnamen führt zu einer Fehlermeldung. Diese Strategie ist laut Delignat-Lavaud generell empfehlenswert. Webserver sollten bei unbekannten Hostnamen keine sinnvollen Daten ausgeben, sondern die Verbindung generell mit einem Fehler beantworten.

Noch gravierender ließ sich die Virtual Host Confusion beim Content-Delivery-Netzwerk Akamai ausnutzen. Akamai liefert beim Aufruf mit unbekanntem Hostnamen einen offenen Proxy. Damit lassen sich beliebige Webseiten von Dritten unter Akamai-Host aufrufen. Akamai liefert für zahlreiche populäre Webseiten Dateien mit gültigen Zertifikaten aus, unter anderem für LinkedIn, Twitter, Paypal, Bing, Apple und sogar die NSA. Delignat-Lavaud gelang es damit, eine von ihm kontrollierte Webseite per HTTPS im Namen der NSA auszuliefern.

Verschiedene weitere Varianten dieses Angriffs sind möglich. Ein weiteres ähnliches Problem hat Delignat-Lavaud im SPDY-Protokoll ausgemacht. SPDY ist ein von Google entwickeltes verbessertes HTTP-Protokoll. Wenn ein Nutzer per SPDY mehrere Verbindungen zum selben Server mit verschiedenen Hostnamen ausführt - diese aber dasselbe Zertifikat nutzen -, dann versucht SPDY, diese Verbindungen zu bündeln. Laut Delignat-Lavaud sind dadurch zahlreiche Sicherheitsannahmen, die für TLS gelten, für SPDY nicht mehr gültig. Details zu diesem Problem wollte er aber nicht nennen - denn es gibt bislang noch keine Updates für die betroffenen Browser.

Workarounds beheben Probleme nicht endgültig

Ähnlich wie bei Cookie Cutter basiert Virtual Host Confusion auf zahlreichen bekannten Problemen in TLS. Für Delignat-Lavaud ist das ein Zeichen dafür, dass Sicherheitsprobleme in der Vergangenheit oft unzureichend behoben wurden. Es wurden Workarounds implementiert, die zwar die bekannten Angriffe verhindern, aber die Grundprobleme nicht beheben. Auch der bereits bekannte Triple-Handshake-Angriff ist dafür ein Beispiel. Er nutzt Probleme der TLS-Renegotiation aus, die bereits 2009 zu einem Angriff geführt hatten.

Diese Beobachtung konnte man auch bei verschiedenen anderen TLS-Problemen in der Vergangenheit machen. So war die Lucky-Thirteen-Attacke im Jahr 2013 lediglich eine Neuauflage des Padding-Oracle-Angriffs von 2002. Bei der Verabschiedung des TLS-1.2-Standards war das Problem bekannt und ist sogar im Standard beschrieben. Man hielt es aber nicht für praktisch ausnutzbar.

TLS hat wohl noch einige Probleme. Die neuen Angriffe, die auf der Black Hat 2014 präsentiert wurden, dürften Ansätze für weitere Forschungsarbeiten bieten. Die nächsten TLS-Angriffe sind wohl nur eine Frage der Zeit.  (hab)


Verwandte Artikel:
Root-Zertifikat: Sennheiser-Software hebelt HTTPS-Sicherheit aus   
(09.11.2018, https://glm.io/137603 )
HTTPS: Browser wollen alte TLS-Versionen 2020 abschalten   
(16.10.2018, https://glm.io/137135 )
Ende-zu-Ende: Yahoo veröffentlicht Quellcode für E-Mail-Verschlüsselung   
(16.03.2015, https://glm.io/112984 )
Verschlüsselung: TLS 1.3 mit Startschwierigkeiten   
(13.10.2018, https://glm.io/137097 )
HTTPS: Noch immer viele Symantec-Zertifikate aktiv   
(12.10.2018, https://glm.io/137093 )

© 1997–2019 Golem.de, https://www.golem.de/