{"id":3449,"date":"2016-08-09T14:26:59","date_gmt":"2016-08-09T12:26:59","guid":{"rendered":"https:\/\/www.psw-group.de\/blog\/?p=3449"},"modified":"2026-03-18T11:28:25","modified_gmt":"2026-03-18T10:28:25","slug":"heist-angriff-auf-tls-ohne-mitm","status":"publish","type":"post","link":"https:\/\/www.psw-group.de\/blog\/heist-angriff-auf-tls-ohne-mitm\/","title":{"rendered":"HEIST: Angriff auf TLS ohne MITM"},"content":{"rendered":"

Forscher der Universit\u00e4t Leuven haben Timing-Angriffe in JavaScript mit der Breach-Attacke kombiniert und damit ein Angriffsszenario erschaffen, das sie HEIST nennen<\/a>. HEIST k\u00fcrzt „HTTP Encrypted Information can be Stolen through TCP-windows“ ab, was bereits verdeutlicht, was hinter dem Angriff steckt.<\/p>\n

Kombination aus Crime und Breach<\/h3>\n

Es war 2012, als der Crime-Angriff<\/a> f\u00fcr Furore sorgte: die Kompression von TLS f\u00f6rderte Informationen \u00fcber die verschl\u00fcsselten Daten zutage. Mit Praxistauglichkeit hatte das Angriffsszenario jedoch nichts zu tun, denn die TLS-Kompression wird sehr selten verwendet.<\/p>\n

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

Grundvoraussetzung f\u00fcr beide Szenarien ist eine Website, die von Angreifern kontrollierbare Strings enth\u00e4lt. 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\u00fcr ihn interessante Geheimnisse, kann er durchs schrittweise testen probieren, an eben diese heranzukommen:<\/p>\n

Der Angreifer err\u00e4t die einzelnen Zeichen, sodass sich die kompromittierten Daten verkleinern. Dies gibt dem Angreifer wertvolles Feedback und ihm gelingt es, den gesamten String zu entschl\u00fcsseln. Voraussetzung f\u00fcrs Funktionieren ist jedoch, dass der Angreifer in der Lage ist, \u00fcbertragene Daten zu belauschen.<\/p>\n

HEIST: Weiterentwicklung ohne vorherigen Lauschangriff<\/h3>\n

Die Forscher Tom Van Goethem und Mathy Vanhoef (KU Leuven) fanden nun heraus, dass sich mithilfe von JavaScript die L\u00e4nge komprimierter und verschl\u00fcsselter Informationen extrahieren l\u00e4sst. Die Funktionsweise von TCP half den Forschern:<\/p>\n

Bei TCP \u00fcbertr\u00e4gt der Server zun\u00e4chst 10 Pakete und wartet dann auf Antwort seitens des Clients, um anschlie\u00dfend mehr Pakete zu \u00fcbertragen. Zwei JavaScript-Funktionen erm\u00f6glichen Angreifern herauszufinden, wie viel Zeit solche Requests brauchen. Die Server-Antwort im ersten Zehnerpack der TCP-Pakete verl\u00e4uft z\u00fcgiger als Antworten mit mehreren Paketen; daf\u00fcr wird ein neuer Roundtrip notwendig. Probiert der Angreifer mit reflektierten Parametern herum, findet er heraus, auf welche Gr\u00f6\u00dfe er die Parameter setzen muss, um diese in das erste Zehnerpack einzuf\u00fcgen bzw.\u00a0um es exakt ein Byte gro\u00df zu gestalten.<\/p>\n

HEIST = Breach 2.0<\/h3>\n

Das erm\u00f6glicht nun wieder den Breach-Angriff. Lediglich die Antwortl\u00e4nge muss der Angreifer anpassen, um dann durch die Antwortzeit darauf schlie\u00dfen zu k\u00f6nnen, ob das Folgezeichen korrekt erraten ist. HTTP\/2 erlaubt eine zweite Variante des Angriffs: hierbei werden s\u00e4mtliche HTTP-Requests \u00fcber nur eine TCP-Verbindung geschickt. So klappt der Angriff selbst dann, wenn sich das interessante Geheimnis und der reflektierte String auf verschiedenen Seiten befinden.<\/p>\n

Das Untermogeln des kontrollierten JavaScripts stellt leider keine H\u00fcrde 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\u00f6tig.<\/p>\n

Nicht viele L\u00f6sungen sind machbar<\/h3>\n

Man k\u00f6nnte dem Glauben verfallen, HEIST durchs Abschalten der Kompression zu begegnen. HTML-Daten lassen sich jedoch bestens komprimieren und ein Verzicht w\u00fcrde immense Performance-Einbu\u00dfen nach sich ziehen \u2013 das ist keine effiziente L\u00f6sung. Geheime Daten nicht zu komprimieren, w\u00e4re mit der HTTP\/2-Headerkompression HPACK m\u00f6glich, allerdings ist dies f\u00fcr Daten innerhalb des HTML-Parts schwer machbar.<\/p>\n

Eine einfache L\u00f6sung ist, Third-Party-Cookies im verwendeten Browser zu deaktivieren (Mozilla: Anleitung, Chrome: Anleitung<\/a>). Wichtig zu wissen ist, dass Sie dann wom\u00f6glich nicht mehr alle Websites uneingeschr\u00e4nkt aufrufen k\u00f6nnen.<\/p>\n

Eine neuere und wirksamere Methode sind Same-Site-Cookies: sie k\u00f6nnen gegen diese und \u00e4hnliche Angriffe wirkungsvoll sch\u00fctzen. Webapplikationen k\u00f6nnen durch Same-Site-Cookies verhindern, dass sich Site-Zugriffe von anderen Websites in Accounts einloggen. Bislang liegt bei der IETF<\/a> lediglich ein Entwurf f\u00fcr Same-Site-Cookies vor, jedoch werden sie von Googles Browser Chrome bereits unterst\u00fctzt<\/a>.<\/p>\n