Sicherheitslücken in SOAP Web Services aufdecken

Welche Risiken bietet XML? – Blogserie – Teil #04

Wie bereits in dem letzten Beitrag dieser Serie soll es auch hier erneut um das Finden von Sicherheitslücken bei der Verarbeitung von XML gehen. Dieses Mal steht das SOAP Protokoll [1] – von dem wir bereits berichtet haben – im Fokus der Untersuchung. SOAP wird häufig mittels des WS-Security Standards [2] abgesichert. Im Allgemeinen definiert WS-Security spezielle SOAP-Header, die es erlauben, den Inhalt (Body) zu signieren und/oder zu verschlüsseln. In diesem Beitrag untersuchen wir die Beispiel-Clients und -Server, die von dem Apache Rampart [3] Projekt zur Verfügung gestellt werden. Wir analysieren diese mittels des Tools WS-Attacker, das von Hackmanit mitentwickelt wurde.

Einrichtung der Testumgebung

Um selbst die Schritte der Sicherheitsanalyse nachzuverfolgen, oder um selber Angriffe auszuprobieren, können Sie die Rampart Beispiel-Webserver mittels der folgenden Schritte herunterladen und starten; die Server sind anschließend unter localhost:8080 erreichbar. Wenn Sie nicht selbst Hand anlegen möchten, können Sie diesen Abschnitt überspringen.

1. Docker installieren und einrichten.
2. Das https://github.com/RUB-NDS/WS-Attacker klonen oder jdk herunterladen und entpacken.
3. In dem heruntergeladenen Order die folgenden Befehle in der Konsole ausführen:

    Dies führt den Server für Beispiel 02 aus. Die entsprechenden Anfragen eines Clients können mit

    ausgeführt werden. Wenn alles korrekt aufgesetzt ist sollte am Ende ein

 BUILD SUCCESSFUL

    stehen.

4. Java Development Kit 7 oder 8 installieren und einrichten.
5. Im ws-attacker Ordner folgenden Befehl ausführen um WS-Attacker zu starten:

    Wir stellen für dieses Projekt eine kompilierte Version des WS-Attacker bereit, wenn Sie auf dem neuesten Stand sein möchten, kann es sich lohnen, das Tool selber zu kompilieren. Alle Informationen dazu finden Sie auf der Projektseite des WS-Attackers.

Um nun die Nachrichten, die zwischen Browser und Server ausgetauscht werden, zu sehen, kann zum Beispiel Wireshark genutzt werden. Informationen zur Einrichtung und Nutzung von Wireshark finden Sie hier.

Automatische SOAP Sicherheitsanalyse

1. WSDL Laden

Wenn WS-Attacker wie oben angegeben gestartet wird und der service.02 korrekt läuft, erkennt das Tool beim Klick auf „Load“ im „WSDL Loader“ Tab den Server und dessen Operationen. Der Pfad zu der WSDL sollte automatisch auf http://localhost:8080/axis2/services/sample02?wsdl gesetzt sein.
Die Web Services Description Language (WSDL) ist eine XML-basierte Sprache, welche die Endpunkte eines Servers und die akzeptierten Nachrichten-Typen beschreibt. Es dient dazu, alle Details einer Web API, die auf XML basiert, zu beschreiben. WS-Attacker lädt diese Datei und nutzt die hinterlegten Informationen für mögliche Angriffe.

2. Beispiel Request Laden

Damit WS-Attacker arbeiten kann, benötigen wir einen gültigen Request, den der Server akzeptiert. Um diesen zu bekommen, führen wir den Client aus und schneiden die Verbindung mit Wireshark mit. Die mitgeschnitte Verbindung sollte in etwa so aussehen wie in Abbildung 1.

Wireshark Mitschnitt einer SOAP/WS-Security Verbindung. (Abbildung 1)

Um nun den gesendeten XML Text zu erhalten, gibt es viele Möglichkeiten in Wireshark. Eine ist – wie in Abbildung 1 – den XML Request auszuwählen, dann mit der rechten Maustaste auf „eXtensible Markup Language“ zu klicken und „Copy“/„Copy Bytes as Printable Text“ auszuwählen. Sollten bei diesem Schritt Probleme auftreten, finden Sie in dem Ordner data im Repository  zu diesem Projekt die ganze Aufzeichnung und die Nachricht, die wir verwendet haben.

Der resultierende XML-Request kann nun in WS-Attacker im Reiter „Test Request“ unter „XML Request“ eingetragen werden (siehe Abbildung 2). Nachdem nun „Send“ ausgeführt wurde, wird in „XML Response“ die Antwort des Servers angezeigt.

WS-Attacker – Erfolgreicher Test Request. (Abbildung 2)

3. Angriffe Ausführen

Die verfügbaren Angriffe können im Tab „Plugin Configurator“ ausgewählt und konfiguriert werden. In diesem Beispiel wählen wir die in Abbildung 3 gezeigten Plugins aus und nehmen keine Änderung an der Konfiguration vor.

WS-Attacker – Auswahl von Angriffen. (Abbildung 3)

Wie bestimmte Angriffe ausgeführt werden, ist in der offiziellen WS-Attacker Dokumentation [4] zu finden. Dort gibt es auch weitere Quellen zu vorhandenen Angriffen und Hinweise, wie bestimmte Plugins eingerichtet werden müssen.

4. Angriffe Auswerten

Wenn alle bisherigen Schritte korrekt ausgeführt wurden, kann im Tab „Attack Overview“ die automatische Evaluierung ausgeführt werden. Die Ergebnisse für Beispiel 2 sind in Abbildung 4 zu sehen.

WS-Attacker – Ergebnisse der automatischen Sicherheitsanalyse des WS-Attackers auf Beispiel 2 der Apache Rampart Implementierung. (Abbildung 4)

Wie zu sehen ist, hat der WS-Attacker erfolgreich Schwachstellen für die Angriffe „Compression Attack“ und „XML Element Count Attack“ identifiziert. Die Beschreibungen in den Abbildungen 5 und 6 erklären, worum es sich bei diesen Angriffen handelt.

Compression Attack – Die erste der beiden Angriffe die WS-Attacker als Schwachstelle erkennen konnte. (Abbildung 5)

XML Element Count Attack – Die zweite der beiden Angriffe die WS-Attacker als Schwachstelle erkennen konnte. (Abbildung 6)

Wie geht es weiter?

Nur durch ein einfaches ausführen des WS-Attackers konnten wir zwei mögliche Sicherheitsprobleme in der Referenzimplementierung finden. Das bedeutet aber nicht, dass die Implementierung sicher gehen alle anderen Angriffe ist. Gerade die Angriffe auf die Signatur und die Verschlüsselung könnten – mit einer tiefgehenden Konfiguration – eventuell noch erfolgreich sein. Was die gefundenen Sicherheitslücken für eine Implementierung genau bedeuten muss von Fall zu Fall analysiert werden.

Mit diesem Beitrag endet die XML Blogserie, wir hoffen Ihnen die Thematik gut vermittel zu können. Eine Blogserie wie diese kann nur in einem eingeschränkten Rahmen Wissen vermitteln und Ihnen dabei weiterhelfen Ihre Systeme abzusichern. Wenn bei Ihnen Fragen offen geblieben sind zu den hier behandelten Themen, oder Sie konkrete Sicherheitsmaßnahmen implementieren oder testen möchten, können Sie sich gerne an unsere Experten auf dem Gebiet wenden. Nur durch eine tiefgehende Analyse Ihrer Systeme können wir wirklich gute Sicherheitsmaßnahmen empfehlen.

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.

Quellen

1. http://www.w3.org/TR/SOAP/ 
2. Web Services Security v1.1.1 on https://www.oasis-open.org/standards 
3. https://axis.apache.org/axis2/java/rampart/index.html
4. https://master.dl.sourceforge.net/project/ws-attacker/WS-Attacker%201.3/Documentation-v1.3.pdf

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