Dipl.-Inform. Carsten Eilers

HTTP Request Hijacking, kurz HRH, wurde am 29. Oktober 2013 von Adi Sharabani und Yair Amit von Skycure auf der Sicherheitskonferenz "RSA Conference Europe 2013" vorgestellt und außerdem im Blog von Skycure beschrieben.

Beim HRH wird das Caching-Verhalten von Mobile-Apps, insbesondere iOS-Apps, ausgenutzt. Die Apps cachen Responses mit dem HTTP-Status-Code 301, Moved Permanently. Der wird für dauerhafte Umleitungen verwendet, zum Beispiel wenn eine URL sich aufgrund eines Umbaus der Website oder des Zusammenlegens zweier Websites dauerhaft ändert. Nachdem die Response im Cache gespeichert wurde wird danach immer die darin angegebene URL statt der Original-URL aufgerufen.

Angriff nur über Man-in-the-Middle möglich

HRH ist nur im Rahmen eines Man-in-the-Middle-Angriffs, zum Beispiel in einem offenen WLAN, möglich. Der MitM belauscht die HTTP-Requests und antwortet auf die für seine Zwecke nützlichen mit einer Response mit einem HTTP-Status-Code 301, der zu einem Server unter seiner Kontrolle führt. Außerdem unterdrückt er natürlich die Antwort des richtigen Servers. Ruft der Benutzer zum Beispiel
http://www.bank.example/onlinebanking.cgi
auf, kann der MitM mit einer 301-HTTP-Response mit einer Umleitung zu
http://www.angreifer.example/phishing.php
antworten.

In einem normalen Webbrowser wäre das noch kein großes Problem, da sich durch die Umleitung auch die Anzeige in der URL-Zeile ändert. Wenn der Benutzer aufpasst, merkt er, dass er sich nicht auf dem Server seiner Bank befindet und wird tunlichst darauf verzichten, irgend welche Daten einzugeben. Viele Mobile-Apps zeigen die URL aber nicht an, so dass der Benutzer nicht merkt, dass er umgeleitet wurde.

Besonders unangenehm ist der Umstand, dass die gefälschte Umleitung auch im Cache gespeichert wird: Ruft der Benutzer später die URL erneut auf, landet er wieder auf dem falschen Server. Auch dann, wenn der MitM längst nicht mehr in der Verbindung sitzt.

Das Cachen kann übrigens auch ein Problem für völlig harmlose Websites sein, falls die mal eine verwendete 301-HTTP-Response wieder ändern wollen. Denn die einmal im Cache gespeicherte 301-HTTP-Response kann von der Website unter Umständen nicht so einfach aus dem Cache gelöscht werden.

Das Onlinebanking im obigen Beispiel habe ich übrigens nur der Dramaturgie wegen verwendet. Beim Onlinebanking wird der Netzwerkverkehr im Allgemeinen über HTTPS geschützt, und dann schaut der MitM in bzw. auf die Röhre. Realistischer sind Angriffe auf zum Beispiel News-Apps, um den Benutzer über falsche Nachrichten zu beeinflussen.

Die Entdeckung der Schwachstelle

Erstmals aufgefallen ist die Schwachstelle als Fehler in der App von Skycure. Bei weiteren Untersuchungen wurde Yair Amit klar, dass es sich um eine Schwachstelle handelt, die in vielen Apps zu finden ist. Und zwar in so vielen, dass an eine "Responsible Disclosure", bei der die betroffenen Entwickler vor der Veröffentlichung der Schwachstelle informiert werden, nicht zu denken war. Daher entschloss man sich bei Skycure zur Veröffentlichung der Schwachstelle an sich, ohne die Namen von betroffenen Apps zu nennen, bevor diese gepatcht sind. Als Beispiel dient Skycures eigene Journal App. Die funktioniert wie viele Nachrichten-Apps: Sie holt den Newsfeed im JSON-Format von einem Server, parst ihn und zeigt ihn an. Ändert ein Angreifer den Server über eine 301-HTTP-Response, wird die JSON-Datei vom Server des Angreifers geholt.

Die Folgen eines Angriffs

Bei einem klassischen Cache-Poisoning-Angriff würde dem Opfer eine gefälschte News-Datei unter geschoben. Die würde zwar auch gecached, der Angreifer kann aber danach keine weiteren Manipulationen vornehmen. Durch die Änderung des Servers kann der Angreifer auch nach dem Vergiften des Caches den Netzwerkverkehr der App manipulieren.

Für den Angriff gelten aber zwei Einschränkungen:

1. Der Angreifer muss als MitM agieren, sich also beim Beginn des Angriffs zum Beispiel im gleichen offenen WLAN wie das Opfer befinden. Die folgenden Aktionen können überall erfolgen, da sie über den Server des Angreifers ablaufen.
2. Der Angriff funktioniert nur gegen HTTP-Traffic problemlos, bei HTTPS-geschützten Verbindungen ist zumindest zusätzlicher Aufwand nötig.

Gegenmaßnahmen

Skycure hat die Schwachstelle in iOS-Apps gefunden. Mir fällt gerade kein Grund ein, warum nicht auch die Apps anderer Mobilsysteme betroffen sein sollten, sofern sie 301-HTTP-Responses cachen. Für iOS werden zwei mögliche Gegenmaßnahmen genannt: Zum einen kann die Kommunikation über ein verschlüsseltes Protokoll, zum Beispiel HTTPS, abgewickelt werden. Zum anderen kann ein neues Subklassen-Object von NSURLCache erzeugt werden, dass 301-HTTP-Responses nicht cached, und eine neue Cache-Policy für die App angelegt werden.

Für Unternehmen bietet Skycure eine Sicherheitslösung an, die die Mobilgeräte der Belegschaft schützen. iOS-Benutzern wird geraten, im Fall eines vermuteten Angriffs die betroffene App zu löschen und neu zu installieren, um den Cache zuverlässig zu löschen. Außerdem sollten alle Apps auf dem aktuellen Stand sein, damit Updates zum Beheben der Schwachstelle zügig installiert werden. Das würde ich auch allen Unternehmen empfehlen.

Wie gefährlich ist HRH?

Erst mal ist HRH nur ein weiterer Angriff, der einem MitM möglich ist. Der kann sowieso den gesamten HTTP-Traffic nach Belieben manipulieren, und auch Cache-Poisoning-Angriffe sind ein alter Hut. Das Problematische am HRH ist dessen permanente Wirkung: Auch wenn der Benutzer den Bereich des MitM verlässt, wirkt die Umleitung weiter. Wenn das Opfer so eines Angriffs später die betroffene App nutzt, verbindet die sich mit dem Server des Angreifers, egal wo der Benutzer sich aufhält.

Die entscheidende Frage ist also mal wieder: Wie gross ist die Wahrscheinlichkeit, Opfer eines MitM-Angriffs zu werden, und wie gross ist die Wahrscheinlichkeit, dass dieser MitM HRH einsetzt? Für ersteres verwende ich gerne das Beispiel eines Rogue Access Points. Würde man den zum Beispiel auf einer Konferenz oder Messe aufstellen, würde ihn sicher viele Benutzer nutzen, und schon hätten die einen MitM in der Leitung. Opfer eines MitM-Angriffs kann mal also schnell werden. Ob so ein MitM dann HRH nutzen würde, ist eine andere Frage. Darauf weiß ich auch keine Antwort.

Carsten Eilers