Verifica del certificato TLS disabilitata per HashiCorp Vault KMS in confluent-kafka
Gravità: Alta, CVSS 3.1 7.4
Vettore (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Interessato: confluent-kafka >= 2.8.0, <= 2.14.2
Corretto in: 2.15.0
CWE: CWE-295 (Validazione del certificato impropria)
Componente: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Segnalato da: Rahul Karne
CNA: VulnCheck
Il client HashiCorp Vault KMS in confluent-kafka codifica in modo fisso verify=False durante la costruzione del suo hvac.Client, disabilitando la verifica del certificato TLS per le connessioni HTTPS a Vault effettuate tramite le regole di cifratura dei campi dello Schema Registry.
Il codice vulnerabile si trova in:
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Il client interessato viene inizializzato come segue:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Poiché verify=False è incondizionato, il client accetta certificati TLS non attendibili, inclusi certificati autofirmati o controllati da un attaccante.
Un attaccante posizionato sulla rete in grado di intercettare o reindirizzare il traffico Vault dell'applicazione può impersonare il server Vault, catturare le credenziali di autenticazione Vault e restituire risposte Vault/KMS contraffatte.
L'integrazione HCVault interessata espone la configurazione per token Vault, namespace e credenziali AppRole, ma le versioni interessate non forniscono alcuna configurazione supportata per il bundle CA o un meccanismo equivalente per ripristinare la verifica del certificato.
Un attaccante con una posizione di man-in-the-middle sulla rete tra l'applicazione e HashiCorp Vault può:
X-Vault-Tokenrole_idsecret_idCiò può compromettere la riservatezza e l'integrità dei dati protetti dal flusso di lavoro KMS basato su Vault.
confluent-kafka è il client Python ufficiale di Confluent per Apache Kafka.
La vulnerabilità interessa specificamente le distribuzioni che utilizzano:
Schema Registry encryption rules
↓
HCVault KMS integration
↓
hcvault:// key URI
La popolazione interessata è quindi più ristretta rispetto a tutti gli utenti di confluent-kafka.
Tuttavia, la funzionalità interessata è sensibile alla sicurezza perché queste distribuzioni si affidano a HashiCorp Vault per la gestione delle chiavi crittografiche e la cifratura a livello di campo.
HcVaultKmsClient.__init__() analizza un URI di chiave hcvault://, determina l'URL di base di Vault e crea un hvac.Client.
Nelle versioni interessate, inclusa la 2.14.2, il codice rilevante è:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
if role_id and secret_id and self._client is not None:
self._client.auth.approle.login(
role_id=role_id,
secret_id=secret_id
)
La libreria hvac si basa in ultima analisi sullo stack TLS di requests di Python.
Impostare:
verify=False
indica al client di non validare il certificato TLS del server remoto.
Di conseguenza, i certificati che normalmente verrebbero rifiutati possono essere accettati, inclusi certificati che sono:
Ciò interessa entrambi i percorsi di autenticazione supportati.
Quando viene utilizzata l'autenticazione tramite token, il token Vault viene inviato attraverso l'header HTTP:
X-Vault-Token
Se un attaccante riesce a impersonare l'endpoint Vault, il server controllato dall'attaccante può ricevere questo token.
Quando viene utilizzata l'autenticazione AppRole, il client invia:
role_id
secret_id
a:
/v1/auth/approle/login
Un MITM riuscito può quindi catturare entrambe le credenziali AppRole.
Il driver HCVault interessato legge la configurazione inclusa:
token.id
namespace
approle.role.id
approle.secret.id
così come le variabili d'ambiente VAULT_* rilevanti.
Tuttavia, le versioni interessate non espongono una configurazione che consenta agli operatori di:
Di conseguenza, le applicazioni che utilizzano l'integrazione interessata non possono ripristinare la verifica TLS tramite la normale configurazione del pacchetto.
Il pacchetto disabilita esplicitamente la verifica del certificato del server TLS invece di affidarsi all'impostazione predefinita sicura.
La costruzione vulnerabile è effettivamente:
hvac.Client(..., verify=False)
anziché:
hvac.Client(..., verify=True)
o semplicemente:
hvac.Client(...)
dove la verifica è abilitata per impostazione predefinita.
Disabilitare la verifica del certificato rimuove l'autenticazione del server dalla connessione TLS.
Sebbene la connessione rimanga cifrata, il client non ha un meccanismo affidabile per determinare se sta comunicando con il server Vault legittimo.
Ciò crea la condizione necessaria per un attacco man-in-the-middle sulla rete.
Lo sfruttamento riuscito richiede:
L'applicazione utilizza una versione interessata di confluent-kafka:
2.8.0 alla 2.14.2.L'applicazione utilizza le regole di cifratura dello Schema Registry con l'integrazione HCVault KMS.
La chiave KMS configurata utilizza lo schema:
hcvault://
Esempi possibili includono:
Non sono richiesti privilegi a livello applicativo né interazione della vittima una volta che esiste la posizione MITM necessaria.
poc_confluent_kafka.py dimostra il problema contro un wheel confluent-kafka 2.14.2 scompattato localmente.
Il PoC utilizza:
HcVaultKmsClient.Il proof of concept contiene cinque modalità.