Skip to content

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Ab dieser Folge werde ich mich dem Thema "Angriffen auf Webanwendungen über ihren Client" widmen. Der Anlass sind die Vorbereitungen für meinen Vortrag "HTML5, the secure Way" auf der WebTech Conference 2012.

Es gibt außer Angriffen auf bzw. über HTML5 noch viele weitere Möglichkeiten, einer Webanwendung über ihren Client Schaden zuzufügen. Einige davon werde ich in dieser und den nächsten Folgen vorstellen. Los geht es mit einigen von Rich Lundeen, Jesse Ou und Travis Rhodes von Microsoft auf der Konferenz Black Hat Abu Dhabi 2011 unter dem Titel "New Ways I'm Going to Hack Your Web App". vorgestellten Angriffen.

Neue Clickjacking-Angriffe auf Facebook - Da erscheint Likejacking harmlos

Rich Lundeen, Jesse Ou und Travis Rhodes begannen bei der Vorstellung neuer Angriffe mit Clickjacking bzw. den Gegenmaßnahmen gegen diese Angriffe: Der X-Frame-Options-Header und JavaScript-Framebuster. Dass Framebuster nicht zwingend funktionieren ist seit längerem bekannt. Auch Rich Lundeen, Jesse Ou und Travis Rhodes führten einige Beispiele auf, wie bzw. wo ein Framebuster unwirksam wird.

Anfreunden, Daten kopieren, Laufpass geben

Danach ging es um die Frage, was sich denn mit Clickjacking erreichen lässt. Ihre erste Antwort: Auf Facebook können Informationen ausgespäht werden. Dazu wird das Opfer über Clickjacking dazu gebracht, sich mit dem Angreifer zu befreunden. Nachdem der Angreifer die Daten kopiert hat, löst er die Freundschaft auf, so dass das Opfer nichts vom Angriff bemerkt.

Eine SMS, und der Account ist futsch

Es ist auch möglich, den Account eines Facebook-Benutzers zu übernehmen. Dazu wird über Clickjacking die Handy-Nummer des Angreifers zum Konto des Opfers hinzugefügt. Danach setzt der Angreifer das Passwort des Opfers zurück und lässt sich das neue temporäre Passwort per SMS an die zuvor hinzugefügte Nummer senden.

Die ausgenutzten Schwachstellen wurden von Facebook behoben, wobei es Unterstützung von Rich Lundeen, Jesse Ou und Travis Rhodes gab. Einige angreifbare Seiten wurden aus dem Netz genommen, für sensitive Seiten soll der X-FRAME-OPTIONS-Header verwendet werden, und für das Hinzufügen einer neuen Handy-Nummer ist nun die Eingabe des Passworts nötig.

Cookies: Der erste gewinnt!

Als nächstes ging es um Cookies. Die Same Origin Policy erlaubt es, für Schwester-Domains "spezifischere" Cookies zu setzen. So kann beispielsweise JavaScript-Code auf test.microsoftonline.com folgende Cookies mit den angegebenen Folgen setzen:

1.    document.cookie='cookname=erster; domain=test.microsoftonline.com; path=/';
An test.microsoftonline.com gesendet:      Cookie: cookname=erster
2.    document.cookie='cookname=zweiter; domain=.microsoftonline.com; path=/';
An test.microsoftonline.com gesendet:      Cookie: cookname=erster; cookname=zweiter
3.    document.cookie='cookname=boese; domain=.microsoftonline.com; path=/site'
An test.microsoftonline.com gesendet:      Cookie: cookname=erster; cookname=zweiter

Damit werden folgende Cookies an die folgenden Domains gesendet:

Domain Cookie
microsoftonline.com/site      Cookie: cookname=boese; cookname=zweiter
test.microsoftonline.com/site      Cookie: cookname=boese; cookname=erster; cookname=zweiter
https://ganz.sicher.microsoftonline.com/site      Cookie: cookname=boese; cookname=zweiter

Der Browser verwendet den ersten Cookie, mit anderen Worten: In allen Fällen wird der "böse" Wert verwendet.

CSRF-Schutz via Cookie ausgehebelt

Ein Angreifer, der eine XSS-Schwachstelle auf irgend einer Subdomain findet, kann darüber Cookies für beliebige andere Subdomains setzen. Darüber lässt sich zum Beispiel ein CSRF-Schutz aushebeln, der mit doppelt übertragenen Cookies nach dem Muster

if (Request.QueryString["CsrfToken"] == Request.Cookies["CsrfTokenCookie"].Value) {
   // Aktion ausführen
}

arbeitet. Das beweist nur, dass der Request von jemanden stammt, der Cookies schreiben kann, und das kann auch ein Angreifer sein. Zum Beispiel ein Man-in-the-Middle, der eine HTTPS-Verbindung aufgebrochen hat, oder ein Angreifer, der eine XSS-Schwachstelle in einer Schwester-Domain ausnutzt.

Gefunden wurde so ein CSRF-Schutz während der Entwicklung des Office365-Portals (daher auch die Domain microsoftonline.com in den Beispielen). Die Schwachstelle wurde behoben, nun wird ein Header mit dem Hashwert eines Session-spezifischen Werts als CSRF-Schutz verwendet.

Auch Outlook Web Access (OWA) war betroffen, hier konnte die Schwachstelle beispielsweise durch E-Mails ausgenutzt werden. Als Schutz wird der gleiche Header wie im Fall von Office365 verwendet.

Ein Cookie - oder ein XSS-Angriff?

Über einen so manipulierten Cookie sind auch XSS-Angriffe möglich, wie am Beispiel von www.msn.com demonstriert wurde. Dabei wurde eine weitere Eigenschaft der Cookies ausgenutzt: Im Browser sind Cookies Case-Sensitive, "CookieName" und "Cookiename" sind also für den Browser verschiedene Cookies.

Auf dem Server dagegen werden Cookies oft Case-Insensitive verwendet, beispielsweise von ASP.NET. Der Aufruf Request.Cookies["ABCdef"] liefert also den ersten Cookie mit dem Namen "abcdef", ohne auf die Gross- oder Kleinschreibung Rücksicht zu nehmen.

Wie man solche Angriffe verhindert, dürfte klar sein: So wie jeden XSS-Angriff durch das Prüfen und Kodieren der Eingaben.

Es sind viele weitere Angriffe über manipulierte Cookies möglich, was zu dem Schluss führt, dass bei Test und Entwicklung einer Webanwendung Cookies genauso wie Query-Strings behandelt werden müssen. Außerdem schlagen Rich Lundeen, Jesse Ou und Travis Rhodes vor, Cookies mit einer digitalen Signatur zu sichern und darüber an den eingeloggten Benutzer und die laufende Session zu binden, wenn ihre Integrität von Bedeutung ist (und das ist sie ja oft). Alternativ kann statt Cookies der Local Storage verwendet werden, bei dem es keine Probleme mit Subdomains gibt.

In der nächsten Folge gibt es das Material zu meinem Vortrag "HTML5, the secure Way" auf der WebTech Conference 2012, danach geht es mit neuen Angriffen auf Webanwendungen weiter.

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 Websecurity

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies
Websecurity - XSS-Angriffe über XML
Websecurity - Angriffe über Logikfehler
Websecurity - Angriffe über Logikfehler, Teil 2
Websecurity - Logikfehler in der Authentifizierung
Websecurity - Logikfehler in der Authentifizierung und auf der Flucht
Websecurity - Logikfehler finden
Websecurity - Logikfehler vermeiden

Übersicht über alle Artikel zum Thema Clickjacking

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

Trackbacks

Keine Trackbacks