HTTPS Bicycle Attack - Ein Überblick

HTTPS Bicycle Attack

Ein Überblick

Stefan Friedli
von Stefan Friedli
am 17. März 2016
Lesezeit: 8 Minuten

Grosse Probleme fangen meistens als kleine Probleme an. Und dann ist der beste Zeitpunkt, sie zu lösen. Diese Weisheit, die gemeinhin dem Gründer des Taoismus, Lao Tzu, zugeschrieben wird, dürfte manchem bekannt vorkommen.

Doch Grössen stehen nicht nur im Zentrum von Lao Tzu’s Lehren, sondern auch in Guido Vranken’s jüngst veröffentlichtem Paper zur sogenannten HTTPS Bicycle Attack. Simpel zusammengefasst stellt Vranken fest, dass die Nutzung von Stromverschlüsselungen im Kontext von TLS-Verbindungen dazu führt, dass die Grösse/Länge des Payloads durch das Betrachten des Netzwerkverkehrs für einen Angreifer eruierbar ist. So versteckt die Verschlüsselung zwar den Inhalt, lässt aber dessen Dimensionen und, über mehrere Requests hinweg, deren Form durchblicken. Vranken wählte basierend darauf den Vergleich mit einem in Geschenkpapier eingewickelten Fahrrads: Marke, Farbe und genaue Ausprägung bleiben unbekannt; der Fakt, dass es sich um ein Fahrrad handelt, ist aber vergleichsweise einfach abzuleiten.

Die Problematik, dass die Länge von TLS-Payloads nicht versteckt wird, ist nicht neu. Bereits im September 2013 veröffentlichte Alfredo Pironti von der INRIA Paris-Rocquencourt einen Internet-Draft mit dem Titel Length Hiding Padding for TLS Protocol, der einige Methoden zum Verstecken der Länge mittels entsprechender Mechaniken (zum Beispiel Range Splitting) aufzeigt.

Neu an Vranken’s Paper ist allerdings der Versuch, praktische Angriffsvektoren aus diesem Verhalten abzuleiten. So demonstriert er in seinem Papier einen interessanten Ansatz, um die bekannten Längen von Requests/Responses zum Fingerprinting von bestimmten Seitenaufrufen zu nutzen. So führt der Aufruf des Loginformulars der populären Blogging-Plattform Wordpress zu insgesamt fünf Anfragen mit individuellen Längen, die in einer bestimmten, statischen Relation zueinander stehen. Beispiel:

ID Anfrage Länge
1 /wp-login.php 368
2 /wp-includes/css/buttons.min.css?ver=4.4 409
3 /wp-includes/css/dashicons.min.css?ver=4.4 411
4 /wp-admin/css/login.min.css?ver=4.4 404
5 /wp-admin/images/wordpress-logo.svg?ver=20131107 454

Vranken nutzt dann den Korrelationskoeffizienten (nach Bravais und Pearson), um die obengenannte Sequenz in einem Strom von Requests zu identifizieren. Ein interessanter Ansatz, zumal dabei eine relative Korrelation der einzelnen Grössen stattfindet: Solange die Grössen im richtigen Verhältnis zueinander stehen, kann ein Angreifer so zum Beispiel genutzte Softwareprodukte und ähnliches eruieren oder erweiterte Angriffe konzipieren. Statische Abweichungen, wie zum Beispiel ein deutlich längerer User-Agent Header, sind daher irrelevant.

In einem zweiten Szenario geht Vranken etwas weiter und zeigt auf, dass unter gewissen Bedingungen die Länge eines unbekannten Faktors, wie zum Beispiel eines Passworts, eruiert werden kann. Dazu muss der Angreifer aber den eingesetzten Browser sowie die spezifische Ressource, die das Ziel des Angriffes sein soll, kennen. Kann ein Angreifer allerdings alle Header sowie weitere Drittdaten emulieren, dann kann er aus der Längendifferenz der beobachteten Requests die Länge des gewünschten Parameters, also in diesem Falle des Passwortes, ableiten.

Dieser Angriff scheint, in der Form wie ihn Vranken schildert, nur begrenzt praxisfähig und hätte durch heute gängige flankierende Massnahmen (Account Lockouts etc.) auch nur wenig kritische Implikationen. Obwohl natürlich die Kenntnis der Passwortlänge den benötigten Effort für eine Brute-Force Attacke massiv reduzieren würde.

Das letzte Beispiel, das in Vranken’s Paper Verwendung findet, geht von einer Applikation aus, die regelmässig die aktuelle Position des Ziels in Form von GPS-Koordinaten über eine SSL-verschlüsselte HTTP Verbindung sendet. Durch das passive Beobachten, so Vranken’s Annahme, könnten die Bewegungen des Ziels zumindest grob nachvollzogen werden. Ein Beispiel:

Beträgt die Summe von Zeichen in den Parametern für Längen- und Breitengrad exakt zwei (2), so kann davon ausgegangen werden, dass sich das Ziel an einer Örtlichkeit in der Umgebung von Kamerun oder dem Kongo befindet. Erhöht sich die Summe der Zeichen plötzlich auf drei (3), so hat sich das Ziel entweder gegen Norden oder Osten verschoben. Die Praktikabilität dieses Angriffs hat jedoch seine Grenzen: Bei einer Erhöhung der Zeichensumme auf vier (4), sind fast alle Himmelsrichtungen als mögliche Optionen denkbar.

Geolokation durch Datenlänge ableiten

Ungeachtet dessen: Im Hinblick darauf, dass diese Analyse gänzlich passiv und damit ohne jegliches Einwirken auf den Verkehr stattfinden könnte, muss die Frage gestellt werden, ob hier nicht Potenzial im Bereich flächendeckender Verkehrsanalyse vorhanden wäre.

Kurz zusammengefasst heisst das:

  1. Ein Angreifer mit Zugriff auf den Netzwerkverkehr des Ziels kann mittels gezielter Korrelation zwischen einzelnen Request-Längen feststellen, ob spezifische Webseiten und/oder Webapplikationen genutzt werden.
  2. Ein Angreifer mit Kenntnis der Zielressource und des eingesetzten Browsers auf Seiten des Benutzers kann mittels Beobachtung des Traffics die Längen unbekannter Faktoren ableiten (z.B. Passwort).
  3. Ein Angreifer mit Kenntnis eines Geolocation-Dienstes kann durch Analyse der Anzahl Zeichen in den Parameterfeldern für Längen- und Breitengrad die Position des Ziels und mutmassliche Bewegungsdaten eruieren.

Generell stellt sich allerdings die Frage, wie weit verbreitet hier Angriffsspielraum überhaupt vorhanden ist. Zum Zeitpunkt dieses Artikels im Frühjahr 2016 ist der Einsatz von Stromchiffren eher unpopulär, bedingt durch die Probleme mit RC4. Zumindest bis Salsa20 breite Verwendung findet, dürften sich die Risikoszenarien daher eher auf Fälle beschränken, in denen Blockchiffren aus Performancegründen als Stromchiffren genutzt werden (Galois/Counter).

Ungeachtet dessen wäre eine mögliche Lösung des Problems einfach zu bewerkstelligen: Request Padding. So könnten Webapplikationen jeder Anfrage mit einem dynamischen, schützenswerten Feld, einen Buffer mitgeben, der die Anfrage auf eine uniforme Grösse aufbläht und so die Analyse auf obengenannter Basis unmöglich macht.

Oder, um Vranken’s Analogie weiterzuspinnen: Wer nicht möchte, dass sein Geschenk als Fahrrad erkannt wird, verpackt es optimalerweise in einer Holzkiste.

Über den Autor

Stefan Friedli

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
Crypto-Malware

Crypto-Malware

Ahmet Hrnjadovic

TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv