© istockphoto.com/AskoldRomanov
XML ist mächtig ... mächtig interessant für Angreifer

XML-Sicherheit - XXE, XSLT und etwas SSRF


Angriffe über XML waren indirekt bereits Thema im Artikel über Server-side Request Forgery (SSRF) [1], wo sie als „Transportmittel“ für die eingeschleusten Angriffe dienten. Allein diese Angriffe sind schon Grund genug, einen Blick auf die Sicherheit von XML zu werfen.

Eigentlich sollte dieser Artikel schon früher erscheinen, aber die Black Hat USA 2015 machte mir einen Strich durch die Planung. Denn für diese Konferenz waren ganze drei (!) Vorträge rund um XML, XXE und XSLT angekündigt worden – plus einem zur SSRF. Bei so einer Ballung von Vorträgen muss da ja etwas ganz gewaltig im Argen liegen und es bestand die Gefahr, dass der Artikel schon bei der Veröffentlichung überholt gewesen wäre.

Ganz so schlimm wäre es zum Glück nicht geworden; an den in den Kästen aufgeführten Schutzmaßnahmen hat sich durch die Vorträge nichts geändert. Dafür gibt es neue Angriffe, die zeigen, wie wichtig es ist, sich vor manipulierten XML- und XSLT-Daten zu schützen. Und was ist besser als Beispiele? Neue, aktuelle Beispiele. Aber bevor wir zu denen kommen, gibt es erst einmal eine Ergänzung zum Artikel über SSRF [1]. Darin wurden bereits einige Angriffe über SSRF dargestellt: von Portscans „über Bande“ über die Codeausführung auf SAP-Systemen hinter einer Firewall bis hin zu allen möglichen Angriffen auf alle möglichen, eigentlich gar nicht direkt aus dem Internet zugänglichen Systeme.

Auf der Black Hat USA wurde dann noch eine weitere Möglichkeit für SSRF-Angriffe vorgestellt: Über eine Schwachstelle in einem Content Delivery Network (CDN) können alle Webanwendungen angegriffen werden, die diesem CDN vertrauen. Im Gegensatz zu vielen anderen SSRF-Angriffen kommt dieser ganz ohne die Verwendung von XML aus.

Der Vortrag von Mike Brooks und Matthew Bryant trägt einen auf den ersten Blick etwas merkwürdigen Titel: „Bypass Surgery Abusing Content Delivery Networks with Server-Side-Request Forgery (SSRF), Flash, and DNS“ [2]. Das klingt nach einem komplizierten Angriff, aber wenn man weiß, wie es geht, ist er eigentlich recht einfach.

Vertrauensfragen

Fast alle modernen Webanwendungen sind auf Dienste von Drittanbietern angewiesen, wie zum Beispiel Goo­gle Analytics, CloudFlare oder Amazon Web Services. Diesen Drittanbietern, die unsichtbar im Hintergrund arbeiten, wird implizit vertraut. Dazu kommen die CDNs, die Inhalte über ihre weit verteilten Netze ausliefern und denen man als Benutzer beim Besuch einer Website ebenfalls vertraut – meist ohne es zu wissen.

Die Zeiten, in denen der Browser einen Request an einen Webserver geschickt hat, der dann die gesamte Seite selbst lieferte, sind lange vorbei. Inzwischen werden von jeder geladenen Seite etliche Requests an eine Vielzahl von Diensten geschickt. Einer davon sind die CDNs. Davon gibt es relativ wenige und ihnen vertrauen äußerst viele Websites. Aber was passiert, wenn eines davon eine Schwachstelle enthält? Kann darüber zum Beispiel Schadcode in alle das betroffene CDN nutzenden Webanwendungen eingeschleust werden? Sie erraten es bestimmt schon: Ja, das geht.

Ein paar Vorbemerkungen

Mike Brooks und Matthew Bryant beschreiben zunächst, wie sich über DNS-Abfragen das Angriffsziel auskundschaften lässt; darauf verzichte ich hier. Der Angreifer muss wissen, welche Server aus dem internen Netz des Opfers tatsächlich von einem CDN gehostet werden, darauf komme ich unten noch mal zurück.

Legen wir also gleich mit den für den Angriff verwendeten Flash-Dateien los. Warum soll eine Flash-Datei eingeschleust werden und keine JavaScript-Datei? Der Unterschied zwischen beiden Dateitypen liegt im Kontext der Origin, in dem eingebundene Dateien ausgeführt werden:

  • Remote eingebundene JavaScript-Dateien werden im Kontext der Origin der einbindenden Domain ausgeführt.

  • Remote eingebundene Flash-Dateien werden im Kontext der Origin der hostenden Domain ausgeführt.

Wenn also die Webanwendung auf ziel.example eine JavaScript-Datei von dritter.example einbindet, hat sie die Origin ziel.example und kann im Rahmen der Same-Origin Policy auf Inhalte von ziel.example zugreifen. Wird aber eine Flash-Datei von dritter.example eingebunden, hat sie die Origin dritter.example und kann dementsprechend auf Inhalte von dritter.example zugreifen – und damit auf vertrauliche Daten von dritter.example, auf die von ziel.example nicht zugegriffen werden kann.

Bevor Flash einen Cross-Origin Request ausführt, wird die Datei crossdomain.xml des Ziels geprüft, über die Zugriffe fremder Server geregelt werden. Dafür können Wildcards verwendet werden, was auch sehr verbreitet ist. Für ziel.example könnte die crossdomain.xml zum Beispiel so aussehen:

<cross-domain-policy> <allow-access-from domain="*.ziel.example> <allow-access-from domain="*.dritter.example> </cross-domain-policy>

Das hat fatale Konsequenzen: Wenn auf einer Subdomain von ziel.example oder dritter.example eine verwundbare SWF-Datei vorhanden ist oder eine bösartige SWF-Datei hochgeladen werden kann, ist die Sicherheit von ziel.example kompromittiert.

Ein Beispiel für eine verwundbare SWF-Datei sind veraltete Versionen des Videoplayers FlowPlayer, die das Laden beliebiger Flash-Plug-ins erlauben – vor Version 3.2.16 etwa von beliebigen Domains. Ein Angreifer kann also über ein bösartiges Plug-in die Kontrolle über den FlowPlayer übernehmen. Ab Version 3.2.18 wird beim Laden eines Plug-ins dessen URL geprüft, die Prüfung kann aber auf mindestens drei Wegen umgangen werden.

Der Angriff im Überblick

Aber kommen wir zum Angriff, zunächst ohne CDN. Beteiligt sind ein Benutzer, der Server ziel.example (zum Beispiel die Website einer Bank) und der Server des Angreifers, angreifer.example. Der Angriff läuft dann so ab (Abb. 1):

  • Der Benutzer loggt sich auf ziel.example ein.

  • Der Benutzer ruft angreifer.example auf.

  • Der Angreifer lädt die verwundbare Version des FlowPlayers von ziel.example.

  • Der Angreifer kompromittiert den FlowPlayer über ein präpariertes Plug-in.

  • Der Angreifer kann nun im Namen des Benutzers authentifizierte Requests an ziel.example schicken.

eilers_xml-sicherheit_1.tif_fmt1.jpgAbb. 1: Der SSRF-Angriff ohne CDN
akamai.beispiel.example => x.beispiel.example.edgesuite.net => a1337.g.akamai.net => 184.25.56.98

Requests an beispiel.example werden also nicht mehr nur von beispiel.example beantwortet, sondern zum Teil auch von akamai.beispiel.example, hinter dem sich der Akamai-Server mit der IP-Adresse 184.25.56.98 verbirgt. Der nächste Baustein ist der Akamai Resource Locator v1 (ARLv1), ein eigentlich veralteter, aber oft noch verwendeter spezieller URL für bei Akamai gehostete Inhalte. Damit wird zum Beispiel aus dem URL http://beispiel.example.edgesuite.net/flow/swf/­example.swf für eine bei Akamai gehostete SWF-Datei der ARL http://akamai.­beispiel.example/f/248/322142/1d/­beispiel.example.edgesuite.net/flow/swf/example.swf, bestehend aus der zu Akamai weisenden Domain akamai.beispiel.­example, Cacheoptionen (f/248/322142/1d/) und dem URL der Datei bei Akamai, beispiel.example.edgesuite.net/flow/swf/example.swf.

Beim Einrichten von Akamais Diensten werden die Daten vom Server der Webanwendung in Akamais verteiltes Netzwerk kopiert. Verweist akamai.­beispiel.­example auf Akamais Edge-Service, können darüber dem Server mit ARLs nach dem Muster http://akamai.beispiel.example/f/1/1/1/fremde-site.example/pfad/zur/datei.ext theoretisch beliebige Dateien untergeschoben werden. Das will man natürlich nicht, daher können nur Dateien von einer festgelegten Liste mit Sites geladen werden. Über einen Brute-Force-Angriff kann diese Whitelist ausgespäht werden. Mike Brooks und Matthew Bryant stießen bei ihrer Suche auf den URL http://mediapm.edgesuite.net/flow/swf/flowplayer-v3.2.16.swf. Akamai hostet also nicht nur den FlowPlayer, sondern auch noch eine verwundbare Version, über die beliebige Plug-ins von beliebigen Servern geladen werden können. Im Endeffekt bedeutet das, da...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang