Dipl.-Inform. Carsten Eilers

Ein Beispiel dafür, wie weit verbreitet XML ist, ist die ebenfalls auf XML basierende Security Assertion Markup Language (SAML), der Industriestandard für Identitätsmanagement im Rahmen eines Single Sign-On. Auch über SAML sind (meist blinde, siehe unten) XXE-Angriffe möglich. Wie man die Schwachstellen entdecken kann, haben Vladislav Mladenov und Christian Mainka im Blog "On Web-Security and -Insecurity" beschrieben. Die beiden verwenden die Domain des Angreifers für die External Entity und warten darauf, ob es einen Zugriff auf den angegebenen URL gibt. 10 von 22 getesteten Software-as-a-Service Webanwendungen, die Single Sign-On über SAML unterstützen, waren für XXE Angriffe anfällig.

2017: XXE bei Symantec

2017 wurde in der Admin-Weboberfläche "Symantec Management Console" (SME) für die Symantec Management Platform eine XXE-Schwachstelle gefunden: CVE-2017-6323. Während Symantec selbst die Gefahr durch Schwachstelle nur als "mittel" einstufte hielt das CERT Bund des BSI das Risiko für "hoch".

Der Angriff kann die üblichen Folgen eines XXE-Angriffs haben: Vom Ausspähen sensibler Daten bis zu Angriffen auf lokale Server und Dienste.

Das sind wohl genug Beispiele. Da drängt sich eine Frage auf:

Ist XXE die neue SQL Injection?

Schon Anfang Januar 2014 und lange vor der Entwicklung der OWASP Top 10 2017 hat sich Bojan Zdrnja im InfoSec Handlers Diary Blog die Frage "Is XXE the new SQLi?" gestellt.

In der Tat nimmt die Verbreitung von XML immer weiter zu, und damit natürlich auch die von XXE-Schwachstellen. Es gibt einfach viel mehr Code, der XML verarbeitet. Und im Vergleich zur SQL Injection haben XXE Angriffe für den Angreifer einen großen Vorteil: Mit SQL Injection lassen sich oft "nur" Daten aus der betroffenen Datenbank ausspähen, mitunter auch aus weiteren Datenbanken auf dem gleichen Server. Über XXE lassen sich aber meist viel mehr Informationen ausspähen, und auch weiterführende Angriffe sind möglich, wie die SSRF-Beispiele gezeigt haben.

XXE ist also sehr viel vielfältiger einsetzbar als SQL Injection, und das lockt sicher auch Angreifer an. Aber XXE Angriffe lassen sich auch recht einfach verhindern, indem entweder ganz auf External Entities verzichtet wird oder dem Benutzer und damit Angreifern die Manipulation der DTD verboten wird.

Außerdem befinden sich XXE-Schwachstellen üblicherweise in Libraries, Tools oder Anwendungen, während SQL Injection Schwachstellen sich in Webanwendungen etc. befinden. Es gibt also viel mehr Möglichkeiten für SQL Injection Schwachstellen als für XXE-Schwachstellen. XXE Angriffe werden SQL Injection also kaum den Rang ablaufen.

Im Januar 2015 hat Bojan Zdrnja dann beschrieben, wie sich "Blind XXE"-Schwachstellen entdecken lassen, also Schwachstellen in Code, der das Ergebnis der XML-Auswertung nicht an den Benutzer zurück gibt. Das funktioniert ebenso wie bei Blind SQL Injection über Tests, bei denen der Tester auch ohne direkte Rückmeldung durch die App feststellen kann, ob External Entities verarbeitet werden oder nicht. Zum Beispiel, indem eine nicht existierende Subdomain im URL für die External Entity verwendet wird und beim zuständigen DNS-Server geprüft wird, ob es eine DNS-Abfrage für diese Subdomain gibt.

Schutz vor XXE-Angriffen

Zum Schutz vor XXE-Angriffen sollte die Auswertung von External Entities ausgeschaltet werden. Für den Default PHP XML-Parser ist dafür z.B. die Option libxml_disable_entity_loader zuständig, die auf TRUE gesetzt werden muss. Und das sollten Sie besser auch tun, den sonst können unter Umständen sogar über den expect://-Handler Shell-Befehle auf Ihren Server ausgeführt werden.

Alternativ kann auch die Verwendung von externen DTDs (egal ob als Teil der XML-Datei oder darin referenziert) verboten werden.

Willis Vandevanter hat in seinem schon im ersten Teil vorgestellten Vortrag auch darauf hingewiesen, dass alle Libraries immer aktuell gehalten werden müssen, um mögliche Schwachstellen möglichst schnell zu schließen. Was ja eigentlich eine Selbstverständlichkeit sein sollte.

Als zusätzlicher Schutz sollte die Prüfung sämtlicher XML-Eingaben einem darauf spezialisierten Gateway übertragen werden, so dass nur eindeutig harmlose XML-Daten die Anwendungen erreichen.

Soviel zu den XXE-Angriffen und wie man sie abwehrt. Ab der nächsten Folge geht es um die auch nicht gerade ungefährliche XML Injection.

Carsten Eilers