This page has been robot translated, sorry for typos if any. Original content here.

Übergreifendes Domain-Scripting

Einleitung.

Die Idee, diesen Artikel zu schreiben, kam zu mir, nachdem es notwendig war, einem Neuling einen Hinweis auf eine detaillierte und verständliche Erklärung dieses Begriffs zu geben. Nachdem ich die Suchmaschinen bestiegen hatte, war ich überrascht festzustellen, dass es nicht einfach ist, einen solchen Artikel zu finden. Der Begriff wurde entweder nicht in zwei Worten oder auf Englisch erklärt :) . Unterdessen sind Windows-Schwachstellen dieses Typs sehr häufig und sie sind mehr als ernst! Daher habe ich in diesem Artikel versucht, diese Art von Angriffen zu beschreiben, die Besonderheiten der Ausnutzung dieser Art von Schwachstellen und des Schutzes vor solchen Angriffen sowie konkrete Beispiele, die so detailliert und klar wie möglich sind. Der Artikel wurde hauptsächlich für Anfänger geschrieben, aber ich hoffe, dass er für erfahrene Leser nützlich sein wird.

Was ist Cross-Domain-Scripting?

Anfänglich war das Cross-Domain Scripting (CDS) mit Fehlern im Sicherheitsmodell aller bekannten "Esel" aka Internet Explorer (IE) verbunden. Jedoch seit Architekturmerkmale moderner Browser unterscheiden sich nicht stark voneinander, dann sind Angriffe dieser Art derzeit fast allen bekannten Webbrowsern unterworfen. Dennoch führen die bestehenden Unterschiede zwischen den Programmen dieser Klasse dazu, dass das am häufigsten gefundene CDS "browserunabhängig" ist, dh es funktioniert zB auf dem IE, funktioniert aber nicht auf Opera oder umgekehrt.
Die Grundlage für Schwachstellen wie CDS ist das Konzept der "Domäne". In diesem Zusammenhang unterscheidet sich die Bedeutung dieses Konzepts etwas von der allgemein akzeptierten. "Domain" ist nicht nur die Website-Adresse im Internet und nicht einmal der "Bereich des hierarchischen Internet-Namespace" - dieses Konzept bezeichnet eine bestimmte "Sicherheitsgrenze", über die kein Benutzerscript hinausgehen darf.
Die Grundlage des Sicherheitsmodells jedes Webbrowsers ist das Prinzip, dass die Ressourcen verschiedener Domänen (Seiten, Skripts usw.) sich in keiner Weise miteinander schneiden können, d.h. um auf die inneren Inhalte und Daten der anderen zuzugreifen. Wenn dies möglich wäre, könnte beispielsweise ein Skript auf der Homepage des jungen Vasya-Hackers auf die Mail.Ru-Postfachdaten von einem ahnungslosen Benutzer zugreifen, den Vasya auf seine Seite gelockt hat. Das würde Spaß machen. :) !! Darüber hinaus sind jede Netzwerkressource im lokalen Netzwerk und das eigene Dateisystem des Clients je nach Architektur von Windows und den Konzepten zum Aufbau moderner Browser auch "Domänen", was bedeutet, dass man von Skripten aus genau wie auf jede Ressource im Internet zugreifen kann! Tatsächlich ist es das lokale Dateisystem des Clients, das häufig das Ziel von domänenübergreifenden Angriffen ist.
Gleichzeitig ist die Interaktion zwischen Ressourcen (Seiten und Skripten) in der Domäne (und allen ihren Subdomains!) Durch das Microsoft-Sicherheitskonzept erlaubt und prinzipiell unbegrenzt. Es ist schwer zu beurteilen, ob es richtig ist oder nicht, aber was ist so einfach :) und gleichzeitig erweitern sich die Möglichkeiten des Websurfens, das ist sicher.
Was ist also domänenübergreifendes Scripting? Im Zusammenhang mit dem Vorstehenden kann dieser Ausdruck als "Cross-Domain-Scripting" übersetzt werden; "Scripted domain bounds crossing" ist eine Verletzung dieser geschätzten Sicherheitslinie, deren Zugriff auf Daten von anderen Domänen, einschließlich des lokalen Dateisystems des Clients, zugreifen kann. Diese Verletzung wird meistens von der Fähigkeit begleitet, beliebigen HTML- und Java-Code im Kontext anderer Domänen zu schreiben und auszuführen, Daten von anderen Domänen zu lesen (zum Beispiel Passwortformulare oder Dateien auf dem Client-System) und sogar beliebige Befehle auf dem entfernten Computer auszuführen.
Häufig wird das Konzept des domainübergreifenden Skripting durch das Konzept des Cross Site Scripting (XSS) ersetzt. Tatsächlich kommt es häufig vor, dass die äußeren Erscheinungsformen dieser Sicherheitslücken sehr ähnlich sind, insbesondere wenn CDS Java-Code in den Kontext einer anderen Domäne einfügt. Trotz dieser Ähnlichkeit ist das Wesen dieser Sicherheitslücken jedoch unterschiedlich:
Erstens ist der Umfang von XSS per definitionem auf eine Domäne beschränkt. Während CDS im Allgemeinen von allen Domänen + das lokale Dateisystem des Clients betroffen ist.
Zweitens liegt die Ursache von XSS-Schwachstellen in den Fehlern von Skripten auf dem Server und besteht in der Regel in einer unzureichenden Filterung der vom Benutzer empfangenen Daten. Die Quelle der CDS-Schwachstellen ist die Client-Software (Browser und Betriebssystem), die in der Regel nicht mit Benutzerdaten verknüpft ist.
Nun, wir sollten nicht vergessen, dass die Gefahr der erfolgreichen Ausnutzung eines Angreifers durch XSS viel geringer ist als von CDS. Immerhin wird es im ersten Fall höchstens zu einem Verlust vertraulicher Benutzerdaten (Passwörter usw.) und nur von einem Standort kommen, und mit CDS ist es möglich, vertrauliche Daten von beliebigen Sites zu stehlen und häufig willkürliche Befehle auf dem Client-System auszuführen erlaubt es Ihnen, die volle Kontrolle zu übernehmen.

Wie funktioniert es?

Warum ist diese Art von Angriff möglich? Der Grund ist, dass dieselbe "Sicherheitslinie" zwischen Domänen künstlich erzeugt wird, dass alle Arbeiten zur Verhinderung von domainübergreifendem Scripting vom Webbrowser und seinen Komponenten ausgeführt werden - es gibt keine architektonischen Einschränkungen. Es besteht also immer die Möglichkeit von Fehlern in den Verifikationsverfahren, die Möglichkeit, diese zu umgehen, was jetzt erfolgreich durchgeführt wird.
Seit mehr als einem Jahrzehnt der Verwendung von Webbrowsern wurden viele Wege gefunden, um die geschätzte Domänengrenze der Domäne zu überwinden. Die meisten von ihnen können jedoch in zwei Klassen unterteilt werden:
1. Verwendung von Sicherheitsfehlern im objektorientierten Browsermodell;
2. Verwenden Sie eine Zwischenverbindung, um einen Angriff auszuführen.
Betrachten wir diese Angriffsklassen genauer.
Im Mittelpunkt des ersten Ansatzes steht eine klar formulierte objektorientierte Architektur moderner Browser und der Java Virtual Machine. In der Tat sind alles, was wir auf dem Bildschirm eines Webbrowsers sehen, Objekte bestimmter Klassen mit ihren Eigenschaften, Ereignissen und Methoden. Mit diesem objektorientierten Modell und Java-Skripten können wir auf jedes Element der Seite zugreifen, das in den Browser geladen wurde, Daten darin lesen und schreiben, neue Fenster öffnen usw. Darüber hinaus ist es mithilfe von Skripts möglich, die Elemente des Webbrowsers selbst und sogar Benutzeraktionen teilweise zu steuern: Vorwärts / Zurück zu Seiten, Hinzufügen zu Favoriten usw.
Einzelne Fenster oder Seitenelemente in einem Webbrowser können jedoch zu verschiedenen Domänen gehören, was bedeutet, dass der Zugriff darauf verhindert werden muss. Sie können nicht zulassen, dass ein benutzerdefiniertes Skript eine andere Domäne in einem neuen Browserfenster öffnet, Sie können dort etwas schreiben oder von dort aus aufnehmen. Sie können ein Skript nicht auf einer Seite mit einem Frame zulassen, auf dem die Ressource aus einer anderen Domäne geladen ist, können auf diesen Frame zugreifen und auf seine Daten zugreifen. Darüber hinaus ist ein Datenverlust von einer Domäne zu einer anderen nicht nur durch Eigenschaften, sondern auch durch Methoden und Ereignisse von Objekten möglich! Ein Skript auf der Seite des jungen Vasi-Hackers, wo er einen ahnungslosen Benutzer anlockt, sollte nicht "wissen", welche Taste er drückt, wenn er das Passwort für die Anmeldung bei Mail.Ru eingibt, geöffnet in einem anderen Browserfenster. Nun, es gibt viele solche Beispiele!
Leider, und vielleicht zum Glück;), werden solche Sicherheitskontrollen oft falsch durchgeführt, und manchmal sogar komplett abwesend! Daher wird es möglich, auf Elemente von Seiten anderer Domains zuzugreifen, Daten von ihnen zu lesen, ihren Java-Code in den Kontext anderer Domains zu schreiben usw. Aufgrund der relativ komplexen Architektur des objektorientierten Modells sind solche "Löcher" oft darin zu finden. Im Folgenden finden Sie ein Beispiel für diese Angriffsklasse (Beispiel 1).
Um Angriffe der zweiten Klasse auszuführen, verwenden Sie eine Zwischenstufe. Was muss ich tun, wenn der direkte Zugriff auf eine andere Domain verboten ist? Das ist richtig! Herumlaufen! Und plötzlich ist jemand da, dem diese Berufung nicht verboten ist, und er kann Daten von dort mitnehmen und an uns übertragen, oder umgekehrt - um unsere Daten in den Kontext einer anderen Domäne zu schreiben. Am anfälligsten ist in diesem Zusammenhang die Microsoft ActiveX-Technologie. Die ActiveX-Technologie stellt dem Benutzer Objekte, deren Eigenschaften und Methoden zur Verfügung, die vom Betriebssystem für zusätzliche Zwecke verwendet werden. Um beispielsweise die Windows-Hilfedateien (* .chm) über den Webbrowser anzuzeigen, verwenden Sie die ActiveX-Komponente der HTML-Hilfe. Ist es nicht bequem? Oft wirken ActiveX-Objekte jedoch als eine Art "Trojaner"! Tatsache ist, dass es eine Möglichkeit gibt, diese Komponenten (Download, Zugriff auf ihre Eigenschaften und Methoden) über eine Webseite zu verwalten. Verwenden Sie dazu das Tag. Aber oft enthalten diese ActiveX-Objekte Methoden zum Manipulieren des Dateisystems, Starten von Anwendungen, Navigieren durch Webseiten usw. Also. es besteht die Möglichkeit, all diese Handlungen von außen zu machen und darüber hinaus einen vollständigen Datenaustausch mit dem Opfer durchzuführen! Lesen Sie beispielsweise den Inhalt lokaler Clientdateien und senden Sie diese Daten an das Skript zurück, oder verwenden Sie ActiveX, um eine andere Domäne zu öffnen und den Java-Code in den Kontext zu schreiben. Mit dieser Klasse von Angriffen ist es manchmal möglich, eine willkürliche Code-Ausführung auf dem Client-System zu erreichen (indem man cmd.exe mit den erforderlichen Parametern ausführt). Derzeit ist diese Art von CDS ebenfalls weit verbreitet und findet ständig neue anfällige ActiveX-Objekte. Das folgende Beispiel zeigt eine solche Sicherheitsanfälligkeit (Beispiel 2).
Zusätzlich zu den betrachteten CDS-Klassen gibt es noch andere Möglichkeiten, Interdomain-Beschränkungen zu umgehen. Es stimmt, oft sind diese Methoden sehr exotisch und selten. Zum Beispiel die Cross-Cookie-Schwachstelle, die im Juli 2004 entdeckt wurde (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Es erlaubt unter bestimmten Bedingungen, auf die Cookies anderer Domains zuzugreifen (lesen / schreiben). Und dies war einer der wenigen Fälle, in denen viele Browser angreifbar waren: IE, Mozilla, Opera, Konqueror.
Also. CDS ist derzeit eine sehr häufige Art von Angriffen, und es werden ständig neue Möglichkeiten entdeckt, diese Schwachstellen auszunutzen (der "Angriffsvektor").

Beispiele für CDS

Um alles, was oben beschrieben wurde, klarer zu machen, betrachten Sie einige Beispiele für echte CDS-Schwachstellen. Sie wurden alle im Internet Explorer gefunden und ermöglichen es Ihnen, Ihren Java-Code in den Kontext anderer Domänen einzufügen. Normalerweise wird dies zum Stehlen von Cookies oder zum Ausführen beliebiger Aktionen innerhalb der aktuellen Benutzersitzung verwendet.

Beispiel 1. Ähnliche Sicherheitsanfälligkeit durch Umleitung der domänenübergreifenden Domänennamen - CAN-2004-0727 (MS04-038)

Diese Sicherheitslücke wurde im Juli 2004 entdeckt und ist mit einem Sicherheitsfehler im objektorientierten IE-Modell verbunden (die erste Klasse von CDS-Schwachstellen, die sich von den oben beschriebenen unterscheidet).
Sein Wesen ist wie folgt. Wie Sie wissen, können Sie zum Laden einer anderen Seite in das aktuelle Browserfenster (möglicherweise aus einer anderen Domäne) die location.href-Eigenschaft oder die location.assign () -Methode verwenden. Nach dem Laden der gewünschten Seite ist jedoch eine weitere Ausführung des Java-Codes des aktuellen Skripts nicht möglich - andernfalls könnte das Skript Mail.Ru laden und beliebige Aktionen im Kontext dieser Domäne ausführen. Es war jedoch möglich, diese Einschränkung zu umgehen, indem wir die location.assign () -Methode auf genau dasselbe, aber unterschiedliche Fenster umlenken (schließlich haben wir ein objektorientiertes Modell, und wir können die Methoden verschiedener Objekte einander zuordnen). Als Ergebnis wurde es möglich, Java-Code im Kontext des aktuellen Fensters auszuführen, aber nach dem Herunterladen der erforderlichen Seite - wie erforderlich! Das folgende Skript führt die erforderlichen Aktionen aus:


w = window.open ("javascript: setInterval (Funktion () {versuchen Sie {x = opener.location.href;} catch (e) {location.assign ('javascript: alert (document.cookie)'); window.close ();}}, 100) ");
w.location.assign = location.assign;
location.href = "/ klicke? http: // localhost";


Zuerst öffnet sich ein neues Fenster, welches in der Schleife darauf wartet, dass die Seite (in unserem Fall mit localhost) in das Hauptfenster (aktuell) geladen wird. In der Zwischenzeit weist das Skript die location.assign () -Methoden neu zu und beginnt mit dem Laden des Hauptfensters der angeforderten Seite (localhost). Sobald der Download beendet ist, löst der Trigger einen Trigger in der Schleife des neuen Fensters aus, weist der Methode assign () Java-Code zu (aufgrund der Neuzuordnung der Methoden erfolgt das Einfügen im Kontext des Hauptfensters) und das neue Fenster schließt sofort. Als Ergebnis der Ausführung des Skripts im Kontext von localhost wird document.cookie ausgeführt.
Anscheinend haben Microsoft-Entwickler die Redirect-Funktion nicht bereitgestellt und in diesem Fall keine Sicherheitsprüfung eingefügt (oder falsch eingefügt). Um diese Sicherheitsanfälligkeit auszunutzen, müssen Sie Active Browsing in Ihrem Browser aktiviert haben. Lesen Sie mehr über diese Sicherheitslücke und finden Sie ein funktionierendes Beispiel für einen Exploit: http://greyhatsecurity.org/similymethodennamedir-discussion.htm.

Beispiel 2. Sicherheitsanfälligkeit bei domänenübergreifender ActiveX-Domänenüberprüfung für DHTML-Editing CAN-2004-1319 (MS05-013)

Diese Sicherheitslücke wurde Ende letzten Jahres entdeckt, aber erst im Februar behoben. Es bezieht sich auf die zweite Art von CDS-Angriffen von den oben betrachteten, d.h. verwendet ein Zwischenprodukt (DHTML ActiveX), um den Angriff auszuführen. Um die Sicherheitsanfälligkeit erfolgreich auszunutzen, müssen Sie die folgende Abfolge von Aktionen durchführen:
1. Laden Sie DHTML ActiveX herunter. Dies geschieht mit Hilfe eines Tags.




2. Laden Sie die gewünschte Seite in das ActiveX-Objekt (beliebige Domäne) herunter. Dies geschieht, indem Sie unser Skript im Kontext von DHTML ActiveX ausführen.

exploit.DOM.Scrypt.execScript ("window.name =" new "; open (" http: // localhost "," new ");");

3. Nun, und danach können Sie unseren HTML- und Java-Code bereits einbetten. Es wird im Kontext der geladenen Domäne ausgeführt. Alles ist einfach zu entehren :) !!

exploit.DOM.Scrypt.execScript ("alert (document.cookie)");

Was sind die Ursachen für diese Sicherheitsanfälligkeit? Ich würde zwei von ihnen herausgreifen:
Erstens die Möglichkeit, beliebige Skripte innerhalb des ActiveX-Objekts extern auszuführen - meiner Meinung nach ist das zu viel Freiheit!
Zweitens wird beim Laden einer Seite in DHTML ActiveX alles dort geladen - sogar Cookies! Frage: Warum? Dieses ActiveX-Objekt kann zum Bearbeiten von Seiten verwendet werden und warum Cookies benötigt werden - es ist unklar ...
Um diese Sicherheitsanfälligkeit auszunutzen, ist es natürlich erforderlich, dass der Browser ActiveX ausführt. Lesen Sie mehr über diese Schwachstelle und finden Sie ein funktionierendes Beispiel für einen Exploit: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Wie verteidigst du dich?

Der Schutz vor Cross-Domain-Scripting ist nicht so einfach. Weil Die Varianten der Ausbeutung (der "Angriffsvektor") dieser Schwachstellen sind sehr unterschiedlich, die meisten Maßnahmen werden sehr begrenzt und temporär sein. Es ist fast unmöglich, alle "Angriffsvektoren" zu blockieren. Daher werde ich einige Empfehlungen geben, die nur das Risiko eines erfolgreichen Angriffs reduzieren, aber nicht vollständig schützen können.
1. Vorsicht beim Surfen im Internet.
Um fast alle Arten von CDS erfolgreich ausführen zu können, müssen Sie zunächst einen ahnungslosen Benutzer auf eine Exploit-Seite locken, worauf er sich diesem Angriff unterzieht. Sie können nicht vertrauen, Links, wie zufällig, in die Konversation geworfen, verschiedene "Homepages", etc. Dies ist wahrscheinlich die wichtigste Empfehlung von allen. Leider kann korrekt angewendet XSS alle Vorsicht streichen.
2. Installieren Sie Patches für das Betriebssystem und den Browser.
In der Regel wird für alle im Internet veröffentlichten Schwachstellen der Hersteller (auch Microsoft :) ) erzeugt in kurzer Zeit ein Patch (Patch). Es schützt vor dieser besonderen Schwachstelle, aber nicht vor anderen, die noch nicht gefunden (oder gefunden, aber nicht veröffentlicht) wurden. Die in den Beispielen untersuchten Schwachstellen sind natürlich schon lange von Microsoft behoben und wer es wollte, hat sich schon um seine Sicherheit gekümmert.
3. Deaktivieren Sie im Browser ActiveX und Active Scripting.
Diese Maßnahme macht es unmöglich, ActiveX auszuführen und Java- oder VBS-Skripte auszuführen. Dadurch werden die meisten CDS-Angriffe wirkungslos, obwohl sie die Funktionalität der besuchten Seiten erheblich beeinträchtigen können. Nicht immer CDS für einen erfolgreichen Angriff erfordert jedoch Unterstützung durch den ActiveX-Browser oder Active Scripting - und dies ist kein Allheilmittel für alle Übel!
4. Arbeiten Sie im Internet nur mit eingeschränkten Rechten.
Die Umsetzung dieser Empfehlung wird, auch im Falle eines erfolgreichen Angriffs, möglichen Schaden reduzieren. Wie Sie wissen, wird der Browser (und damit alle darin enthaltenen Skripte) mit den Rechten des aktuellen Benutzers ausgeführt. Lassen Sie nicht zu, dass Hacker Vasya cmd.exe mit Administratorrechten erhält :) !!
Wenn Sie all diese Empfehlungen befolgen, wird es schwierig, für das domänenübergreifende Scripting anzugreifen!