dungsocool/cve-2019-20933Report dettagliato di laboratorio passo-passo che dimostra l'elusione dell'autenticazione di InfluxDB tramite token JWT falsificati (CVE-2019-20933), includendo sfruttamento, post-sfruttamento e linee guida per la correzione.
Iniziando con ciò che è in esecuzione nell'ambiente. Elenco tutti i container attivi:
docker ps
La vittima espone una singola porta: 8086.
Attualmente, non ho informazioni dettagliate sul target. Dall'output di docker ps, il sistema espone solo un servizio notevole esternamente sulla porta 8086, che è mappata al servizio all'interno del container. Questa è la superficie d'attacco principale da analizzare.
Invece di accedervi immediatamente tramite browser, procediamo a identificare il servizio usando Nmap per determinare quale servizio è in esecuzione sulla porta 8086:
nmap -sV -sC -p 8086 192.168.3.137
I risultati della scansione mostrano che la porta 8086 è il servizio HTTP di InfluxDB OSS 1.6.6. Questo è un database time-series esposto tramite un'API HTTP, non una tipica applicazione web.
InfluxDB è un database time-series open-source scritto in Go. A differenza di RDBMS (ottimizzato per transazioni precise) o Elasticsearch (ottimizzato per ricerca testuale), InfluxDB è stato creato con un unico scopo: Gestire volumi massivi di scrittura (Alto Throughput di Scrittura) e interrogare i dati lungo l'asse temporale con bassa latenza.
Poiché il servizio è stato identificato come InfluxDB, il passo successivo è fare riferimento a come InfluxDB comunica con i client. Secondo la documentazione dell'API HTTP InfluxDB v1, la porta 8086 è la porta API HTTP predefinita. Gli endpoint importanti includono:
/ping: verifica lo stato operativo del server./query: invia interrogazioni InfluxQL per leggere metadati o dati./write: scrive dati time-series nel database.⇒ Riflessione: Dopo che Nmap identifica il servizio come InfluxDB http admin 1.6.6, non continuiamo a testarlo come un sito web standard. Per le applicazioni web, cerchiamo tipicamente rotte, moduli di login o directory. Tuttavia, con InfluxDB, la superficie d'attacco risiede nell'API HTTP. Pertanto, dobbiamo passare al test degli endpoint API standard di InfluxDB per determinare se l'API richiede autenticazione. Di conseguenza, la prossima direzione di test non è accedere a / tramite browser, ma inviare richieste direttamente agli endpoint API di InfluxDB.
/pingDopo aver identificato la porta 8086 come API HTTP di InfluxDB, verifica l'endpoint /ping per confermare che il servizio sia operativo:
curl -i <http://192.168.3.137:8086/ping>
Risposta 204 No Content conferma che InfluxDB funziona normalmente. Le intestazioni confermano inoltre la versione del servizio come InfluxDB OSS 1.6.6
/querycurl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"
L'endpoint /query non consente interrogazioni dirette senza credenziali di autenticazione. Ciò conferma che InfluxDB ha l'autenticazione abilitata e blocca tutte le interrogazioni anonime inviate al sistema.
Passo a riflettere: la versione 1.6.6 di InfluxDB ha qualche vulnerabilità che permette di bypassare il meccanismo di autenticazione?
Consultando i database pubblici delle vulnerabilità, le versioni di InfluxDB precedenti alla 1.7.6 sono affette da CVE-2019-20933. Si tratta di una vulnerabilità di Bypass dell'Autenticazione nella funzione di autenticazione di InfluxDB, relativa alla gestione dei token JWT con un segreto condiviso vuoto.
Poiché il target esegue InfluxDB 1.6.6, che è inferiore alla versione corretta 1.7.6, il servizio rientra nell'intervallo di versioni affette.
Si può concludere:
| Servizio | InfluxDB OSS |
|---|---|
| Versione | 1.6.6 |
| Autenticazione | Abilitata |
| Mappatura CVE | CVE-2019-20933 |
| Impatto | Bypass dell'Autenticazione |
| Stato | Versione vulnerabile |
⇒ Riflessione: Inizialmente, l'endpoint /query restituisce 401 Unauthorized, indicando che il meccanismo di autenticazione è attivo. Tuttavia, avere l'autenticazione abilitata non significa sicurezza assoluta. Quando la versione è identificata come 1.6.6, dobbiamo correlarla con CVE noti. I risultati indicano che questa versione rientra nell'intervallo affetto da CVE-2019-20933, il che significa è possibile bypassare il meccanismo di autenticazione che protegge l'endpoint /query. Sulla base di questi risultati di identificazione, la fase di sfruttamento si concentrerà sulla verifica di CVE-2019-20933 generando un token JWT appropriato per bypassare l'autenticazione ed eseguire interrogazioni sull'endpoint /query.
La vulnerabilità CVE-2019-20933 si verifica nella funzione authenticate all'interno del file services/httpd/handler.go di InfluxDB precedente alla versione 1.7.6.
InfluxDB supporta l'autenticazione utilizzando JSON Web Token (JWT) per le richieste API HTTP. Quando riceve una richiesta con l'intestazione:
Authorization: Bearer <token>
InfluxDB eseguirà i seguenti passaggi:
shared-secret dal file influxdb.conf per fungere da chiave segreta per la verifica della firma del token.username dai claims per determinare l'utente che esegue l'interrogazione.Nelle versioni affette, se l'autenticazione JWT è abilitata ma il parametro shared-secret non è configurato, il valore segreto potrebbe essere elaborato come stringa vuota ("").
Il sistema non riesce a validare adeguatamente la robustezza del segreto prima di verificare la firma del JWT. Ciò consente a un attaccante di costruire un JWT personalizzato, firmarlo con un segreto vuoto e quindi impostare il claim username su un account valido nel sistema, come admin se questo account esiste nel laboratorio.
Quando questo token viene inviato tramite l'intestazione Authorization: Bearer <token>, InfluxDB utilizza lo stesso segreto vuoto per verificare la firma. Se la firma corrisponde e il nome utente esiste, la richiesta sarà autorizzata senza richiedere la password effettiva dell'utente.
Il flusso di elaborazione può essere riassunto come segue: