Dipl.-Inform. Carsten Eilers

Nehmen wir als Beispiel mal eine Webmail-Anwendung: Nachdem der Benutzer sich auf einer HTTPS-geschützten Seite angemeldet hat und erfolgreich authentifiziert wurde, wird ein Cookie gesetzt, anhand dessen er danach identifiziert wird. Wer den Cookie kennt, kann auf die Mailbox des Benutzers zugreifen. Ganz konkret ist das z.B. bei der Nutzung ungeschützter WLAN-Verbindungen ein Problem, wie David Maynor und Robert Graham bereits 2007 auf der Konferenz "Black Hat USA" gezeigt haben (Berichte von George Ou und Brian Krebs). Mike Perry hat dazu ergänzend auf der Mailingliste Bugtraq berichtet, dass die Nutzung von HTTPS entgegen der Annahme von Robert Graham nicht als Schutz vor diesen Angriffen ausreicht.

Mike Perry hat dann 2008 auf der Sicherheitskonferenz Defcon ein Tool zur Demonstration dieser Angriffe vorgestellt: Der als Man-in-the-Middle agierende Angreifer fügt "on the fly" in eine gar nicht mit der angegriffenen Website in Verbindung stehenden Webseite einen Verweis auf ein Bild oder einen iframe von der angegriffenen Seite ein. Beim Laden der so präparierten Seite lädt der Browser des Opfers dieses Bild oder diesen iframe und sendet dabei den Cookie mit, der dann vom Angreifer belauscht wird. Das für den Angriff verwendete Tool CookieMonster kann für jede beliebige Webseite verwendet werden (Detaillierte Beschreibung). Weitere Informationen gibt diese Übersicht aller Blogeinträge von Mike Perry zum Thema.

Ein Tool ist nicht genug

Parallel zu Mike Perry und unabhängig davon hat Sandro Gauci von EnableSecurity ein gleichartiges Tool entwickelt: 'Surf Jack'. Dessen Funktion wird auch in einem Video demonstriert, außerdem gibt es ein Paper (PDF) mit einer Beschreibung des Angriffs.

Gegenmaßnahmen: Einfach, und doch komplex

Die Lösung des Problems ist ganz einfach: Für den Session-Cookie muss das 'Secure'-Flag gesetzt werden. Das ist weiter kein Problem, wenn der Cookie nur von sowieso nur über HTTPS zugänglichen Seiten verwendet wird. Wird er auch auf über HTTP zugänglichen Seiten benötigt, sind größere Änderungen nötig. Entweder muss die gesamte Website auf die Nutzung von HTTPS umgestellt werden, oder bei der Erkennung der Benutzer und ihres Authentifizierungsstatus muss größerer Aufwand betrieben werden. Es bietet sich z.B. folgende Möglichkeit an:

Lösung ohne Mithilfe des Benutzers

Statt eines Session-Cookies werden zwei separate Cookies verwendet: Einer zur Erkennung des authentifizierten Benutzers, z.B. "istEingeloggt", mit gesetztem 'Secure'-Flag, und einer zur bloßen Erkennung der Session ohne 'Secure'-Flag. Fehlt der "istEingeloggt"-Cookie beim Aufruf einer HTTPS-Seite, findet ein Angriff statt; Jemand versucht, sich mit einem ausgespähten Session-Cookie anzumelden. Der Benutzer wird daher abgemeldet und muss sich neu einloggen, was einem Angreifer mangels Kenntnis der Zugangsdaten nicht möglich ist.
Durch diesen Ansatz ist der Benutzer auch auf HTTP-Seiten erkennbar und kann ggf. die HTTPS-Seiten ohne erneute Authentifizierung aufrufen. Einem Angreifer ist das nicht möglich: Da er den notwendigen Cookie mit gesetztem 'Secure'-Flag nicht kennt wird er abgemeldet.

Lösung mit Mithilfe des Benutzers

Mike Perry hat einen anderen Ansatz vorgeschlagen, der ebenfalls mit zwei Cookies arbeitet: Die Benutzer haben die Wahl zwischen der Nutzung von HTTP und HTTPS und verwenden HTTPS nur in potentiell unsicheren Umgebunden wie z.B. einem offenen WLAN. Wird die Seite einmal über HTTPS aufgerufen, wird ein Cookie, z.B. "WantsSSL", ohne 'Secure'-Flag gesetzt, während gleichzeitig für den oder die bisher ungeschützten Session- und Authentifizierungscookies das 'Secure'-Flag gesetzt wird. Wird die Seite danach über HTTP aufgerufen, wird zwar der "WantsSSL"-Cookie übertragen, nicht aber die Session- und Authentifizierungscookies. Die Anwendung erkennt dann, dass der Benutzer zwar authentifiziert ist, aber auf die HTTPS-Version umgeleitet werden muss. Der Benutzer darf erst dann wieder HTTP verwenden, wenn er sich abgemeldet hat. Ein "Downgrade" auf HTTP darf nicht möglich sein, weil das ein möglicher Angreifer erzwingen könnte.

Mike Perry hat an seinem Ansatz zwei Nachteile gefunden: Ein Angreifer kann den "WantsSSL"-Cookie löschen, so dass der Benutzer denkt, er ist abgemeldet, wenn er die HTTP-Version aufruft. Evtl. loggt er sich dann darüber ein, obwohl er sich in einer unsicheren Umgebung befindet. Und ein Benutzer, der sich in einem unsicheren Netzwerk nie über HTTPS anmeldet, behält seine Session- und Authentifizierungscookies ohne 'Secure'-Flag, so dass diese mit dem oben beschriebenen Angriff ausgespäht werden können.

Ich habe noch einen dritten Kritikpunkt: Sollte man wirklich den u.U. völlig ahnungslosen Benutzern die Entscheidung überlassen, ob die Nutzung einer Webanwendung geschützt werden muss oder nicht? In den USA währen dann wahrscheinlich einige Disclaimer-Seiten vor der Webanwendung nötig, die auf alle möglichen (und natürlich unmöglichen) unsicheren Umgebungen hinweisen, in denen besser HTTPS genutzt werden sollte. Außerdem: Wer bekommt denn die Schuld zugewiesen, wenn ein Angreifer aufgrund fehlender HTTPS-Nutzung z.B. ein E-Mail-Konto übernimmt und vertrauliche Daten daraus veröffentlicht? Natürlich ist der Benutzer Schuld, er hätte ja HTTPS nutzen können. Aber wird in der Öffentlichkeit nicht eher der Betreiber in Erklärungsnöte geraten, der HTTPS nicht erzwungen hat?

Soviel zum Thema "Sichere Nutzung von HTTPS und Cookies". Ein letzter Hinweis noch: Sofern auf die Session-Cookies nicht über JavaScript zugegriffen wird, kann zusätzlich als "Defense in depth"-Maßnahme gegen XSS-Angriffe das 'HttpOnly'-Flag gesetzt werden.

Update
Ende Oktober 2010 wurde ein Tool zum Ausspähen unsicherer Cookies veröffentlicht: Firesheep. Mehr dazu erfahren Sie hier.

In der nächsten Folge geht es um zwei miteinander verwandte Themen, die eigentlich nichts miteinander zu tun haben (auch dieser Widerspruch wird dann aufgeklärt): Neue Entwicklungen beim Binary Planting sowie die aktuell bekannt gewordene Schwachstelle im GNU-C-Loader, die das Erlangen von root-Rechten ermöglicht.

Carsten Eilers

Übersicht über alle Artikel zum Thema

HTTPS und Cookies sicher einsetzen

Angriff und Abwehr des CookieMonster

Firesheep fängt ungeschützte Cookies

Standpunkt: Firesheep - unverantwortlich oder dringend nötig?