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.