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.

Das könnte Dich auch interessieren …

6 Antworten

  1. Diese Schwachstelle Verantwortlichen zu erklären dürfte sehr schwer werden. Viele Seitenbetreiber, aber auch Entwickler, tuen sich schon schwer die Gefahren von Cross-Site Scripting zu verstehen.

    Ich versuche es aber trotzdem mal… :O)

    Eine WebApplikation meldet bei unautorisiertem Zugriff einen Alert an die IT-Sicherheitsabteilung, um diese Meldung nicht zu provozieren muß ein Angreifer sicher sein das sein Opfer angemeldet ist, bevor er ihm einen manipulierten Link unterschiebt. Solch einen hohen Sicherheitslevel haben sicher nur wenige WebApplikationen, also könnte ein Angreifer einfach immer einen CSRF-Link seinen Opfern anbieten, unabhängig davon ob sie angemeldet sind oder nicht. Wenn diese Anfragen aber zu häufig ohne Anmeldung benutzt werden und zu Fehlermeldungen bzw. Weiterleitungen zum Login führen, wird dies irgendwann in den Logfiles auffallen. Also wäre es auch hier sinnvoller nur angemeldeten Usern den Deeplink zu senden.

    Ein Szenario in dem solch eine Schwachstelle relevant ist ist sicher nicht sehr häufig anzutreffen, aber wo sie auftritt ist sie sehr wahrscheinlich sehr kritisch. Also ist diese Schwachstelle bestimmt auch eine die man im Hinterkopf behalten sollte.

    Für einen Angreifer ist es natürlich am besten gar nicht aufzufallen und wer weiß schon wo überall Daten gestohlen werden ohne das es jemals bemerkt wird.

  2. Paul sagt:

    Ein sehr interessanter Artikel, schön geschrieben und verständlich erklärt. Vielen Dank.
    Sicher ist das die einzige Möglichkeit die Entwickler zu sensibilisieren, auch wenn es scheint das sich die wenigsten dafür interessieren. Aber die kriegen das auch noch mit (irgendwann) :)

    Voller Zuversicht ins neue Jahr!

  3. valentin sagt:

    ist das nicht auch ein problem, welches das surfen mit tor betrifft?

  4. Erich Kachel sagt:

    Mit TOR dürfte die Genauigkeit der Seitenkanal-Analyse nachlassen, da die Netzwerkverzögerung durch die Proxys variieren wird. Durch die Auswahl einer neuen Route durch das onion-Netzwerk ist die Messung bestimmt nicht mehr aussagekräftig. Alles aber nicht getestet.

  1. 14. Januar 2009

    […] Dabei gibt es einige mehr (und seit Jahren bekannte) Möglichkeiten wie „protected images“ und „Seitenkanal-Analysen“ um festzustellen, ob jemand auf einer fremden Webseite angemeldet ist. Während dieser Bug […]

  2. 4. Februar 2009

    […] Damit die Wertung auch korrekt gezählt wird, musst Du zuerst bei Heise.de eingeloggt sein. (Finde heraus, ob Du zur Zeit bei Heise.de eingeloggt bist!) Nach dem Klick auf dem Knopf wird für kurze Zeit ein kleines Popup-Fenster eingeblendet. Dieses […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.