Sichere Cookies, unsichere Cookies, geklaute Cookies - dieser Standpunkt Sicherheit dreht sich nur um ein Thema: Cookies. Denn Vorsicht:

Der Cookieklau geht um

Ein Tool zum Ausspähen von Cookies, deren 'Secure'-Flag nicht gesetzt ist, das klingt harmlos, oder? Cookies, bei denen das Flag für 'Sicher' nicht gesetzt ist, können ja nicht besonders wichtig sein. Das sollte man meinen, und das stimmt auch. Zumindest in der Theorie. Praktisch sieht das leider anders aus.

Flagge zeigen, aber richtig!

Das 'Secure'-Flag legt fest, ob ein Cookie nur über geschützte HTTPS-Verbindungen oder auch über ungeschützte HTTP-Verbindungen übertragen werden darf (About Security #151). Durch das Setzen des Flags wird verhindert, dass die betroffenen Cookies über normale HTTP-Verbindungen übertragen und dabei belauscht werden können. Praktisch sieht das z.B. so aus: Ein Benutzer meldet sich auf einer HTTPS-geschützten Seite bei der Webanwendung an, und die setzt nach erfolgreicher Authentifizierung einen Session- und/oder Authentifizierungscookie mit gesetztem 'Secure'-Flag. Solange sich der Benutzer im HTTPS-geschützten Bereich der Webanwendung bewegt, werden diese Cookies bei jedem Aufruf mit übertragen. Verlässt er den geschützten Bereich und ruft eine Seite über HTTP auf, werden die Cookies nicht übertragen. Ein Angreifer, der die Kommunikation des Benutzers belauschen kann, bekommt die Session- und/oder Authentifizierungscookies also nie zu sehen, da sie immer nur über die geschützte HTTPS-Verbindung übertragen werden.

Wird das 'Secure'-Flag nicht gesetzt, werden die Cookies beim Aufruf jeder Seite der betreffenden Website übertragen: Verlässt der authentifizierte Benutzer aus obigen Beispiel den geschützten Bereich, werden seine Session-/Authentifizierungscookies weiterhin an die Webanwendung gesendet. Da die Verbindung nun nicht mehr über HTTPS, sondern das ungeschützte HTTP erfolgt, kann der Angreifer sie belauschen und sich danach gegenüber der Webanwendung als der betreffende Benutzer ausgeben, sofern es keine weiteren Schutzmaßnahmen gibt.

Bug oder Feature?

Ob dieses Verhalten ein Problem ist oder nicht, hängt ganz vom Anwendungsfall ab. Es ist natürlich auch möglich, dass eine Webanwendung die Authentifizierung und z.B die Benutzerverwaltung über geschützte Verbindungen abwickelt, die spätere Nutzung z.B. eines Forums dann aber über ungeschützte Verbindungen erfolgt. Dann ist es durchaus gewollt, dass ein bei der Anmeldung gesetzter Session-Cookie auch im ungeschützten Bereich der Webanwendung übertragen wird. Nur darf sich die Webanwendung dann eben nicht darauf verlassen, dass nur der authentifizierte Benutzer diesen Cookie an die Webanwendung senden kann.

Mail als Beispiel

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 bewiesen haben. Mike Perry hat schon im August 2007 darauf hingewiesen, dass HTTPS-Verbindungen nicht immer vor einem Angriff schützen. Da es aber keine Demonstration des Problems gab, wurde es weitgehend ignoriert: Immer noch setzen viele Websites das 'Secure'-Flag nicht, obwohl es eigentlich nötig wäre. Na, wer nicht hören will, muss eben fühlen, oder:

Demo gewünscht? Kein Problem...

Auf der Sicherheitskonferenz Defcon hat Mike Perry nun ein Tool vorgestellt, das genau diese Angriffe demonstriert. Dabei geht er noch einen Schritt weiter als 2007: Während er 2007 allgemein beschrieb, wie ein Angreifer die über ungeschützte Verbindungen übertragenen Cookies passiv belauschen kann, hat er dieses Jahr einen aktiven Angriff demonstriert. Der Angreifer fügt in eine gar nicht mit der angegriffenen Webseite in Verbindung stehenden Webseite einen Verweis auf ein Bild oder einen iFrame von der angegriffenen Seite ein und lässt die Seite vom Opfer öffnen. Wird die präparierte Seite geladen, versucht der Browser des Opfers dieses Bild oder diesen iFrame zu laden 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 und soll in zwei Wochen veröffentlicht werden.

Ein Tool ist nicht genug

Wer das schon jetzt ausprobieren möchte, muss nicht auf Mike Perrys CookieMonster warten. Parallel dazu 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. Und wenn zwei Leute unabhängig voneinander dasselbe entwickeln und veröffentlichen, gibt es ja vielleicht auch noch einen bösen Dritten, der nach dem Entwickeln gleich zur Tat geschritten ist und auf das Veröffentlichen verzichtet hat...

WLAN, LAN, WAN,...

Der Angriff ist natürlich nicht nur über WLAN möglich, sondern immer dann, wenn der Angreifer den Netzwerkverkehr des Opfers belauschen kann. Das geht z.B. in lokalen Netzen über ARP-Spoofing (About Security #60) - oder über DNS-Cache-Poisoning in beliebigen Netzen. Wie schon erwähnt: Dan Kaminskys DNS-Schwachstelle wird uns noch einige Zeit beschäftigen. Das war übrigens auch wieder so ein Fall, bei dem erst jemand einen Proof-of-Concept schreiben musste, damit allgemein bekannt wird, dass der bisherige Patch nur ein Notflicken ist und Angriffe nicht verhindert, sondern nur behindert.

Hilfe!

Der Benutzer ist diesen Angriffen im Allgemeinen hilflos ausgeliefert. Ob das 'Secure'-Flag gesetzt wird oder nicht, entscheidet die Webanwendung und damit deren Betreiber. Benutzer von Google Mail haben seit Ende Juli die Möglichkeit, in den Einstellungen die ständige Verwendung von HTTPS zu wählen, womit auch das Setzen des 'Secure'-Flags aktiviert wird. Es empfiehlt sich also, diese Einstellung schnell zu aktivieren. Und ansonsten bleibt nur die Hoffnung, dass alle Webanwendungen das Flag richtig nutzen. Ach ja: Und man sollte natürlich keine ungeschützten WLANs nutzen. Leider lässt sich das nicht immer vermeiden.

Und nun?

Wenn Sie eine Webanwendung betreiben oder entwickeln, sehen Sie sich die einmal genau an: Ist sie in geschützte und ungeschützte Bereiche getrennt? Wenn es eine Trennung gibt: Werden im geschützten Bereich gesetzte Cookies im ungeschützten Bereich benötigt? Wenn nicht, sollte für diese Cookies das 'Secure'-Flag gesetzt sein. Ist das bisher nicht der Fall, haben Sie jetzt doch bestimmt etwas zu erledigen, oder? Werden im geschützten Bereich gesetzte Cookies im ungeschützten Bereich benötigt, stellt sich die Frage, ob das so sein muss. Vielleicht lässt sich da ja die Sicherheit der Anwendung noch verbessern?

Noch kurz was zum Microsoft-Patchday

Laut Microsoft Security Response Center Blog wurde ein Bulletin aus Qualitätsgründen nicht veröffentlicht. So erfreulich wie ich das finde, stutze ich doch etwas bei folgendem Satz aus dem Blogeintrag: "Microsoft has heard from customers that the quality of updates is very important ..." Microsoft hat von Kunden gehört, dass die Qualität der Updates wichtig ist. Aha. Gut, dass denen das mal jemand gesagt hat. Aber sollte das nicht eigentlich eine Selbstverständlichkeit sein? Mag wirklich irgendwer Bananensoftware? Wieso muss ich da gerade an Steve Ballmer denken? Na ja, die nächste Entwicklerkonferenz kommt bestimmt, und 'Quality' lässt sich doch auch gut schreien...

Carsten Eilers