Über unsMediaKontaktImpressum
Dr. Juraj Somorovsky 29. Juni 2015

Webservices und Single Sign-On: XML-basierte Angriffe im Überblick

Webservices und Single Sign-On gehören zu den wichtigsten Internettechnologien. Sie werden in Bereichen wie Automotive, Gesundheitswesen, E-Government bis hin zu Cloud-Schnittstellen eingesetzt. Die Wichtigkeit dieser Bereiche deutet darauf hin, dass mit den Daten sehr vorsichtig umgangen wird. In den letzten Jahren wurde allerdings gezeigt, dass diese Technologien zahlreiche schwerwiegende Angriffe ermöglichen.

Webservices und Single Sign-On sind Web-basierte Standards. Daher könnte man sich die berechtigte Frage stellen, ob bekannte Angriffe wie XSS (Cross Site Scripting) oder SQL Injection auf diese Technologien angewandt werden können. Die Antwort ist "Ja, viele Web-Angriffe können auf Webservices und Single Sign-On direkt übertragen werden". Es existieren aber viele weitere Angriffe, die der breiten Masse an Entwicklern nicht bekannt sind. Die Angriffe nutzen die Komplexität der eingesetzten XML-Standards oder ihre weniger bekannten Features aus. Sie erlauben es, Daten aus den fremden Servern auszulesen, sich als beliebiger Nutzer zu authentisieren oder vertrauliche Daten zu entschlüsseln.

In unserem Artikel werden wir auf diese Angriffe eingehen und sie an Beispielen von SOAP- und SAML-Standards vorstellen. Wir möchten aber explizit erwähnen, dass die Angriffe jenseits von SOAP und SAML anwendbar sind, zum Beispiel auf REST-basierte Webservices.

Nötige Grundlagen für unsere Angriffe: XML-basierte Standards

XML (Extensible Markup Language) ist eine plattformunabhängige Auszeichnungssprache zur Darstellung von strukturierten Daten [1]. Sie wurde bereits am Ende der Neunziger standardisiert und ist heutzutage ein Grundbaustein von vielen Standards. Beispiele dafür sind auch SOAP und SAML.

SOAP-basierte Webservices

SOAP definiert Struktur der XML-Nachrichten für eine Maschine-zu-Maschine-Kommunikation (M2M Communication). Die SOAP-Nachrichten sind in der Regel mit zwei Elementen gekennzeichnet: Header und Body. Das Header-Element enthält nachrichtenspezifische Daten wie z. B. Zeitstempel oder Sicherheitstoken. Das Body-Element enthält einen Funktionsaufruf und wird vor allem auf die Geschäftslogik des Empfängers gerichtet.

Das Bild zeigt die Kommunikation zwischen einem Webservice-Client und einem Server. Der Client schickt an den Server eine SOAP-Nachricht, die einen Funktionsaufruf CreateUser enthält. Wenn der Server diese Nachricht empfängt, interpretiert dieser zuerst den Funktionsnamen und den Funktionsparameter im Body-Element. Danach führt er die Funktion aus. Am Ende erstellt er eine SOAP-Nachricht, die über den Status des Aufrufs berichtet. Diese Nachricht schickt er an den Client.

SAML-basiertes Single Sign-On

Der nächste in diesem Artikel betrachtete Standard ist SAML. Die Motivation für die Standardisierung von SAML war ein typisches Passwort-Identität-Problem. Aus dem eigenen, täglichen Internetleben kennt jeder das Problem, im Internet viele Identitäten auf verschiedenen Internetwebseiten zu verwenden und zu verwalten. Damit sich der Benutzer nicht alle Passwörter zu seinen Identitäten merken muss, wurde Single Sign-On entwickelt. Single Sign-On stellt ein Konzept vor, bei dem sich der Benutzer nur einmalig bei einem Identity Provider mit seinem Passwort anmeldet. Der Identity Provider erstellt nachträglich für den Benutzer sogenannte Tokens, die er bei Webseiten (Service Providern) einlösen kann.

In Abb.2 ist ein Benutzer (Bob) dargestellt, der sich auf seiner Webseite einloggen möchte (z. B. Salesforce). Wenn er die Webseite mit seinem Browser besucht, wird er zu seinem Identity Provider weitergeleitet (z. B. Onelogin). Der Identity Provider erstellt für den Benutzer ein signiertes SAML-Token. Mit diesem Token wird der Benutzer wieder zu Salesforce weitergeleitet und dort eingeloggt.

Für den weiteren Verlauf des Artikels müssen wir uns merken, dass bei einem SAML-basierten Single Sign-On XML-basierte SAML-Token eingesetzt werden. Das Token beinhaltet Informationen über den Benutzer und Ablaufdatum. Damit das Token nicht manipuliert wird, wird es vom Identity Provider signiert.

XML-spezifische Angriffe

Im Folgenden fangen wir mit dem spannenden Teil an und präsentieren die ersten Angriffe. Wir starten dabei mit dem XML-Parsing-Prozess.

Um eine eingehende SOAP-Nachricht oder SAML-Nachricht bearbeiten und beantworten zu können, muss diese zuerst geparst werden. XML-Parsing ist ein Prozess, der einen Bytestrom in eine Baum-Struktur übersetzt. Zum Beispiel sieht die oben vorgestellte Nachricht nach dem Parsing-Prozess in einer Baum-Struktur wie in Abb.3 dargestellt aus. Der Server kann diese geparste Struktur sehr einfach bearbeiten, da er auf alle Elemente problemlos zugreifen kann. Allerdings können schon beim Parsing-Prozess die ersten Probleme auftreten.

Denial of Service (DoS)

DoS-Angriffe zielen auf die Verfügbarkeit der Server und der darauf laufenden Dienste ab. Wenn ein Dienst nicht verfügbar ist, können damit dem Betreiber große Schäden verursacht werden. Natürlich können Angreifer mit mächtigen Ressourcen DoS-Angriffe (fast) immer ausführen. Mit XML kann aber ein solcher Angriff auch ohne viel Ressourcenaufwand ermöglicht werden. Der erste (und einfachste) vorgestellte Angriff heißt Coercive Parsing [2]. Der Angreifer erstellt dabei eine XML-Nachricht, welche viele verschachtelte Elemente beinhaltet (s. Abb.4).

Das Problem bei Coercive Parsing liegt darin, dass der Angreifer lediglich wenige Bytes senden muss. Der Server muss jedoch für jedes XML-Element einen Speicherbereich im Arbeitsspeicher des Servers reservieren und zusätzlich zu den offensichtlichen Informationen (z. B. den Namen des Elements) weitere Informationen abspeichern (z. B. eine Referenz auf das Elternelement, Referenzen auf alle Kindelemente, usw.). Dies benötigt wesentlich mehr Speicherplatz als die reine Abspeicherung eines XML-Dokuments in seiner reinen Byteform.

Gegenmaßnahmen: Ähnliche Angriffe können auch mit wiederholenden Attributen oder langen Elementnamen erzielt werden [2]. Daher ist die beste Gegenmaßnahme, die Länge der Nachricht explizit einzugrenzen. Falls dies nicht möglich ist, wird es empfohlen, die Anzahl der Elemente und Attribute und die Baum-Tiefe direkt beim Einlesen zu überprüfen.

XML eXternal Entity (XXE) Angriffe

Eins der größten Ziele von XML war ihre Flexibilität, damit diese Sprache in allen möglichen Szenarien eingesetzt werden kann. Daher beinhaltet XML auch bestimmte Erweiterungen, die heutzutage sehr selten gebraucht werden. Eine dieser Erweiterungen ist Document Type Definition (DTD). DTD erlaubt es, XML-Bausteine zu definieren. Diese Bausteine können direkt in der XML-Datei definiert werden, sie können aber auch aus einer externen Datei kommen. Also mit DTD kann ein Parser gezwungen werden, externe Inhalte einzulesen. Damit ist DTD auch zu einem der wichtigsten Bestandteile zahlreicher Angriffe geworden, die XXE genannt werden. Für ihre Beschreibung betrachten wir Abb.5. Der Server aus der Abbildung akzeptiert Bestellungen über einen Webservice. Bei jeder erfolgreichen Anfrage antwortet der Server mit einer Nachricht, die den Namen des Bestellers beinhaltet.

Jetzt stellen wir uns vor, der Angreifer (Client) definiert in seiner Nachricht eine XML-Entität name, die auf die System-Datei "c:\boot.ini" verweist. Er referenziert die Entität in der XML-Nachricht mit &name;. Wenn der Server diese Nachricht bearbeitet, versucht er die definierte Entität aufzulösen. Dabei liest er den Inhalt der Datei "c:\boot.ini" aus. Anschließend antwortet er dem Angreifer mit einer Nachricht, die den kompletten Dateiinhalt enthält.

Gegenmaßnahmen: Die Gegenmaßnahme gegen diesen Angriff scheint sehr trivial zu sein: man muss DTDs verbieten. Jedoch erfreuen sich XXE-Angriffe in den letzten Jahren einer großen Beliebtheit und tauchen immer wieder in Schlagzeilen auf. Der Grund dafür ist, dass dieses Feature in den üblichen XML-Parsern standardmäßig aktiviert ist. Wenn es von Entwicklern nicht bewusst ausgeschaltet wird, kann es zu diesen schwerwiegenden Angriffen kommen.

Scannen der Netzwerkinfrastruktur mit WS-Addressing Spoofing

Der SOAP-Standard enthält auch einige vergessene Erweiterungen, die ein Angreifer ausnutzen könnte. In der Mehrheit der Webservice-Szenarien sind diese Erweiterungen aber nicht für den eigentlichen Zweck des Webservices notwendig. Eine dieser Erweiterungen ist WS-Addressing.

WS-Adressing ist eine SOAP-Erweiterung, die eine Weiterleitung von SOAP-Nachrichten ermöglicht: In einem Header-Element kann der Client definieren, wohin seine Anfrage oder die Antwort des Servers weitergeleitet werden soll. Wenn der Server diese Erweiterung tatsächlich unterstützt und die Eingaben nicht korrekt filtert, kann ein Angreifer den Server zwingen, beliebige Nachrichten an beliebige Server weiterzuleiten (s. Abb.6).

In der Abbildung sehen wir einen Client, der von außen nur Zugriff auf den Server A hat. Den Server B kann er von außen nicht erreichen. Er möchte aber seine Nachrichten an diesen Server schicken. Dies kann er damit erzielen, in dem er ein neues To-Element definiert, das die Adresse von Server B beinhaltet. Wenn so eine Anfrage am Server A ankommt, wird sie an den Server B weitergeleitet. So kann der Angreifer beispielsweise einen DoS-Angriff direkt auf den Server B ausführen. Eine weitere Möglichkeit ist es, dass der Angreifer mehrere SOAP-Nachrichten mit unterschiedlichen Adressen an den Server A schickt. Damit kann er die interne Netzwerkinfrastruktur und IP-Adressen scannen. Dieser Angriff wird auch WS-Addressing Spoofing genannt [2].

Gegenmaßnahmen: In einigen Frameworks ist WS-Addressing leider standardmäßig aktiviert. Daher empfehlen wir immer explizit zu überprüfen, ob dieses Feature aktiviert ist und es ggf. abzuschalten.

Signierte Nachrichten Richtig Fälschen: mit XML Signature Wrapping

XML-Signaturen erlauben es, beliebige Inhalte zu signieren und damit die Authentizität und Integrität zu schützen. Im Folgenden werden wir XML Signature Wrapping (XSW)-Angriffe [4] vorstellen, welche es ermöglichen, signierte Dateien zu modifizieren.

XML Signatur

XML Signatur [3] definiert die Syntax und Regeln für die Erstellung und Überprüfung von XML-basierten digitalen Signaturen. Die Spezifikation ist sehr flexibel. Sie ermöglicht es, die ganze XML-Struktur, spezifische Elemente oder sogar nur den Inhalt eines Elementes zu signieren. Eine vereinfachte Struktur einer Signatur angewandt an unsere SOAP-Nachricht ist in Abb.7 skizziert.

Die dargestellte SOAP-Nachricht enthält einen "CreateUser"-Funktionsaufruf im Body-Element. Im Header-Element befindet sich die Signatur. Sie besteht aus zwei Elementen: SignedInfo und SignatureValue. In SignedInfo befindet sich eine Id-basierte Referenz auf das Body-Element. Über das Body-Element wurde ein Hash berechnet, der im DigestValue-Element gespeichert wird. Damit wird gewährleistet, dass das Body-Element nicht verändert wird. Um das SignedInfo-Element zu schützen, wird eine Signatur über das gesamte SignedInfo-Element berechnet (z. B. mit RSA) und im SignatureValue-Element gespeichert.

XML Signature Wrapping

Validierung einer XML-Signatur ist ein komplexer Prozess. Es besteht aus einer Id-basierten Dereferenzierung, XML-Kanonisierung, zweistufiger Hashwert-Berechnung und Auswertung einer Signatur. Auf der anderen Seite kann die Suche nach einer Funktion im Body-Element mit einem XML-Parser einfach umgesetzt werden. Dies führt dazu, dass Dokumente mit XML-Signaturen in der Regel in zwei Schritten bearbeitet werden: Signaturvalidierung und Funktion-Ausführung (Geschäftslogik). Die Signaturvalidierungslogik wird typischerweise als eine eigenständige Bibliothek implementiert oder mit einer XML-Firewall umgesetzt. Die Geschäftslogik wird von dem Benutzer implementiert.

Wenn Dokumente in zwei unabhängigen Schritten bearbeitet werden, besteht die Gefahr durch XSW-Angriffe. Ziel des Angreifers ist es dabei, die Nachricht so zu verändern, dass die Signaturvalidierung und die Geschäftslogik auf unterschiedliche Elemente zugreifen. Betrachten wir dafür folgende Nachricht (s. Abb.8).

Nehmen wir an, dass der Angreifer eine signierte Nachricht abgefangen hat, mit welcher ein neuer Benutzer erstellt wird. Sein Ziel ist es, eine andere Funktion auszuführen, so dass er Admin-Rechte kriegt. Er geht dabei wie folgt vor. Zuerst erstellt er ein Wrapper-Element in einem Nachrichten-Teil, der von der Geschäftslogik nicht benutzt wird, z. B. im Header-Element. Danach kopiert er das signierte Body-Element mit seinem Inhalt in das Wrapper-Element. Da das verschobene Body-Element immer noch dereferenziert werden kann (das Id-Attribut ist gleich geblieben) und da es auch valid ist (der Hashwert über dieses Element ist gleich geblieben), kann es von der Signaturlogik immer noch erfolgreich validiert werden. Damit hat sich der Angreifer einen Platz für ein neues Element erschaffen. Er kann also ein neues Body-Element mit einer neuen Funktion AddAdminRights hinzufügen.

Diese Nachricht wird anschließend auf dem Server wie folgt verarbeitet: Der Server validiert zuerst die Signatur über das Element mit Id="body". Obwohl dieses Element momentan im Header-Element steht, kann es erfolgreich validiert werden. Anschließend evaluiert die Geschäftslogik das SOAP-Body-Element. Die Geschäftslogik findet hier die Funktion AddAdminRights und führt diese aus. Damit hat sich der Angreifer Admin-Rechte zugeteilt.

Gegenmaßnahmen: Es existieren mehrere Methoden, XSW-Angriffe zu verhindern. Welche Methode am besten geeignet ist, hängt vom Szenario und den eingesetzten Bibliotheken ab. Grundsätzlich muss aber mit der eingesetzten Gegenmaßnahme gewährleisten sein, dass die Signaturvalidierung und die Geschäftslogik dieselben Daten bearbeiten [5, 6, 7].

Anwendung auf Cloud und Single Sign-On-Schnittstellen

XML-Signaturen sind in verschiedenen kritischen Szenarien und Frameworks angewendet. Unser Ziel war es, ihre Robustheit gegenüber XSW-Angriffen zu analysieren. Im Jahre 2011 waren wir zum ersten Mal fündig, als wir verschiedene Cloud-Management-Schnittstellen untersucht haben [5]. Mit den Management-Schnittstellen können Benutzer ihre virtuellen Maschinen starten und stoppen, neue virtuelle Maschinen hochladen oder Rechte verwalten. In unserer Analyse haben wir uns auf Amazon und Eucalyptus Clouds konzentriert. Beide Cloud-Systeme waren auf XSW-Angriffe anfällig. Somit konnte ein Angreifer eine einzige abgefangene Nachricht benutzen, um eine vollständige Kontrolle über Cloud-Instanzen des Opfers zu bekommen.

Im Jahre 2012 untersuchten wir die Anwendung der XSW-Angriffe auf SAML-basierte Single Sign-On-Systeme [6]. In SAML wird mit einer XML-Signatur das Authentifizierungs-Token geschützt. Wenn die Signatur also gefälscht werden kann, kann dieses Token beliebig manipuliert werden: der Benutzer oder der Ablauf des Tokens können verändert werden. Unsere Studie hat ergeben, dass elf von 14 untersuchten Systemen gegen XSW-Angriffe anfällig waren. Der Angreifer konnte damit z. B. seine Tokens fälschen und sich als beliebiger Benutzer bei diesen Systemen ausgeben.

Komplette Liste der analysierten Systeme

Systeme / Frameworks Anfällig gegen XSW-Angriffe
Apache Axis2 x
Guanxi x
Higgins x
IBM Datapower x
JOSSO x
Windows Identity Foundation -
OIOSAML (Danish eGovernment) x
OpenAM x
OneLogin x
OpenAthens (UK Federation) -
OpenSAML (Shibboleth, SuisseID) x
Salesforce x
SimpleSAMLphp -
WSO2 x

Die neueste Studie der Ruhr-Universität Bochum zeigt, dass XSW-Angriffe immer noch ein Problem darstellen [8]. In der Studie wurden 22 Software-as-a-Service-Systeme untersucht, davon war eine Hälfte auf XSW-Angriffen anfällig. Zusätzlich zu XSW-Angriffen stellt diese Studie auch weitere Gefahren vor, die beim Einsatz von SAML zu betrachten sind: XML Signature exclusions, Angriffe mit XSLT oder Certificate injections.

Alles Automatisiert Testen: mit WS-Attacker

Wir haben jetzt einen Auszug der wichtigsten Angriffe im Webservice und Single Sign-On Bereichen dargestellt. Es stellt sich natürlich die Frage, wie man so viele Angriffe am besten testen kann. Gängige Tools wie OWASP ZAP oder Burp Suite bieten leider nur Tests von typischen Web-Angriffen an. SoapUI, ein Tool für Webservices, bringt nur grundlegende Sicherheitstests mit.

Aus diesem Grund haben wir uns für die Entwicklung eines neuen Tools entschieden: WS-Attacker [9]. WS-Attacker konzentriert sich auf Webservice-spezifische Angriffe. Um das wichtige Thema der Webservice-Sicherheit zu fördern, wurde WS-Attacker als Open Source veröffentlicht [14].

Im Folgenden geben wir einen kurzen Überblick über einen Test-Ablauf mit WS-Attacker. Wir gehen davon aus, dass wir einen Webservice zur Verfügung haben, welcher uns in Form von einer WSDL-Datei Information zur Nachrichtenstruktur gibt. Darüber hinaus verfügen wir über eine valide signierte SOAP-Nachricht.

Die Evaluierung des Webservices besteht aus drei Phasen. In der ersten Phase laden wir mit WS-Attacker die WSDL-Datei. Damit weiß WS-Attacker, wohin die SOAP-Nachrichten geschickt werden sollten und welche SOAP-Version der Webservice unterstützt. Anschließend schicken wir an den Webservice die zur Verfügung stehende SOAP-Nachricht. Somit haben wir WS-Attacker initialisiert. In der zweiten Phase fahren wir mit der Konfiguration der Angriffe fort. Wie in Abb.9 zu sehen ist, haben wir uns für WS-Addressing Spoofing, einige DoS-Angriffe und den XSW-Angriff entschieden.

Die meisten der ausgewählten Angriffe sind automatisch vorkonfiguriert und direkt einsatzbereit.

Bei dem XSW-Angriff müssen wir lediglich den neuen Payload definieren (hier: "Hello attack"), mit dem der originale Payload ersetzt werden soll. In der letzten Phase können wir die eingestellten Angriffe ausführen. Nach kurzer Zeit können wir sehen, dass der getestete Webservice auf den vorgestellten XSW-Angriff und drei DoS-Angriffe anfällig ist (s. Abb.10).

Zusätzlich zu den erwähnten Angriffen beinhaltet die neueste WS-Attacker-Version Angriffe auf XML Encryption [10]. Die Angriffe erlauben es, verschlüsselte Nachrichten zu entschlüsseln [7, 11, 12]. Eine detaillierte Dokumentation zu den erwähnten Angriffen kann auf Sourceforge gefunden werden [15]. Praktische Beispiele zum Testen von Webservices können vom Blog unseres Lehrstuhls entnommen werden [13].

Fazit

Webservices und Single Sign-On sind neue Technologien, die auch neue Angriffe und Herausforderungen mit sich bringen. Entwickler sollten über diese Probleme geschult werden und ihre Schnittstellen sicherheitsbewusst entwickeln und testen. Obwohl WS-Attacker nicht alle Angriffe erkennen kann – wie jedes Penetrationstest-Tool – können damit sehr schnell die wichtigsten Probleme entdeckt werden.

Quellen

[1] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler and F. Yergeau (2008): Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C Recommendation
[2] WS-Attacks.org
[3] D. Eastlake, J. Reagle, D. Solo, F. Hirsch and T. Roessler (2008): XML Signature Syntax and Processing (Second Edition). W3C Recommendation
[4] M. McIntosh and P. Austel (2005): XML signature element wrapping attacks and countermeasures. In Workshop on Secure Web Services, New York, USA
[5] J. Somorovsky, M. Heiderich, M. Jensen, J. Schwenk, N. Gruschka and L. Lo Iacono (2011): All Your Clouds Are Belong to Us – Security Analysis of Cloud Management Interfaces. In The ACM Cloud Computing Security Workshop (CCSW)
[6] J. Somorovsky, A. Mayer, J. Schwenk, M. Kampmann and M. Jensen (2012): On Breaking SAML: Be Whoever You Want to Be. In 21st USENIX Security Symposium, Bellevue, WA
[7] J. Somorovsky (2013): On the Insecurity of XML Security. Doctoral Dissertation
[8] C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW)
[9] C. Mainka, J. Somorovsky, J. Schwenk (2012): Penetration Testing Tool for Web Services Security. IEEE Services Workshop on Security and Privacy
[10] D. Eastlake, J. Reagle, F. Hirsch, T. Roessler, T. Imamura, B. Dillaway, E. Simon, K. Yiu and M. Nystrom (2013): XML Encryption Syntax and Processing 1.1. W3C Recommendation
[11] T. Jager, S. Schinzel and J. Somorovsky (2012). Bleichenbacher’s attack strikes again: breaking PKCS#1 v1.5 in XML Encryption. In European Symposium on Research in Computer Security (ESORICS), Pisa, Italy
[12] T. Jager and J. Somorovsky (2011): How To Break XML Encryption. In The 18th ACM Conference on Computer and Communications Security (CCS)
[13] On Web-Security and -Insecurity
[14] WS-Attacker
[15] Sourceforge: WS-Attacker

Autor

Dr. Juraj Somorovsky

Dr. Juraj Somorovsky ist ein Mitbegründer von 3curity GmbH, welche Penetrationstests, Schulungen und Sicherheitsanalysen in Bereichen Web, Web Services und Single Sign-On anbietet. Darüber hinaus arbeitet er als...
>> Weiterlesen
botMessage_toctoc_comments_9210