Skip to content

HTTP Request Hijacking - Kein Grund zur Panik!

HTTP Request Hijacking ist vielleicht ein genialer PR-Schachzug, aber bei weitem nicht die Bedrohung, zu der es aufgebauscht wird. Aber wenn man schreiben kann, das Hunderttausende iOS-Apps bedroht sind, ergibt das natürlich eine schöne Schlagzeile. Besteht wirklich Grund zur Panik? Garantiert nicht. Oder zur Besorgnis? Nicht mehr als sonst.

Opfer von HRH habe noch ganz andere Probleme

Erst mal möchte ich mich zwei Mal selbst zitieren:

"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."
(aus meiner Beschreibung des HRH)

und

"Kein Grund zur Panik. HTTP Request Hijacking setzt einen Man in the Middle voraus, zu Hause und im Büro dürften 99,999% aller Benutzer sicher sein. Kritisch sind nur offene WLANs, und wer die benutzt, muss sowieso aufpassen."
(aus meinem Kommentar unter einer Meldung auf webmagazin.de)

Was ich im ersten Text nicht explizit erwähnt hatte, habe ich im zweiten quasi nachgereicht. Und jetzt noch ein dritter Punkt: Wer einen Man-in-the-Middle in der Leitung hat, hat noch ganz andere Probleme als einen möglichen HRH-Angriff. Der MitM hat die vollständige Kontrolle über den Netzwerkverkehr und kann beliebigen Schadcode und beliebige falsche Informationen einschleusen. Und dadurch das Opfer zum Beispiel dazu bringen, ein angebliches, dringend erforderliches Update zu installieren und ihm dabei dann seinen Schadcode unter schieben. Ein HRH-Angriff ist dagegen ein schlechter Witz. Zumindest kann ich mir keinen Fall vorstellen, in dem ein MitM über HRH größeren Schaden anrichten kann als er es sowieso schon kann. Also: Kein Grund zur Panik!

HRH ist eine Schwachstelle. Und sie muss, wie jede Schwachstelle, behoben werden. Grund zur Panik besteht wegen der Schwachstelle aber absolut nicht. Wer allerdings einem MitM in der Leitung hat, der hat auch Grund zur Panik. Denn wer weiß, was der schon alles angestellt hat? Über einen HRH-Angriff und eine dadurch möglicherweise fehlgeleitete App würde ich mir in so einem Fall zuletzt Gedanken machen.

Die App-Entwickler haben nichts falsch gemacht!

Übrigens haben die Entwickler der betroffenen Apps rein gar nichts falsch gemacht. Denn im Standard für HTTP, RFC 2616, steht beim Status-Code 301, Moved Permanently, ausdrücklich:

"This response is cacheable unless indicated otherwise."

Ein Server, der nicht möchte, dass seine Antwort im Cache landet, muss das dem Client also mitteilen. Ansonsten wird sie im Cache gespeichert. Ein möglicher Missbrauch des Statuscodes ist dort gar nicht berücksichtigt. Im Fall eines Webbrowsers ist eine Umleitung über eine 302-Response auch nicht besonders problematisch, da die geänderte URL ja in der URL-Zeile angezeigt wird. Ein Problem ist sie nur im Fall einer App, da die die URL meist nicht anzeigt, der Benutzer also nicht merkt, dass er Daten von einem anderen Server abfragt.

Die App-Entwickler, die ja meist auch nur die entsprechenden Funktionen von Betriebssystem oder verwendeten Frameworks etc., verwenden, halten sich also völlig korrekt an den HTTP-Standard. Das einzige, was man ihnen unter Umständen vorwerfen kann, ist die Verletzung des alten Grundsatzes "Traue nie dem Kommunikationspartner". Ebenso, wie der Server prüfen muss, ob eine Verbindungsanfrage von einem Client auch wirklich von behaupteten Absender stammt und erlaubt ist, muss zumindest in kritischen Fällen der Client prüfen, ob die Antwort auch wirklich vom erwartete Server stammt und unverfälscht ist.

Dafür werden zum Beispiel beim Onlinebanking HTTPS und weitere Protokolle verwendet. Darüber, ob das beim Beispiel einer Nachrichten-App, wie sie von Skycure genannt wird, wirklich nötig ist, kann man trefflich streiten. Ich finde das schon etwas übertrieben. Wichtige Entscheidungen sollte man ja wohl besser nicht nur aufgrund einer Meldung in einer App treffen. Und wenn man zusätzliche Informationsquellen nutzt, wird die über HRH gefälschte Nachricht in der App schnell als Falschmeldung enttarnt.

Carsten Eilers

Trackbacks

Keine Trackbacks