HEIST: Angriff auf TLS ohne MITM

Forscher der Universität Leuven haben Timing-Angriffe in JavaScript mit der Breach-Attacke kombiniert und damit ein Angriffsszenario erschaffen, das sie HEIST nennen. HEIST kürzt „HTTP Encrypted Information can be Stolen through TCP-windows“ ab, was bereits verdeutlicht, was hinter dem Angriff steckt.

Kombination aus Crime und Breach

Es war 2012, als der Crime-Angriff für Furore sorgte: die Kompression von TLS förderte Informationen über die verschlüsselten Daten zutage. Mit Praxistauglichkeit hatte das Angriffsszenario jedoch nichts zu tun, denn die TLS-Kompression wird sehr selten verwendet.

Jedoch wurde in 2013 auf der Black Hat in Las Vegas mit dem Breach-Angriff ein Szenario vorgestellt, das auf die Gzip-Kompression, die HTTP verwendet, abzielte. Dieses Szenario ist praxisrelevanter, da nahezu sämtliche Websites zum Komprimieren von HTML-Daten Gzip nutzen.

Grundvoraussetzung für beide Szenarien ist eine Website, die von Angreifern kontrollierbare Strings enthält. Infrage kommen GET- sowie POST-Parameter, die entweder Teil des HTML-Codes sind oder innerhalb der ausgelieferten Site sichtbar werden. Erkennt ein Angreifer auf derselben Site für ihn interessante Geheimnisse, kann er durchs schrittweise testen probieren, an eben diese heranzukommen:

Der Angreifer errät die einzelnen Zeichen, sodass sich die kompromittierten Daten verkleinern. Dies gibt dem Angreifer wertvolles Feedback und ihm gelingt es, den gesamten String zu entschlüsseln. Voraussetzung fürs Funktionieren ist jedoch, dass der Angreifer in der Lage ist, übertragene Daten zu belauschen.

HEIST: Weiterentwicklung ohne vorherigen Lauschangriff

Die Forscher Tom Van Goethem und Mathy Vanhoef (KU Leuven) fanden nun heraus, dass sich mithilfe von JavaScript die Länge komprimierter und verschlüsselter Informationen extrahieren lässt. Die Funktionsweise von TCP half den Forschern:

Bei TCP überträgt der Server zunächst 10 Pakete und wartet dann auf Antwort seitens des Clients, um anschließend mehr Pakete zu übertragen. Zwei JavaScript-Funktionen ermöglichen Angreifern herauszufinden, wie viel Zeit solche Requests brauchen. Die Server-Antwort im ersten Zehnerpack der TCP-Pakete verläuft zügiger als Antworten mit mehreren Paketen; dafür wird ein neuer Roundtrip notwendig. Probiert der Angreifer mit reflektierten Parametern herum, findet er heraus, auf welche Größe er die Parameter setzen muss, um diese in das erste Zehnerpack einzufügen bzw. um es exakt ein Byte groß zu gestalten.

HEIST = Breach 2.0

Das ermöglicht nun wieder den Breach-Angriff. Lediglich die Antwortlänge muss der Angreifer anpassen, um dann durch die Antwortzeit darauf schließen zu können, ob das Folgezeichen korrekt erraten ist. HTTP/2 erlaubt eine zweite Variante des Angriffs: hierbei werden sämtliche HTTP-Requests über nur eine TCP-Verbindung geschickt. So klappt der Angriff selbst dann, wenn sich das interessante Geheimnis und der reflektierte String auf verschiedenen Seiten befinden.

Das Untermogeln des kontrollierten JavaScripts stellt leider keine Hürde dar: gerade Ad-Netzwerke gestalten ihre Produkte nicht sonderlich sicher und so braucht es nur eine Werbeanzeige, die JavaScript verwendet. Der Angreifer muss nicht mal den Netzwerkverkehr seines Opfers mitlesen; vorheriges Belauschen via Man-in-the-Middle (MITM) ist unnötig.

Nicht viele Lösungen sind machbar

Man könnte dem Glauben verfallen, HEIST durchs Abschalten der Kompression zu begegnen. HTML-Daten lassen sich jedoch bestens komprimieren und ein Verzicht würde immense Performance-Einbußen nach sich ziehen – das ist keine effiziente Lösung. Geheime Daten nicht zu komprimieren, wäre mit der HTTP/2-Headerkompression HPACK möglich, allerdings ist dies für Daten innerhalb des HTML-Parts schwer machbar.

Eine einfache Lösung ist, Third-Party-Cookies im verwendeten Browser zu deaktivieren (Mozilla: Anleitung, Chrome: Anleitung). Wichtig zu wissen ist, dass Sie dann womöglich nicht mehr alle Websites uneingeschränkt aufrufen können.

Eine neuere und wirksamere Methode sind Same-Site-Cookies: sie können gegen diese und ähnliche Angriffe wirkungsvoll schützen. Webapplikationen können durch Same-Site-Cookies verhindern, dass sich Site-Zugriffe von anderen Websites in Accounts einloggen. Bislang liegt bei der IETF lediglich ein Entwurf für Same-Site-Cookies vor, jedoch werden sie von Googles Browser Chrome bereits unterstützt.