Cross-Zone-Scripting
Cross-Zone-Scripting ist ein Webbrowser-Exploit, der die Zonenaufteilung des Browsers ausnutzt. Der Angriff erlaubt es Webseiten, beliebigen Code innerhalb einer privilegierten Zone auszuführen.
Hintergrund
Bei einem Cross-Zone-Scripting Angriff handelt sich um einen Berechtigungsangriff, der gezielt auf das zonenbasierte Sicherheitsmodell von Webbrowsern abzielt. In einem zonenbasierten Modell gehören Seiten zu einer Gruppe von Zonen, die der Berechtigungsstufe entsprechen, die dieser Seite zugewiesen wurde. Seiten in einer nicht vertrauenswürdigen Zone hätten einen geringeren Zugriff auf das System und/oder wären in den Arten von ausführbaren Inhalten, die sie aufrufen durften, eingeschränkt.[1]
Bei einem zonenübergreifenden Scripting-Angriff erhält eine Seite, die einer weniger privilegierten Zone zugeordnet wurde, die Berechtigungen einer vertrauenswürdigeren Zone. Dies kann durch die Ausnutzung von Fehlern im Browser, die Ausnutzung falscher Konfigurationen in den Zonensteuerungen oder durch einen Cross-Site-Scripting-Angriff erreicht werden, bei dem der Inhalt der Angreifer so behandelt wird, als käme er von einer vertrauenswürdigeren Seite.
Dieser Angriff unterscheidet sich von “Restful Privilege Escalation” dadurch, dass letzteres mit der unzureichenden Sicherung von RESTful-Zugriffsmethoden (z. B. HTTP DELETE) auf dem Server korreliert, während Cross-Zonen-Skripting das Konzept der Sicherheitszonen angreift, wie es von einem Browser implementiert wird.
Auswirkung
Durch eine Cross-Zone-Scripting-Lücke ist ein Angreifer in der Lage, ein Opfer dazu zu bringen, Inhalte in seinem Webbrowser auszuführen, die die Sicherheitszonensteuerungen de Browsers umgeht, um Zugriff auf höhere Berechtigungszonen zu erlangen. Das würde den Angreifer dazu befähigen, Scripte, Applets oder andere Webobjekte auszuführen.[1]
Ursprung
Das Konzept von Sicherheitszonen wurde erstmals im Internet Explorer 4 eingeführt. Ein Cross-Zone-Scripting ist jedoch ein allgemeines Problem, das nicht Internet Explorer-spezifisch ist, da einige andere Browser auch implizit die Zone besitzen.[2]
Für den Internet Explorer sind folgende Zonen bekannt
Internet
Dabei handelt es sich um die Standardzone, hierzu gehört alles, was nicht zu anderen Zonen gehört.
Local intranet
Standardmäßig enthält die lokale Intranetzone alle Netzwerkverbindungen, die über einen UNC-Pfad hergestellt wurden, und Websites, die den Proxy-Server umgehen oder Namen ohne Punkt (z. B. http://local) haben, sofern sie weder der Zone Restricted Sites noch der Zone Trusted Sites zugeordnet sind.[2]
Trusted sites
Diese Zone wird normalerweise verwendet, um vertrauenswürdige Websites aufzulisten, die mit minimalen Sicherheitsberechtigungen ausgeführt werden dürfen (z. B. unsichere und unsignierte ActiveX-Objekte ausführen)[2]
Restricted sites
Diese Zone enthält Websites, denen nicht vertraut wird. Wenn eine Website zu dieser Zone hinzufügt wurde, bedeutet das, dass Dateien, die ein Besucher von der Website herunterlädt oder ausführt, vermutlich seinen Computer oder seine Daten beschädigen können. Standardmäßig gibt es keine Websites, die dieser Zone zugeordnet sind; die Sicherheitsstufe ist auf Hoch eingestellt.[2]
Die Zone Eingeschränkte Sites enthält Websites, die sich nicht auf Ihrem Computer oder in Ihrem lokalen Intranet befinden oder die nicht bereits einer anderen Zone zugeordnet sind. Die Standardsicherheitsstufe ist Mittel.[2]
Beispiele
Lokale Zone
Diese Art von Exploit versucht, Code im Sicherheitskontext der lokalen Computerzone auszuführen.
Das folgende HTML wird verwendet, um einen naiven, jedoch nicht funktionierenden, Versuch der Ausbeutung zu veranschaulichen:
<!DOCTYPE html>
<html>
<img src="codigomalicioso.gif">
<script src="file://C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\codigomalicioso.gif">
</html>
In diesem Beispiel versucht der HTML-Code die Datei codigomalicioso.gif mit Hilfe einer IMG SRC-Referenz in den Cache zu laden. Dann wird mit einem SCRIPT SRC-Tag versucht, das Skript von der lokalen Computerzone aus auszuführen, indem die lokale Datei im Cache angesprochen wird.[3]
Trusted zone
Das bekannteste Beispiel ist der Internet Explorer-Bug %2f, der heutzutage allerdings als veraltet gilt: Die folgende Schwachstelle ermöglicht es, die Webseite des Angreifers im Domänenkontext des virtuellen Shops anzuzeigen. Um dies korrekt zu tun, muss das Web des Angreifers so konfiguriert sein, dass er ungültige Werte im HTTP-Header „Host“ akzeptiert.[3]
http://tiendavirtual.com%2F%20%20%20.http://blackbox.psy.net/
Sicherheitslücken
In der Vergangenheit wurden immer wieder Cross-Zone-Scripting Lücken bekannt.
Im Februar 2008 wurde bekannt, dass es eine Cross-Zone-Scripting Lücke in der VoIP Anwendung Skype gab. Diese Sicherheitslücke befähigte einen Angreifer, einem Opfer beim Einbinden von Videos der Plattformen Metacafe und Dailymotion Schadcode unterzuschieben.[4] Skype verwendet Internet-Explorer-Webkontrollen, um interne und externe HTML-Seiten darzustellen. Die „Video zum Chat hinzufügen“ verwendet diese Web-Steuerelemente und sie laufen in der lokalen Zone. Benutzer, die in Skype nach dem Video mit den gleichen Schlüsselwörtern wie im Titelfeld gesucht hatten, hatten den Code der Angreifer in seinem Browser mit lokalen Zonenrechten ausführen lassen.[1][5]
Wie im Oktober 2012 bekannt wurde, fanden Sicherheitsforscher von IBM eine Lücke in einem eingebetteten Browserfenster, dass auf mobilen Geräten zum Einsatz kommt. Dieses eingebettete Browserfenster fand unter anderem in der Dropbox app und der Google Drive app für iOS und Android Anwendung.[6]
Einzelnachweise
- ↑ a b c CAPEC-104: Cross Zone Scripting. Abgerufen am 21. Mai 2019 (englisch).
- ↑ a b c d e How to use security zones in Internet Explorer (Memento vom 4. Juni 2011 im Internet Archive)
- ↑ a b XSS_Hacking_tutorial. (PDF) S. 52, abgerufen am 21. Mai 2019 (englisch).
- ↑ Sicherheitsupdate für Skype. 7. Februar 2008, abgerufen am 21. Mai 2019.
- ↑ Skype plugs critical cross-zone scripting hole. 5. Februar 2008, abgerufen am 21. Mai 2019 (englisch).
- ↑ Cross-zone scripting vulnerabilities found in Dropbox and Drive. 22. Oktober 2012, abgerufen am 21. Mai 2019 (englisch).
