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 5984 aktiv ist und direkt über HTTP erreichbar ist.
Server-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: