Der Anteil verschlüsselter HTTP-Verbindungen wächst stetig und erfasst längst auch Bereiche mit weniger sensitiven Informationen. Es gibt sogar Initiativen, die den gesamten Web-Traffic auf HTTPS umstellen wollen. Eine gewichtige treibende Kraft ist dabei Google mit „HTTPS everywhere“ und dem vor zwei Jahren eingeführten Ranking-Signal HTTPS. Mit dem schwindenden Anteil unverschlüsselter HTTP-Verbindungen nimmt aber auch die Attraktivität von Angriffsvektoren gegen HTTPS zu. Bei den bisher bekannten Angriffsszenarien war dazu ein Man-in-the-Middle im Datenstrom zwischen Client und Server notwendig. Forscher der belgischen Universität Leuven haben jetzt mit HEIST einen Angriff vorgestellt, der ohne diese Einschränkung funktioniert.
Was ist neu und warum ist HEIST so brisant?
HEIST baut auf HTTPS-Angriffen auf, die in ihren Ursprüngen mehr als ein Jahrzehnt zurückreichen, namentlich BREACH, CRIME und TIME. Sie waren in der Praxis wenig relevant, vor allem weil der Angreifer zunächst einen Zugang zur Datenverbindung zwischen dem Browser und dem Webserver benötigt, um den Angriff ausführen zu können. Zwei neue JavaScript APIs ermöglichen es, dieses Problem zu umgehen. Die Funktion fetch erlaubt es, beliebige Web-Ressourcen zu laden und mit Hilfe des Resource Timing APIs die Zeiten vom eintreffen des ersten Bytes bis zum vollständigen Laden exakt zu ermitteln. Dabei unterliegt fetch keinen Beschränkungen bezüglich des Ursprungs der Ressource, im Gegensatz zu den entsprechenden Funktionen des älteren XMLHttpRequest API, und umgeht damit die wichtige Schutzfunktion der Same-Origin Policy.
Ein HEIST-Angriffszenario könnte also so aussehen, dass ein Angreifer über eine Werbeeinblendung einen bösartigen JavaScript-Code in die Webseiten eines Onlineshops einschleust, der mittels fetch HTTP(S)-Requests an den Webserver des Shopbetreibers senden und auswerten kann, obwohl er von einer ganz anderen Quelle geladen wird.
Welche Schwachstellen in HTTPS nutzt HEIST aus?
Der Trick, mit dem HEIST die HTTPS-Verschlüsselung knackt, ohne die verschlüsselten Daten an sich zu untersuchen, ist bereits von BREACH bekannt. Er nutzt die Datenkomprimierung, die bei HTTP-Verbindungen das Datenvolumen erheblich reduziert und damit auch die Ladezeiten von Webseiten verkürzt. Die Komprimierung entfernt gleiche Zeichenketten aus einem Datenstrom und ersetzt sie durch Indizes. Das ermöglicht es, durch das Anhängen einer Zeichenkette wie „ABC“ an einen unbekannten Text herauszufinden, ob „ABC“ darin enthalten ist. Die Länge des komprimierten Texts ist in diesem Fall kürzer als wenn die Zeichenkette nicht vorkommt. Aber wie misst HEIST die Länge? Das ist der zweite Trick, dem HEIST auch seinen Namen verdankt.
„HTTP Encrypted Information Stolen through TCP-Windows“
Eine TCP-Verbindung beginnt allgemein mit einem kleinen Datenfenster, meist 10 Pakete, und vergrößert es bei ausreichender Bandbreite sukzessive. Passen die übertragenen Daten in das erste TCP-Window, dann ist der HTTP-Request deutlich schneller beantwortet, als wenn die Response größer ist und ein zweites Fenster benötigt. Somit braucht HEIST gar nicht die Länge der komprimierten und verschlüsselten Daten bestimmen, sondern nur die Übertragungszeit messen. Genau das ermöglichen die neuen JavaScript-APIs. HEIST kann damit zum Beispiel CSRF-Token einfach durch ein Ausprobieren verschiedener Zeichenketten erraten.
