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.
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