© CapturePB/Shutterstock.com
Wie sicher ist SOAP? Und wie kann man es absichern?

Sicherheit und Seife


SOAP war früher die Abkürzung für Simple Object Access Protocol; heutzutage wird diese aber nicht mehr verwendet, denn SOAP ist gar nicht so „Simple“ und auf keinen Fall nur auf Objektzugriffe beschränkt. Wenn etwas nicht einfach ist, wird es schnell zur Gefahrenquelle: Entweder weil die Implementierungen Schwachstellen aufweisen oder eine sichere Nutzung unnötig erschwert wird. Wie sieht es denn da bei SOAP aus?

SOAP gilt dem Austausch von Daten und dem Durchführen von Remote Procedure Calls (RPC, entfernte Prozeduraufrufe), ursprünglich nur zwischen verschiedenen Servern, inzwischen auch zwischen Client und Server. SOAP stützt sich auf verschiedene andere Standards: XML für die Repräsentation der Daten und Internetprotokolle (vor allem HTTP) für ihren Austausch.

Eins seiner Haupteinsatzgebiete ist die Kommunikation zwischen Web Services, und im Rahmen von Webanwendungen wird es meist für die Kommunikation zwischen verschiedenen Backend-Komponenten verwendet. Aber auch für die Konfiguration von Netzwerkgeräten wird teilweise SOAP für die Kommunikation verwendet.

Einige Beispiele für Schwachstellen und Angriffe

Im November 2016 wurde eine Schwachstelle in den DSL-Routern des irischen Providers Eir gefunden [1]. Die Router öffneten einen Port für das Fernwartungsprotokoll TR-069, der auch für das damit verwandte Protokoll TR-064 genutzt wird. Und das sollte eigentlich nur aus dem lokalen Netz zugänglich sein, da über dessen SOAP-Schnittstelle ohne Authentifizierung die DNS- und NTP-Konfiguration der Geräte geändert werden kann.

2016: Angriff auf Telekom-Router

Nun ist Irland ziemlich weit weg und Schwachstellen in den dortigen DSL-Routern sind hier in Deutschland erst mal ziemlich uninteressant. Aber nur, bis ein Cyberkrimineller versucht, die Schwachstelle auch hier auszunutzen – probieren kann man es ja mal, die Provider bauen und/oder programmieren ihre Router ja nicht selbst, sondern kaufen sie irgendwo ein. Da ist es gar nicht mal so unwahrscheinlich, dass die in mehr als einem Land und/oder von mehr als einem Provider genutzt werden. Wenig später kam es zu einer großflächigen Störung im Telekom-Netz: Ein Cyberkrimineller hatte den Proof of Concept für die Schwachstelle in den irischen Routern mit dem Code des Mirai-Botnets kombiniert und auf das Telekom-Netz losgelassen. Dort kam es allerdings nicht zur Infektion der Router, stattdessen fielen sie aus [2].

Nicht SOAP, sondern der aus dem Internet zugängliche Port für die Fernwartung war hier das Problem. SOAP diente nur dem Transport des Exploits. So auch im folgenden Beispiel.

2015: Schwachstelle in Netgear-Routern

Im Februar 2015 wurde eine Schwachstelle in Netgear-Routern entdeckt [3]: Die Router stellen ein SOAP-Interface bereit, über das die Webadministrationsoberfläche der Konfigurationssoftware „Genie“ Informationen über das lokale Netzwerk und den Router abfragen kann, wie z. B. Passwörter und den WLAN-Schlüssel. Das Interface sollte auf unberechtigte Anfragen eigentlich mit einem 401-HTTP-Fehler antworten, der Schutz ließ sich allerdings umgehen. Und da das SOAP-Interface auch aus dem Internet zugänglich war, waren Angriffe von dort aus möglich.

2015: Schwachstelle in Windows Server Update Services (WSUS)

Paul Stone und Alex Chapman haben auf der Black Hat USA 2015 unter dem Titel „WSUSpect – Compromising the Windows Enterprise via Windows Update“ Angriffe auf die Windows Server Update Services (WSUS) vorgestellt [4].

Windows Update dient Microsoft dazu, Updates für Betriebssysteme und Anwendungen zu verteilen. Dazu führen die Windows Update Services in regelmäßigen Abständen das Programm wuauctl.exe aus, das über das Internet bei Windows Update nach neuen Updates für das System und die installierte Hardware fragt. wuauctl.exe wird über Registry-Einträge konfiguriert; z. B. wird so festgelegt, woher Updates heruntergeladen werden, wie oft nach neuen Updates gesucht wird, ob Nicht-Admins höhere Rechte bekommen sollen oder nicht und vieles mehr [5].

Die Kommunikation zwischen wuauctl.exe und den Windows-Update-Servern erfolgt über einen SOAP Web Service über HTTPS. Beim Fragen nach neuen Updates sendet die Anwendung eine vollständige Liste der installierten Updates an den Windows-Update-Server, der mit einer Liste der verfügbaren Updates antwortet.

Die Windows Server Update Services agieren als Proxy zu Microsofts öffentlichem Windows Update Service. Die WSUS holen die Updates über das Internet vom Windows Update Service und speichern sie lokal. Die Rechner im Intranet holen ihre Updates dann nicht vom öffentlichen Microsoft-Server, sondern vom lokalen WSUS-Server. Die Administratoren haben dadurch eine bessere Kontrolle darüber, wie Updates in ihrem Netz ausgerollt werden.

WSUS verwenden, wie Windows Update auch, SOAP-Aufrufe und die Protokolle sind abgesehen von der Authentisierung identisch [6].

Per Default verwenden WSUS für den SOAP Web Service kein SSL, sondern normales HTTP über Port 8530. Im letzten Schritt des Installations-Wizards wird der Admin aber aufgefordert, SSL zu konfigurieren. Dazu muss nur ein Zertifikat für den WSUS-Server installiert und die Nutzung von HTTPS für die Suche nach Updates auf den Clients eingeschaltet werden.

Alle von Windows Update heruntergeladenen Updates sind von Microsoft signiert. Vor der Installation der Updates wird die Signatur geprüft, nicht von Windows signierte Pakete werden bei der Nutzung von WSUS zurückgewiesen. Während die signierten Updatedateien nicht manipuliert werden können, ohne die Signatur ungültig zu machen, kann ein Angreifer die Updatemetadaten nach Belieben manipulieren und sogar Fake-Updates erstellen. Indem ein Angreifer ein Update einschleust, das den CommandLineInstallation-Update-Handler verwendet, kann er den Client dazu bringen, jedes beliebige von Microsoft signierte Programm zu starten, auch wenn es gar nicht dafür vorgesehen war, von Windows Update genutzt zu werden. Außerdem kann er dem Programm beliebige Argumente übergeben. So sind beispielsweise Microsofts Sysinternals-Tools signiert und das Utility PsExec, mit dem normalerweise Befehle auf entfernten Systemen ausgeführt werden, kann auch verwendet werden, um lokal Befehle als der aktuelle Benutzer auszuführen. Die beiden Forscher konnten als Man in the Middle (MitM) in einer WSUS-Verbindung ein Update einschleusen, das PsExec verwendet, um über die zugehörigen Metadaten beliebige Befehle auf dem Client auszuführen. Eine ausführlichere Beschreibung finden Sie im Windows Developer 1.17 [7].

Und d...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang