XXE - XEE - XML External Entity
PreviousXSLT Server Side Injection (Extensible Stylesheet Language Transformations)NextXSS (Cross Site Scripting)
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
XML ist eine Auszeichnungssprache, die für die Speicherung und den Transport von Daten entwickelt wurde und eine flexible Struktur aufweist, die die Verwendung von beschreibend benannten Tags ermöglicht. Es unterscheidet sich von HTML, da es nicht auf eine Menge vordefinierter Tags beschränkt ist. Die Bedeutung von XML hat mit dem Aufstieg von JSON abgenommen, trotz seiner anfänglichen Rolle in der AJAX-Technologie.
Datenrepräsentation durch Entitäten: Entitäten in XML ermöglichen die Darstellung von Daten, einschließlich spezieller Zeichen wie < und >, die < und > entsprechen, um Konflikte mit dem Tag-System von XML zu vermeiden.
Definition von XML-Elementen: XML ermöglicht die Definition von Elementtypen, die festlegen, wie Elemente strukturiert sein sollten und welchen Inhalt sie enthalten dürfen, von beliebigem Inhalt bis hin zu spezifischen Kind-Elementen.
Dokumenttypdefinition (DTD): DTDs sind entscheidend in XML, um die Struktur des Dokuments und die Arten von Daten, die es enthalten kann, zu definieren. Sie können intern, extern oder eine Kombination sein und leiten, wie Dokumente formatiert und validiert werden.
Benutzerdefinierte und externe Entitäten: XML unterstützt die Erstellung benutzerdefinierter Entitäten innerhalb einer DTD für eine flexible Datenrepräsentation. Externe Entitäten, die mit einer URL definiert sind, werfen Sicherheitsbedenken auf, insbesondere im Kontext von XML External Entity (XXE)-Angriffen, die die Art und Weise ausnutzen, wie XML-Parser externe Datenquellen behandeln: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
XXE-Erkennung mit Parameterentitäten: Zur Erkennung von XXE-Schwachstellen, insbesondere wenn herkömmliche Methoden aufgrund von Sicherheitsmaßnahmen des Parsers fehlschlagen, können XML-Parameterentitäten verwendet werden. Diese Entitäten ermöglichen Out-of-Band-Erkennungstechniken, wie das Auslösen von DNS-Abfragen oder HTTP-Anfragen an eine kontrollierte Domain, um die Schwachstelle zu bestätigen.
<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>
<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>
In diesem Angriff werde ich testen, ob eine einfache neue ENTITY-Deklaration funktioniert.
Lass uns versuchen, /etc/passwd auf verschiedene Arten zu lesen. Für Windows könntest du versuchen zu lesen: C:\windows\system32\drivers\etc\hosts
In diesem ersten Fall beachte, dass SYSTEM "**file:///**etc/passwd" ebenfalls funktionieren wird.
Dieser zweite Fall sollte nützlich sein, um eine Datei zu extrahieren, wenn der Webserver PHP verwendet (nicht der Fall in den Portswigger-Labs)
In diesem dritten Fall beachten Sie, dass wir das Element stockCheck als ANY deklarieren.
In Java-basierten Anwendungen könnte es möglich sein, den Inhalt eines Verzeichnisses aufzulisten über XXE mit einem Payload wie (nur nach dem Verzeichnis anstelle der Datei fragen):
Ein XXE könnte verwendet werden, um eine SSRF in einer Cloud auszunutzen.
Mit der vorher kommentierten Technik kannst du den Server dazu bringen, auf einen Server zuzugreifen, den du kontrollierst, um zu zeigen, dass er anfällig ist. Wenn das jedoch nicht funktioniert, liegt es möglicherweise daran, dass XML-Entitäten nicht erlaubt sind. In diesem Fall könntest du versuchen, XML-Parameterentitäten zu verwenden:
In diesem Fall werden wir den Server dazu bringen, eine neue DTD mit einer bösartigen Payload zu laden, die den Inhalt einer Datei über eine HTTP-Anfrage sendet (für mehrzeilige Dateien könnten Sie versuchen, sie über _ftp://_ zu exfiltrieren, indem Sie beispielsweise diesen einfachen Server verwenden xxe-ftp-server.rb). Diese Erklärung basiert auf Portswiggers-Labor hier.
In der gegebenen bösartigen DTD werden eine Reihe von Schritten durchgeführt, um Daten zu exfiltrieren:
Die Struktur ist wie folgt:
Die von diesem DTD ausgeführten Schritte umfassen:
Definition von Parameterentitäten:
Eine XML-Parameterentität, %file, wird erstellt, die den Inhalt der Datei /etc/hostname liest.
Eine weitere XML-Parameterentität, %eval, wird definiert. Sie erklärt dynamisch eine neue XML-Parameterentität, %exfiltrate. Die %exfiltrate-Entität ist so eingestellt, dass sie eine HTTP-Anfrage an den Server des Angreifers sendet und den Inhalt der %file-Entität innerhalb der Abfragezeichenfolge der URL übergibt.
Ausführung von Entitäten:
Die %eval-Entität wird verwendet, was zur Ausführung der dynamischen Erklärung der %exfiltrate-Entität führt.
Die %exfiltrate-Entität wird dann verwendet, was eine HTTP-Anfrage an die angegebene URL mit dem Inhalt der Datei auslöst.
Der Angreifer hostet dieses bösartige DTD auf einem Server unter seiner Kontrolle, typischerweise unter einer URL wie http://web-attacker.com/malicious.dtd.
XXE Payload: Um eine verwundbare Anwendung auszunutzen, sendet der Angreifer eine XXE-Payload:
Dieses Payload definiert eine XML-Parameterentität %xxe und integriert sie in die DTD. Wenn sie von einem XML-Parser verarbeitet wird, ruft dieses Payload die externe DTD vom Server des Angreifers ab. Der Parser interpretiert dann die DTD inline, führt die in der bösartigen DTD skizzierten Schritte aus und führt zur Exfiltration der Datei /etc/hostname auf den Server des Angreifers.
In diesem Fall werden wir den Server dazu bringen, eine bösartige DTD zu laden, die den Inhalt einer Datei in einer Fehlermeldung anzeigt (dies ist nur gültig, wenn Sie Fehlermeldungen sehen können). Beispiel von hier.
Eine XML-Parsing-Fehlermeldung, die den Inhalt der Datei /etc/passwd offenbart, kann durch eine bösartige externe Document Type Definition (DTD) ausgelöst werden. Dies wird durch die folgenden Schritte erreicht:
Eine XML-Parameterentität namens file wird definiert, die den Inhalt der Datei /etc/passwd enthält.
Eine XML-Parameterentität namens eval wird definiert, die eine dynamische Deklaration für eine andere XML-Parameterentität namens error integriert. Diese error-Entität versucht, beim Auswerten, eine nicht vorhandene Datei zu laden, wobei die Inhalte der file-Entität als Name verwendet werden.
Die eval-Entität wird aufgerufen, was zur dynamischen Deklaration der error-Entität führt.
Der Aufruf der error-Entität führt zu dem Versuch, eine nicht vorhandene Datei zu laden, was eine Fehlermeldung erzeugt, die den Inhalt der Datei /etc/passwd als Teil des Dateinamens enthält.
Die bösartige externe DTD kann mit dem folgenden XML aufgerufen werden:
Upon execution, die Antwort des Webservers sollte eine Fehlermeldung enthalten, die den Inhalt der Datei /etc/passwd anzeigt.
Bitte beachten Sie, dass externe DTD es uns ermöglicht, eine Entität innerhalb der zweiten (eval) einzuschließen, dies jedoch in der internen DTD verboten ist. Daher können Sie normalerweise keinen Fehler erzwingen, ohne eine externe DTD zu verwenden.
Was ist also mit blinden XXE-Schwachstellen, wenn out-of-band Interaktionen blockiert sind (externe Verbindungen nicht verfügbar sind)?
Ein Schlupfloch in der XML-Spezifikation kann sensible Daten durch Fehlermeldungen offenlegen, wenn die DTD eines Dokuments interne und externe Deklarationen mischt. Dieses Problem ermöglicht die interne Neudefinition von extern deklarierten Entitäten, was die Durchführung von fehlerbasierten XXE-Angriffen erleichtert. Solche Angriffe nutzen die Neudefinition einer XML-Parameterentität aus, die ursprünglich in einer externen DTD deklariert wurde, aus einer internen DTD heraus. Wenn out-of-band Verbindungen vom Server blockiert werden, müssen Angreifer auf lokale DTD-Dateien zurückgreifen, um den Angriff durchzuführen, mit dem Ziel, einen Parsing-Fehler zu erzeugen, um sensible Informationen offenzulegen.
Betrachten Sie ein Szenario, in dem das Dateisystem des Servers eine DTD-Datei unter /usr/local/app/schema.dtd enthält, die eine Entität namens custom_entity definiert. Ein Angreifer kann einen XML-Parsing-Fehler hervorrufen, der den Inhalt der Datei /etc/passwd offenlegt, indem er eine hybride DTD wie folgt einreicht:
Die skizzierten Schritte werden durch diese DTD ausgeführt:
Die Definition einer XML-Parameterentität namens local_dtd umfasst die externe DTD-Datei, die sich im Dateisystem des Servers befindet.
Eine Neudefinition erfolgt für die XML-Parameterentität custom_entity, die ursprünglich in der externen DTD definiert wurde, um einen fehlerbasierten XXE-Exploit zu kapseln. Diese Neudefinition ist darauf ausgelegt, einen Parsing-Fehler auszulösen, der den Inhalt der Datei /etc/passwd offenbart.
Durch die Verwendung der local_dtd-Entität wird die externe DTD aktiviert, die die neu definierte custom_entity umfasst. Diese Abfolge von Aktionen führt zur Ausgabe der angestrebten Fehlermeldung des Exploits.
Echtweltbeispiel: Systeme, die die GNOME-Desktopumgebung verwenden, haben oft eine DTD unter /usr/share/yelp/dtd/docbookx.dtd, die eine Entität namens ISOamso enthält.
Da diese Technik eine interne DTD verwendet, müssen Sie zuerst eine gültige finden. Sie könnten dies tun, indem Sie das gleiche Betriebssystem / die gleiche Software installieren, die der Server verwendet, und einige Standard-DTDs durchsuchen, oder eine Liste von Standard-DTDs in Systemen abrufen und überprüfen, ob eine von ihnen existiert:
Für weitere Informationen siehe https://portswigger.net/web-security/xxe/blind
In dem folgenden großartigen GitHub-Repo kannst du Pfade von DTDs finden, die im System vorhanden sein können:
Darüber hinaus, wenn du das Docker-Image des Opfersystems hast, kannst du das Tool aus demselben Repo verwenden, um das Image zu scannen und den Pfad der DTDs im System zu finden. Lies die Readme des GitHub, um zu erfahren, wie.
Für eine detailliertere Erklärung dieses Angriffs, sehen Sie sich den zweiten Abschnitt von diesem erstaunlichen Beitrag von Detectify an.
Die Möglichkeit, Microsoft Office-Dokumente hochzuladen, wird von vielen Webanwendungen angeboten, die dann bestimmte Details aus diesen Dokumenten extrahieren. Zum Beispiel kann eine Webanwendung Benutzern erlauben, Daten durch das Hochladen einer XLSX-Format-Tabelle zu importieren. Damit der Parser die Daten aus der Tabelle extrahieren kann, muss er zwangsläufig mindestens eine XML-Datei parsen.
Um diese Schwachstelle zu testen, ist es notwendig, eine Microsoft Office-Datei mit einem XXE-Payload zu erstellen. Der erste Schritt besteht darin, ein leeres Verzeichnis zu erstellen, in das das Dokument entpackt werden kann.
Sobald das Dokument entpackt wurde, sollte die XML-Datei, die sich unter ./unzipped/word/document.xml befindet, in einem bevorzugten Texteditor (wie vim) geöffnet und bearbeitet werden. Die XML sollte so modifiziert werden, dass der gewünschte XXE-Payload enthalten ist, der oft mit einer HTTP-Anfrage beginnt.
Die modifizierten XML-Zeilen sollten zwischen den beiden Wurzel-XML-Objekten eingefügt werden. Es ist wichtig, die URL durch eine überwachbare URL für Anfragen zu ersetzen.
Schließlich kann die Datei gezippt werden, um die bösartige poc.docx-Datei zu erstellen. Aus dem zuvor erstellten "unzipped"-Verzeichnis sollte der folgende Befehl ausgeführt werden:
Jetzt kann die erstellte Datei in die potenziell anfällige Webanwendung hochgeladen werden, und man kann hoffen, dass eine Anfrage in den Burp Collaborator-Protokollen erscheint.
Das jar-Protokoll ist ausschließlich innerhalb von Java-Anwendungen zugänglich. Es ist so konzipiert, dass es den Dateizugriff innerhalb eines PKZIP-Archivs (z. B. .zip, .jar usw.) ermöglicht, sowohl für lokale als auch für entfernte Dateien.
Um auf Dateien innerhalb von PKZIP-Dateien zugreifen zu können, ist es super nützlich, XXE über System-DTD-Dateien auszunutzen. Überprüfen Sie diesen Abschnitt, um zu lernen, wie man System-DTD-Dateien ausnutzt.
Der Prozess, um auf eine Datei innerhalb eines PKZIP-Archivs über das jar-Protokoll zuzugreifen, umfasst mehrere Schritte:
Eine HTTP-Anfrage wird gestellt, um das Zip-Archiv von einem bestimmten Ort herunterzuladen, wie z.B. https://download.website.com/archive.zip.
Die HTTP-Antwort, die das Archiv enthält, wird vorübergehend auf dem System gespeichert, typischerweise an einem Ort wie /tmp/....
Das Archiv wird dann extrahiert, um auf seinen Inhalt zuzugreifen.
Die spezifische Datei im Archiv, file.zip, wird gelesen.
Nach dem Vorgang werden alle temporären Dateien, die während dieses Prozesses erstellt wurden, gelöscht.
Eine interessante Technik, um diesen Prozess im zweiten Schritt zu unterbrechen, besteht darin, die Serververbindung unbegrenzt offen zu halten, während die Archivdatei bereitgestellt wird. Werkzeuge, die in diesem Repository verfügbar sind, können hierfür verwendet werden, einschließlich eines Python-Servers (slow_http_server.py) und eines Java-Servers (slowserver.jar).
Das Schreiben von Dateien in ein temporäres Verzeichnis kann helfen, eine andere Schwachstelle auszunutzen, die eine Pfad Traversierung beinhaltet (wie lokale Datei-Einbindung, Template-Injection, XSLT RCE, Deserialisierung usw.).
Auf Windows-Hosts ist es möglich, den NTML-Hash des Webserver-Benutzers zu erhalten, indem man einen Responder.py-Handler einrichtet:
und indem Sie die folgende Anfrage senden
Dann können Sie versuchen, den Hash mit hashcat zu knacken.
Bei der Integration von Kundendaten in serverseitige XML-Dokumente, wie sie in Backend-SOAP-Anfragen vorkommen, ist die direkte Kontrolle über die XML-Struktur oft eingeschränkt, was traditionelle XXE-Angriffe aufgrund von Einschränkungen bei der Modifizierung des DOCTYPE-Elements erschwert. Ein XInclude-Angriff bietet jedoch eine Lösung, indem er die Einfügung externer Entitäten innerhalb eines beliebigen Datenelements des XML-Dokuments ermöglicht. Diese Methode ist effektiv, selbst wenn nur ein Teil der Daten innerhalb eines servergenerierten XML-Dokuments kontrolliert werden kann.
Um einen XInclude-Angriff auszuführen, muss der XInclude-Namensraum deklariert und der Dateipfad für die beabsichtigte externe Entität angegeben werden. Unten ist ein prägnantes Beispiel, wie ein solcher Angriff formuliert werden kann:
Check https://portswigger.net/web-security/xxe für weitere Informationen!
Von Benutzern hochgeladene Dateien in bestimmten Anwendungen, die dann auf dem Server verarbeitet werden, können Schwachstellen in der Handhabung von XML oder XML-haltigen Dateiformaten ausnutzen. Häufige Dateiformate wie Office-Dokumente (DOCX) und Bilder (SVG) basieren auf XML.
Wenn Benutzer Bilder hochladen, werden diese Bilder serverseitig verarbeitet oder validiert. Selbst für Anwendungen, die Formate wie PNG oder JPEG erwarten, kann die Bildverarbeitungsbibliothek des Servers auch SVG-Bilder unterstützen. SVG, als XML-basiertes Format, kann von Angreifern ausgenutzt werden, um bösartige SVG-Bilder einzureichen, wodurch der Server XXE (XML External Entity) -Schwachstellen ausgesetzt wird.
Ein Beispiel für einen solchen Exploit ist unten dargestellt, wo ein bösartiges SVG-Bild versucht, Systemdateien zu lesen:
Ein weiteres Verfahren besteht darin, zu versuchen, Befehle auszuführen über den PHP "expect" Wrapper:
In beiden Fällen wird das SVG-Format verwendet, um Angriffe zu starten, die die XML-Verarbeitungsfähigkeiten der Software des Servers ausnutzen, was die Notwendigkeit robuster Eingangsvalidierung und Sicherheitsmaßnahmen hervorhebt.
Überprüfen Sie https://portswigger.net/web-security/xxe für weitere Informationen!
Beachten Sie, dass die erste Zeile der gelesenen Datei oder des Ergebnisses der Ausführung INDEM erstellten Bild erscheint. Sie müssen also in der Lage sein, auf das Bild zuzugreifen, das SVG erstellt hat.
Lesen Sie den folgenden Beitrag, um zu lernen, wie man eine XXE beim Hochladen einer PDF-Datei ausnutzt:
PDF Upload - XXE and CORS bypassWenn eine POST-Anfrage die Daten im XML-Format akzeptiert, könnten Sie versuchen, eine XXE in dieser Anfrage auszunutzen. Zum Beispiel, wenn eine normale Anfrage Folgendes enthält:
Dann könnten Sie die folgende Anfrage mit demselben Ergebnis einreichen:
Um die Anfrage zu ändern, könnten Sie eine Burp-Erweiterung namens „Content Type Converter“ verwenden. Hier finden Sie dieses Beispiel:
Ein weiteres Beispiel finden Sie hier.
Das funktioniert nur, wenn der XML-Server das data://-Protokoll akzeptiert.
Sie können das ["Encode Recipe" von cyberchef hier ]([https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to) in UTF-7 umwandeln.
Wenn das Web PHP verwendet, anstatt file:/ zu verwenden, können Sie php wrappers php://filter/convert.base64-encode/resource= verwenden, um auf interne Dateien zuzugreifen.
Wenn das Web Java verwendet, können Sie das jar: protocol überprüfen.
Trick von https://github.com/Ambrotd/XXE-Notes Sie können eine Entity innerhalb einer Entity erstellen, indem Sie sie mit html entities kodieren und dann aufrufen, um eine dtd zu laden. Beachten Sie, dass die verwendeten HTML Entities numerisch sein müssen (wie [in diesem Beispiel](https://gchq.github.io/CyberChef/#recipe=To_HTML_Entity%28true,'Numeric entities'%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\).
DTD-Beispiel:
Extrahieren index.php
Wenn das PHP "expect" Modul geladen ist
Dieses Beispiel ist inspiriert von https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe
XLIFF (XML Localization Interchange File Format) wird verwendet, um den Datenaustausch in Lokalisierungsprozessen zu standardisieren. Es ist ein XML-basiertes Format, das hauptsächlich zum Übertragen lokalisierbarer Daten zwischen Werkzeugen während der Lokalisierung und als gemeinsames Austauschformat für CAT (Computer-Aided Translation) Werkzeuge verwendet wird.
Eine Anfrage wird an den Server mit folgendem Inhalt gesendet:
Jedoch löst diese Anfrage einen internen Serverfehler aus, der speziell ein Problem mit den Markup-Deklarationen erwähnt:
Trotz des Fehlers wird ein Treffer auf Burp Collaborator aufgezeichnet, was auf ein gewisses Maß an Interaktion mit der externen Entität hinweist.
Out of Band Data Exfiltration Um Daten zu exfiltrieren, wird eine modifizierte Anfrage gesendet:
Dieser Ansatz zeigt, dass der User Agent die Verwendung von Java 1.8 anzeigt. Eine bemerkte Einschränkung dieser Version von Java ist die Unfähigkeit, Dateien mit einem Zeilenumbruchzeichen, wie /etc/passwd, mithilfe der Out of Band-Technik abzurufen.
Error-Based Data Exfiltration Um diese Einschränkung zu überwinden, wird ein Error-Based-Ansatz verwendet. Die DTD-Datei ist wie folgt strukturiert, um einen Fehler auszulösen, der Daten aus einer Zieldatei enthält:
Der Server antwortet mit einem Fehler, der wichtig auf die nicht vorhandene Datei hinweist und anzeigt, dass der Server versucht, auf die angegebene Datei zuzugreifen:
Um den Inhalt der Datei in die Fehlermeldung einzufügen, wird die DTD-Datei angepasst:
Diese Modifikation führt zur erfolgreichen Exfiltration des Inhalts der Datei, da sie im Fehlerausgabe, die über HTTP gesendet wird, reflektiert wird. Dies zeigt einen erfolgreichen XXE (XML External Entity) Angriff an, der sowohl Out of Band- als auch Error-Based-Techniken nutzt, um sensible Informationen zu extrahieren.
Gültiges XML im RSS-Format zur Ausnutzung einer XXE-Schwachstelle.
Einfacher HTTP-Anfrage an den Server des Angreifers.
Verwendung des PHP base64 Filters
XMLDecoder ist eine Java-Klasse, die Objekte basierend auf einer XML-Nachricht erstellt. Wenn ein böswilliger Benutzer eine Anwendung dazu bringen kann, beliebige Daten in einem Aufruf der Methode readObject zu verwenden, erhält er sofort die Möglichkeit zur Codeausführung auf dem Server.
Informationen über HTTP mit eigener externer DTD extrahieren: https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/\
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
