Internet Explorer Cross-Site Scripting-Lücke offengelegt

Originalartikel von Trend Micro

Der Sicherheitsforscher David Leo hat eine neue Sicherheitslücke in Microsoft Internet Explorer öffentlich gemacht, über die die Same-Origin-Policy verletzt werden kann. Diese Policy regelt, wie ein Dokument oder Skript, das von einer Website (Origin, Herkunft) geladen wird, mit einer Ressource einer anderen Herkunft interagieren kann. Wird die Same-Origin-Policy übergangen, so kann ein Angreifer Sitzungen kapern, Authentifizierungs-Cookies stehlen und Phishing-Angriffe starten.

Diese Lücke wird als universelle Cross-Site Scripting (UXSS)-Schwachstelle beschrieben, weil sie alle Websites Angriffen aussetzt. Ein UXSS-Angriff bedarf keiner Sicherheitslücke auf der anvisierten Website. Es reicht ein Nutzer, der eine bösartige URL besucht. Beispielsweise können sehr einfach Cookies von jeder besuchten Site gestohlen werden. In anderen Szenarien lässt sich die Ziel-Site „modifizieren“, als ob sie durch einen Angreifer kompromittiert wäre, und alle „Änderungen“ finden innerhalb des Browsers eines Nutzers statt.

Ein Angreifer könnte einen iFRAME nutzen, um eine legitime Site zu laden, für die das Opfer ein Konto besitzt. Aufgrund der Sicherheitslücke hat der Angreifer die Möglichkeit, Javascript im Kontext dieser Site laufen zu lassen – was die Same-Origin-Policy verbietet. Das Opfer läuft Gefahr, die Daten, die es auf der Site angegeben hat, oder auch Cookies an den Angreifer zu verlieren.

Der Forscher hat einen Proof of Concept veröffentlicht, der einen Angriff auf die Website der britischen Daily Mail zeigt. Die Exploit-Seite liefert einen Link auf die Daily Mail-Website, die in einem neuen Fenster geöffnet wird. Nach sieben Sekunden wird der Inhalt der Website durch die Seite ersetzt, auf der zu lesen ist “Hacked by Deusen”.

Websites können sich vor dieser Lücke schützen, indem sie im http-Header in X-Frame-options “same-origin”, “deny”, “allow-from” Werte angeben.

Der IE 11 ist bekanntermaßen angreifbar, und es war nicht gleich klar, ob auch ältere Versionen der Gefahr ausgesetzt sind. Windows 7, Windows 8.1 und Windows 10 Technical Preview sind alle betroffen. Auch gibt es derzeit noch keinen Patch oder ein Workaround.

Analyse der Sicherheitslücke

Die Trend Micro-Sicherheitsforscher analysierten den Fehler auf einem Windows 7 32-Bit-System mit einer nicht gepatchten Version des Internet Explorer 11 (Version 11.00.9600.17041 von mshtmll.dll). Nachfolgend einige Details zur Datenstruktur innerhalb von mshtmll.dll.



Bild 1. mshtml.dll-Datenstruktur

Jeder iFRAME hat eine Struktur CWindow.

  • absid: der Sicherheits-Identifier, der von der aktuellen Domäne repräsentiert wird

abSID ist kein Teil von CWindow. CWindow kann GetSIDOfDispatch aufrufen, um die abSID zu erhalten.

Wenn man einen Frame referenziert, so erzeugt die Rendering Engine ein Proxy-Fenster ComWindowProxy mit folgendem Inhalt:

  • pWindow: Zeiger auf das reale html Window
  • pbSID: der Sicherheits-Identifier, der von der Herkunft repräsentiert wird, die sich auf das reale Fenster bezieht.

Wenn ein Nutzer versucht, auf die ComWindowProxy-Ressource zuzugreifen, ruft diese die Funktion AccessAllowed auf. Diese Funktion vergleicht pbSid und pWindow->abSID. Sind sie gleich, erfolgt der Zugang in derselben Herkunft und wird erlaubt., wenn nicht, wird er verweigert.

Im vorliegenden Fall vergisst die Engine ganz einfach, den Zugang zu prüfen und erlaubt es, die Policy zu umgehen.

Der Proof of Concept besteht aus zwei Dateien: eine HTML-Datei namens poc.html und eine PHP-Datei namens 1.php. Die HTML-Datei enthält zwei IFRAMES:

<iframe style="display:none;" width=300 height=300 id=i name=i src="1.php"></iframe><br>

Beispiel 1. Frame0

<iframe width=300 height=100 frameBorder=0 src="http://www.dailymail.co.uk/robots.txt"></iframe><br>

Beispiel 2. Frame1

Sie enthält auch eine Javascript-Funktion:

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:%22%3Cscript%3Efunction%20a()%7Bw.document.body.
innerHTML%3D%27%3Ca%20style%3Dfont-size%3A50px%3EHacked%20by%20Deusen
%3C%2Fa%3E%27%3B%7D%20function%20o()%7Bw%3Dwindow.open(%27http%3A%2F%2Fwww.dailymail.co.uk
%27%2C%27_blank%27%2C%27top%3D0%2C%20left%3D0%2C%20width%3D800%2C%20height%3D600%2C%20
location%3Dyes%2C%20scrollbars%3Dyes%27)%3BsetTimeout(%27a()%27%2C7000)%3B%7D%3C%2Fscript
%3E%3Ca%20href%3D%27javascript%3Ao()%3Bvoid(0)%3B%27%3EGo%3C%2Fa%3E%22\\';'))",1);
}

Beispiel 3. Go-Funktion

Die PHP-Datei enthält den folgenden Code:

<?php
sleep(5);
Header(“Location: http://www.dailymail.co.uk/robots.txt”);
?>

Beispiel 4. PHP-Code

Die Sicherheitslücke wird auf folgende Weise angestoßen:

  1. In der go-Funktion ist die Frame0-Domäne http://serverip, und das ist die bösartige URL der Site. Wegen des php Calls sleep(5) ist die Antwort des Servers pending.

 

Die Frame1-Domäne ist http://www.dailymail.co.uk oder jede andere Ziel-Site. Die Haupt-Frame Domain ist http://serverip.

Der Befehl w=window.frames[0] erzeugt einen ComWindowProxy w:

Da pbSID gleich ist mit abSID, wird der w.setTimeout-Zugang durch SOP erlaubt.

  1. Der w.setTimeout-timeout agiert.

2.1. Der Befehl .x=top.frames[1] erzeugt eine COWindowproxy-Variante x. Deren pbSID ist serverIP.

2.2. Die Schleife der Bestätigungsnachricht erzeugt eine Redirect-Nachricht und die frame0 abSID ändert sich auf Frame1.

2.3. Die JavaScript Engine führt x.location durch. An diesem Punkt besteht das korrekte Vorgehen darin, x.AccessAllowed aufzurufen, denn pbSID (die Angriffsserver-IP) und abSId (www.dailymail.co.uk) sind unterschiedlich und deshalb wird der Zugang fehlschlagen. Doch wurde nie ein solcher Check durchgeführt. Der Angreifer kann folgich als „normal“ laufen.

Die Ursache für diese Sicherheitslücke ist einfach ein vergessener Call, der dazu führt, dass eine SOP umgangen wird. Interessanterweise scheint der Internet Explorer 8 dies richtig zu handhaben, während spätere Versionen (9 bis 11) dies nicht tun.

Trend Micro Deep Security schützt die Anwender über folgende Regel, die Anfang der Woche veröffentlicht wurde:

  • 1006472 – Microsoft Internet Explorer Same Origin Policy Bypass Vulnerability

 

Analyse von Henry Li und Rajat Kapoor

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.