Skip to content

XML-Sicherheit, Teil 2: XXE-Angriffe, zum zweiten!

Die XXE-Angriffe stehen auf Platz 4 der aktuellen OWASP Top 10. Worum es dabei generell geht haben Sie bereits im ersten Teil erfahren, in dem ich Ihnen auch einige Beispiele für XXE-Schwachstellen vorgestellt habe. Und davon gibt es noch viel mehr.

Noch zwei XXE-Schwachstellen...

Xiaoran Wang und Sergey Gorbaty haben auf der Black Hat USA 2015 zwei bis dahin unveröffentlichte XXE-Schwachstellen vorgestellt und ihre Entdeckung beschrieben: "FileCry - The New Age of XXE".

Die erste Schwachstelle wurde im JDK XML Entity Expander gefunden. Der ging immer davon aus, dass der URL einer External Entity wohlgeformt ist und versuchte, ihn aufzulösen.

Da die meisten XML-Parser für Java (TransformerFactory, Validator, SchemaFactory, Unmarshaller, SAXTransformerFactory, XPathExpression, XMLReader sowie von Drittherstellern org.apache.commons.digester.Digester, Woodstock, dom4j, XOM, OpenSAML, Apache Hadoop, ...) diesen Expander verwenden waren sie auf einen Schlag alle für XXE anfällig, sofern keine entsprechenden Schutzmaßnahmen aktiviert waren. Die natürlich für jeden Parser anders ausfallen, wenn sie denn überhaupt vorhanden sind.

Generell helfen hier die allgemein bekannten Schutzmaßnahmen:

  • Ausschalten der Unterstützung von External Entities
  • Ausschalten der Verwendung externer DTD
  • Ausschalten der generellen Verwendung von DTD

Die zweite Schwachstelle haben Xiaoran Wang und Sergey Gorbaty im Internet Explorer gefunden. In MSXML 6.0 wurde 2006 eine XXE-Schwachstelle behoben, von der die Version 3.0 auch 2015 noch betroffen war. Die durch Erzwingen des Kompatibilitätsmodus im IE aktiviert werden kann, so dass auch die aktuellen Versionen des IE noch von der Schwachstelle betroffen waren.

Zwischen Browser-Engine (zuständig für das Auflösen von External Entities) und dem XML-Parser wird die Same-Origin Policy nur für den ersten Request geprüft, im Fall von Weiterleitungen aber nicht erzwungen. Sie kann daher über XXE umgangen werden kann, so dass alle JSON-Endpunkte, die Cookies für die Authentifizierung verwenden, ausgespäht werden können. Außerdem ist es möglich, lokale Dateien auf dem Rechner des Opfers zu lesen. Allerdings mit Einschränkungen, da die Daten bzw. Dateien die Zeichen <, %, > und das Null-Byte nicht enthalten dürfen.

Die Schwachstelle wurde im April 2015 im IE 11 behoben. Außer dem IE war aber auch jedes andere Programm betroffen, dass die Bibliothek MSXML 3.0 verwendet. Und das waren etliche.

2013: XXE bei Facebook (und vielen anderen)

2013 hat Reginaldo Silva eine Reihe von XXE-Schwachstellen in Verbindung mit OpenID entdeckt, die weite Kreise zogen.

Los ging es mit einer Schwachstelle im OpenID-Modul von Drupal, über die beliebige Dateien gelesen werden konnten. Danach folgten DoS-Schwachstellen in Googles App Engine und Blogger (was Reginaldo Silva 500 US-Dollar Bug Bounty einbrachte), und danach Schwachstellen in vielen verschiedenen OpenID-Implementierungen. Statt alle einzeln zu kontaktieren ließ er auf der nur für Mitglieder zugänglichen Security-Mailinglist der OpenID-Foundation eine Mail mit seinen Forschungsergebnissen veröffentlichen.

Er ging davon aus, dass die meisten Library-Entwickler diese Liste lesen. Und das anscheinend zu Recht, da viele Schwachstellen behoben wurden.

Danach nahm er Facebook unter die Lupe, und erst sah es so aus als wäre Facebook nicht betroffen. Bis er auf die Forgot your password?-Funktion stieß. Die war für XXE anfällig, und letztendlich hätte er darüber auf Facebooks Servern sogar Code ausführen können.

Was ihm die bis dahin größte von Facebook ausgezahlte Bug Bounty einbrachte.

2014: XXE bei Google

Fredrik N. Almroth und Mathias Karlsson von detectify haben 2014 Schwachstellen auf Googles Servern gesucht und auch eine gefunden: Eine XXE-Schwachstelle in der Google Toolbar Button Gallery.

Gereizt hatte sie vor allem die Idee, mit Google als Suchmaschine) nach Schwachstellen in Googles Servern zu suchen. Für die Suche hatten sie sich folgende Strategie überlegt, die sich als erfolgreich herausstellte:

  • Sie haben sich überlegt, welche Software im Allgemeinen die meisten Schwachstellen enthält:
    • Alte und nicht mehr unterstützte Software
    • Unbekannte und nur schwer zugängliche Software
    • Proprietäre Software auf die nur wenige Leute Zugriff haben
    • Alpha- und Beta-Versionen und andere neuen Technologien
  • Und dann haben sie nach passenden "Leichen" bei Google gesucht. Wie schon erwähnt natürlich mit Google. Und sind dabei auf die Google Toolbar Button Gallery gestoßen, und darin auch nach kurzer Zeit fündig geworden.

Entwickler können eigenen Buttons erzeugen, indem sie XML-Dateien mit verschiedenen Meta-Daten hochladen. Und beim Parsen dieser XML-Dateien waren XXS-Angriffe möglich. Über die dann z.B. die Dateien /etc/passwd und /etc/hosts von einem von Googles Produktiv-Servern gelesen werden konnten.

Die Suche hat sich für die Forscher auch finanziell gelohnt: Google zahlte 10.000 US-Dollar Bug Bounty.

In der nächsten Folge gibt es noch weitere Beispiele für XXE-Schwachstellen und -Angriffe, außerdem werde ich die möglichen Schutzmaßnahmen vorstellen.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 3: XXE-Angriffe, zum dritten!

Vorschau anzeigen
Die XXE-Angriffe stehen auf Platz 4 der aktuellen OWASP Top 10. Worum es dabei generell geht haben Sie bereits im ersten Teil erfahren, in dem ich Ihnen auch einige Beispiele für XXE-Schwachstellen vorgestellt habe. Und mit XXE-Schwachstellen

Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 4: XSL Injection, zum ersten

Vorschau anzeigen
Werden XML-Daten vor der Verarbeitung nicht geprüft, kann ein Angreifer darüber eigenen XML-Code einschleusten. Meist kommt es dann zu den schon vorgestellten XML External Entity (XXE) Angriffen. Die stehen auf Platz 4 der aktuellen OWAS

Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 5: XSL Injection, zum zweiten

Vorschau anzeigen
Werden XML-Daten vor der Verarbeitung nicht geprüft, kann ein Angreifer darüber eigenen XML-Code einschleusten. Meist kommt es dann zu den schon vorgestellten XML External Entity (XXE) Angriffen. Die stehen auf Platz 4 der aktuellen OWAS

Dipl.-Inform. Carsten Eilers am : XML-Sicherheit, Teil 6: XPath Injection

Vorschau anzeigen
Werden XML-Daten vor der Verarbeitung nicht geprüft, kann ein Angreifer darüber eigenen XML-Code einschleusten. Meist kommt es dann zu den schon vorgestellten XML External Entity (XXE) Angriffen. Die stehen auf Platz 4 der aktuellen OWAS