Timing-Schwachstellen: bist Du bei Heise eingeloggt?

Durch die Auswertung der Information über die Ladezeit von Webseiten können Schlüsse über ihren Inhalt oder Zustand gezogen werden. Eine volle Seite lädt länger als eine leere, ein Bild im Cache des Webbrowsers lädt schneller als übers Netz, ein angemeldeter Nutzer verursacht eine andere Serverlast als ein anonymer. Diese Messungen können für den Webseitenbesucher unsichtbar durchgeführt werden.

Diese Art der Informationsgewinnung wird als „Seitenkanal-Angriff“ bezeichnet. Er zeichnet sich dadurch aus, dass der Angriff nicht direkt gegen das Ziel, sondern z.B. anhand von Messungen des Zeitverbrauchs der Ressourcen im Ziel erfolgt. Das Thema wurde allgemein umfassend bereits im Jahr 2000 analysiert: „Timing Attacks on Web Privacy“. Eine Folgearbeit von 2007 („Exposing Private Information by Timing Web Applications“) geht genau auf die Angriffe dieser Art auf Webapplikationen ein. Im Folgenden möchte ich einen solchen Angriff, wie in der zuletzt genannten Arbeit, demonstrieren.

same origin policy

Bindet ein Angreifer eine fremde Zielseite in seine Webseite ein, so verhindert die „same origin policy“ des Webbrowsers, dass er anschließend über JavaScript, Zugriff auf die Inhalte der fremden Seite erlangt. Er bekommt so gut wie keine Information darüber was dort geschieht, ist sozusagen blind. Diese Sicherheitsmaßnahme ist in allen großen Webbrowsern implementiert und immer verfügbar.

Um eine Interaktion in komplexen Ajax-Anwendungen zu ermöglichen, verraten diese eingebundenen, fremden Webseiten nur wenige Ereignisse an die umschließende Webseite. Uns interessiert hier das in JavaScript verfügbare Ereignis „onerror„. Es dient der Fehlerbehandlung, um z.B. zu erkennen, dass ein Bild von einer fremden Seite nicht geladen werden konnte.

Gerade bei Heise.de eingeloggt?

Durch eine geringfügige und auch durch Anfänger leicht umsetzbare Modifikation des bei „Exposing Private Information by Timing Web Applications“ zu findenden JavaScript-Codes ist z.B mit ziemlich hoher Wahrscheinlichkeit zu ermitteln, ob der Leser dieser Zeilen bei Heise.de einen Account hat und gerade eingeloggt ist.

Die Methode dafür ist in „Exposing Private Information by Timing Web Applications“ in Kapitel 4.3 „Testing for boolean values“ beschrieben:

This is primarily because the web
site in question externally redirects a logged in user from
the front page to the primary member page, which adds a
full network round-trip to the time it takes the browser to
complete the request.

Es handelt sich hier also zuerst um einen Cross-Site-Request-Forgery-Angriff, bei dem der Webbrowser das Anmeldecookie an die eingebundene Zielseite sendet und dort eine vorgesehene Inhaltsänderung hervorruft.

Betrachtet man die Webseite der Profilinformationen bei Heise.de so ist leicht festzustellen, dass ein nicht angemeldeter Nutzer durch eine Umleitung zur Anmeldeseite geschickt wird, während ein Nutzer mit einem gültigen Anmeldecookie die Informationen direkt angezeigt bekommt. Vergleicht man die dafür benötigte Zeit mit einem Seitenaufruf, der ohne eine Weiterleitung auskommt (hier die Anmeldeseite selbst), so ergibt sich in den meisten Fällen ein Zeitunterschied, der gut messbar und nachweisbar ist. Vermutlich zugunsten der Sicherheit und der Usability, blendet Heise.de bei den Anmeldeseiten keine Werbebanner ein. Das kommt den timing-Angriffen zugute, die ohne die Störeinflüsse („noise“) sehr genau werden.

1. Die Zielwebseite wird über ein IMG-Tag eingebunden.
2. Ein direkter Zugriff auf Informationen der eingebundenen Seite ist nicht möglich.
3. Über das JavaScript-Event „onerror“ kann jedoch die Ladezeit („Seitenkanal“) ermittelt werden.

timing-Messung durchführen

Fünf aufeinander folgende Messungen und der errechnete Durchschnitt ist in diesem Fall nur eine schnelle und unpräzise Lösung. Sie sind jedoch ausreichen um festzustellen, ob der aktuelle Webseitenbesucher weiter geleitet wird (also keinen Zugang zu Heise.de hat oder abgemeldet ist) oder angemeldet ist. Zum Testen des eigenen Login-Status bei Heise.de, auf „Zeitmessung starten“ klicken. Je nach Server- und Netzwerkauslastung kann mit jedem Klick ein anderes Ergebnis entstehen. Um den Gegentest zu machen ist die Anmeldung bei heise.de nötig.

Gegenmaßnahmen

1) „Exposing Private Information by Timing Web Applications“ schlägt eine Server-Erweiterung vor, die jede Serverantwort um eine über Zufall generierte Zeit verzögert.

2) Eine Zufallsverzögerung am Skript selbst. Für PHP wäre „sleep“ etwas zu groß dimensioniert da es nur ganze Sekunden pausiert. Eine mathematisch aufwändige Berechnung würde Rechenzeit beanspruchen – wäre also zu „teuer“. Die Verwendung von „usleep“ ist zu empfehlen, da die Zeit in Mikrosekunden angegeben werden kann.

3) Einbinden einer zufälligen Anzahl von Elementen auf der Webseite, die per Design unterschiedlich lange Ladezeiten haben. Beispielsweise durch die Bereitstellung auf unterschiedlich im Netzwerk eingebundene Server.

4) Abschalten von JavaScript auf Clientseite. noscript ist eine gute Wahl für Mozilla Firefox-Nutzer.

5) Immer auf sicherheitskritischen Webseiten abmelden, bevor andere Webseiten aufgerufen werden, Verwenden eines separaten Webbrowsers für sicherheitskritische Webseiten, Verwenden von unterschiedlichen Nutzerprofilen in Mozilla Firefox. Mehrere Webbrowser lassen sich voneinander getrennt beispielsweise mit dem kostenlosen Sandboxie verwalten.

6) Speziell zum oben genannten Test auf heise.de würde eine Absicherung der Anmeldeseiten gegen CSRF-Angriffe hilfreich sein, denn dann würde die eingebundene Seite keine automatische Anmeldung vornehmen können.

Ich nehme gerne andere Vorschläge entgegen.

Auch nach den Änderungen 1-3 wird es dem Angreifer gelingen, zumindest das Vorhandensein von Webseitenelementen im Cache des Opfers zu messen. Dagegen würde nur eine Abschaltung oder Unterbindung des Caches vom Server zum Client helfen. Die Nebenwirkung wäre jedoch im Vergleich zur gewonnenen Sicherheit zu prüfen.

Dies ist kein Angriff

Die Bezeichnung „timing-Angriff“ kommt von der ursprünglichen Verwendung der Methode: dem Angriff auf Chiffrierschlüssel, um diese zu ermitteln. Die Messung von Serverantwortzeiten wie hier gezeigt, stellt keinen Angriff auf die Ressourcen einer Webseite und keine Gefahr dar. Die Frage ist dann natürlich, wie die gewonnenen Informationen verwendet werden. Es dürfte daher auch schwer sein, Webentwicklern oder Seitenbetreibern diese Schwachstelle verständlich zu machen.