Dipl.-Inform. Carsten Eilers

Cookiejacking und die dabei ausgenutzte Schwachstelle im Internet Explorer wurde von Rosario Valotta entdeckt und auf den Sicherheitskonferenzen Swiss Cyber Storm 2011 (12. - 15. Mai 2011) und Hack in the Box Amsterdam 2011 (17. - 20. Mai 2011) vorgestellt. Kurz darauf hat er eine FAQ zum Cookiejacking veröffentlicht. Von der Schwachstelle sind alle Versionen des Internet Explorer 6, 7 und 8 betroffen, getestet wurden sie auf Windows XP SP3 und Windows 7. Über einen etwas anderen Angriffsvektor ist auch der Internet Explorer 9 angreifbar.

In der Präsentation (PDF) für die Swiss Cyber Storm nennt Rosario Valotta folgenden Zeitplan:

28. Januar:

Meldung der Schwachstelle an das Microsoft Security Response Center (MSRC), die Beta-Version des IE 9 ist betroffen

14. März:

Offizielles Release-Datum des IE 9, die veröffentlichte Version ist nicht von der Schwachstelle betroffen

Ende April (2 Wochen vor der Konferenz):

Ein neuer Angriffsvektor funktioniert auch im IE 9

Der Angriff im Detail

Das Sicherheitszonenmodell des Internet Explorer verhindert, dass eine Seite aus der Internetzone auf Daten in der lokalen Zone, z.B. der Festplatte, zugreifen kann. Die Schwachstelle im IE besteht darin, dass diese Einschränkung für Cookies nicht gilt, so dass sie in einem iframe geladen werden können:

<iframe src="file://C:/Users/%user%/AppData/Roaming/Microsoft/Windows/Cookies/%user%@google[1].txt">

Dort kann wie bereits bei den Drag&Drop-Clickjacking-Angriffen als 'content extraction' beschrieben der unsichtbare Cookietext markiert und vom Benutzer aus dem iframe in das umgebende Fenster gezogen und dort fallengelassen werden. Von dort aus gelangt er dann zum Angreifer. Damit der Benutzer die Drag&Drop-Aktion ausführt, lässt Rosario Valotta ihn ein kleines Spiel spielen.

Cookiejacking ist also eine Kombination aus der Schwachstelle im IE, die den Zugriff auf die Cookies erlaubt, und der bereits bekannten 'content extraction' per Clickjacking, die bisher eine mehr oder weniger theoretische Bedrohung war.

Damit der Cookie zuverlässig ausgewählt wird, setzt Rosario Valotta zwei ineinander verschachtelte iframes ein: Ein äußerer, der beim Aktivieren des onfocus-Events automatisch scrollt, und ein innerer, der den Cookie enthält. Fährt das Opfer mit dem Mauszeiger über den inneren iframe und drückt dann den Mausknopf, wird der onfocus-Event ausgelöst und der äußere iframe scrollt, wobei der Cookie-Text selektiert wird.

Angriff mit Haken und Ösen

Der Angriff ist nicht gerade einfach, denn der Angreifer muss den genauen Pfad zum Cookie kennen, der u.a. von der Betriebssystemversion des Opfers und dessen Windows-Benutzernamen abhängt. Der Pfad sieht für Windows Vista und 7 z.B. so aus:

C:/Users/%user%/AppData/Roaming/Microsoft/Windows/Cookies/%user%@google[1].txt

Windows XP speichert die Cookies unter C:/Documents and Settings/%user%/Cookies/.

Die Betriebssystemversion kann z.B. dem JavaScript-Objekt navigator.userAgent entnommen werden. Die Ermittlung des Benutzernamens ist etwas schwieriger. Rosario Valotta verschafft ihn sich, indem er in die präparierte Webseite ein Bild von einem SMB-Netzwerkshare einbettet. Für den Zugriff auf das Bild ist eine NTLM-Authentifizierung notwendig, bei der der Benutzername als Klartext übertragen wird. Dabei kann er von einem Skript, dass die Daten am TCP-Port 445 überwacht, protokolliert werden.

Nachdem diese Hürden genommen wurden, muss der Benutzer noch dazu gebracht werden, das untergeschobene Spiel zu spielen und damit die Drag&Drop-Aktion auszuführen.

Das klingt zwar, als wäre ein Angriff nicht besonders erfolgversprechend, Rosario Valotta gelang es aber, innerhalb von 3 Tagen auf Facebook mehr als 80 Cookies zu sammeln - obwohl er nur 150 Facebook-"Freunde" hat. Und wie? Indem er die Opfer ein Puzzle spielen ließ, bei dem sie das Foto einer attraktiven Frau entkleiden sollten.

Wie gefährlich ist das?

Microsoft stuft die Gefahr durch das Cookiejacking laut Michael Kranawetter, Microsofts Chief Security Advisor für Deutschland, aufgrund der notwendigen Nutzeraktivität als "moderat" ein: Der Benutzer muss eine bösartige Seite besuchen und dort z.B. ein Spiel spielen. Beides ist aber nicht gerade ungewöhnlich, denn die "bösartige Seite" kann heutzutage jede Seite sein, auch und gerade in Social Networks.

Jim Walter von McAfee kommentiert das Cookiejacking in einem Blogbeitrag mit dem Titel "‘Cookiejacking’ Poses Minimal Danger if You Keep Good Habits", übersieht aber einiges. Dass der Angreifer Benutzername und Cookie-Pfad kennen muss, ist kein Problem, wie Rosario Valotta bewiesen hat. Und ob Cookies Klartext oder Schlüsseltext enthalten, ist schlicht irrelevant. Zum einen ist es gute Sicherheitspraxis, keine Zugangsdaten in Cookies zu speichern, zum anderen hat es ein Angreifer auf die auch gar nicht abgesehen, der will nur einen gültigen Session-Cookie erbeuten, mit dem er dann im Namen des Opfers auf die betroffene Website zugreifen kann. Und was die kurze Lebenszeit von Cookies betrifft, sehen meine Erfahrungen auch etwas anders aus. Auch sein letzter Rat ist nicht gerade zielführend: "And, finally, never, ever allow a website to remember your sessions! That keeps your cookies valid for future sessions." Das stimmt so i.A. nicht. Wird die "Remember me"-Funktion korrekt implementiert, wird der Benutzer zwar erkannt, muss sich aber erneut einloggen, bevor er auf die Website zugreifen kann.
Ein besserer Rat ist "Melden Sie sich auf der Website ab, wenn Sie mit der Nutzung fertig sind", denn dann wird der Session-Cookie ungültig und für einen möglichen Angreifer wertlos.

Robert McArdle von Trend Micro stuft die Gefährdung deutlich höher als Microsoft ein, wie schon der Titel seines Blogbeitrags verrät: "Contrary to Reports—Cookiejacking Presents a Major Risk". Seine Argumente sind äußerst treffend:

• Laut Trend Micros Erfahrungen besuchen die Leute bösartige Seite (was kein Wunder ist, da man das den Links dahin ja i.A. nicht ansieht),
• Social Engineering ist eindeutig erfolgreich, wie Fake-Virenscanner und Angriffe auf Facebook beweisen, und
• Cookies werden vom Benutzer nur selten gelöscht (warum auch? Wenn eine Website ihn nicht mehr braucht, kann sie ihn ja selbst löschen oder die Lebenszeit entsprechend kurz wählen).

Alles zusammen macht erfolgreiche Angriffe sehr wahrscheinlich. Und hat nicht schon Rosario Valotta bewiesen, wie gefährlich Cookiejacking ist? In drei Tage konnte er die Cookies von mehr als der Hälfte seiner Facebook-"Freunde" einsammeln. Wie viele Cookies wären es wohl auf einer populäreren Seite?

Microsoft patcht die Schwachstelle

Am Juni-Patchday wurde das Security Bulletin MS11-050 veröffentlicht, mit dem damit begonnen(!) wurde, die Schwachstelle zu beheben. Im ersten Schritt wurde unter dem CVE-Identifier CVE-2011-1258 ein Angriffsvektor im IE 6, 7 und 8 behoben. Der neue Angriffsvektor für den IE 9 mit dem CVE-Identifier CVE-2011-2383 blieb ebenso wie die ursprüngliche Schwachstelle im IE 6, 7 und 8 mit dem CVE-Identifier CVE-2011-2382 offen.

Erst mit dem am August-Patchday veröffentlichten Security Bulletin MS11-057 wurde die eigentliche Schwachstelle im IE 6 bis 9 unter dem CVE-Identifier CVE-2011-2383 behoben. Hoffen wir mal, dass das wirklich alles war und nicht irgendwann ein Patch für CVE-2011-2382 nachgeliefert werden muss. Immerhin ist CVE-2011-2383 ja nur entstanden, weil die Schwachstelle im IE 9 nicht korrekt behoben wurde.

Die Gefahr von Cookiejacking ist also nach ca. 8 Monaten durch die Korrektur der Schwachstelle gebannt. Clickjacking bleibt aber nach wie vor eine Gefahr, vor der Sie ihre Webanwendung schützen müssen. In der nächsten Folge gibt es einen Überblick über die Likejacking-Angriffe der letzten 12 Monate.

Carsten Eilers

Update 13.5.2015
Aus Anlass des 5jährigen Blog-Jubiläums habe ich alle Clickjacking-Artikel zusammengefasst, überarbeitet, ergänzt und auf den aktuellen Stand gebracht. Das Ergebnis ist ein (natürlich kostenloses) eBook im ePub- und PDF-Format: 5 Jahre Blog - Als Special: "Clickjacking"-eBook
Ende des Updates vom 13.5.2015

Übersicht über alle Artikel zum Thema

Clickjacking - Angriffe auf Seiten ohne Schwachstellen

Clickjacking - Auch komplizierte Aktionen sind möglich

Clickjacking - Framebuster oder HTTP-Header verhindern Angriffe

Der Angriff der Clickjacking-Würmer, "Likejacking" und "Buttonjacking"

Clickjacking - "Likejacking" unter die Haube geguckt

Clickjacking - The next Generation

Clickjacking - Drag&Drop-Angriffe und weitere Neuigkeiten

Cookiejacking - Keksdiebe im Internet Explorer

Likejacking - Facebook im Visier der Cyberkriminellen

Clickjacking - Gute und Schlechte Nachrichten

Standpunkt: Clickjacking gegen Flash, urchin.js und Duqu - nichts als Wiederholungen!

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Clickjacking-Angriffe verhindern - der aktuelle Stand der Dinge

Clickjacking: Cross Origin Resource Jacking und ein Clickjacking-BeEF-PlugIn

Clickjacking: "Zaubertricks" ermöglichen Likejacking und mehr

Dieses und Jenes zum Clickjacking

5 Jahre Blog - Als Special: "Clickjacking"-eBook