rahulreddykarne/cve-2026-57836-confluent_kafkaVerifica 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 durante la costruzione del suo , disabilitando la verifica del certificato TLS per le connessioni HTTPS a Vault effettuate tramite le regole di crittografia dei campi dello Schema Registry.
verify=Falsehvac.ClientIl 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 del bundle CA o 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 crittografia 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
nonché 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 crittografia 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 di applicazione 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à.
| Modalità | Descrizione |
|---|---|
cert | Genera un certificato autofirmato e una chiave per il Vault mock locale. |
server | Avvia il Vault HTTPS mock su https://localhost:8443 e mostra le richieste ricevute. |
control | Controllo sicuro utilizzando verify=True; dovrebbe rifiutare il certificato autofirmato con CERTIFICATE_VERIFY_FAILED. |
token | Carica il HcVaultKmsClient vulnerabile e dimostra che accetta il certificato non attendibile. |
approle | Esercita il percorso di autenticazione AppRole vulnerabile e dimostra l'esposizione di role_id e secret_id. |
Installa le dipendenze del PoC:
pip install hvac cryptography
Posiziona il wheel vulnerabile scompattato accanto al PoC:
confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
└── schema_registry/
└── ...
Il PoC importa HcVaultKmsClient direttamente dal pacchetto 2.14.2 scompattato.
Esso sostituisce dipendenze non correlate come tink, consentendo di testare la costruzione vulnerabile del client Vault senza richiedere un ambiente Kafka o KMS completo.
Usa due terminali.
python poc_confluent_kafka.py server
Il Vault HTTPS mock ascolta su:
https://localhost:8443
utilizzando un certificato autofirmato.
Per prima cosa dimostra che una corretta validazione del certificato rifiuta il server autofirmato:
python poc_confluent_kafka.py control
Risultato atteso:
EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert
Esegui:
python poc_confluent_kafka.py token
Il HcVaultKmsClient vulnerabile si connette nonostante il server presenti un certificato non attendibile.
Il server mock può osservare il token Vault:
GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace
Esegui:
python poc_confluent_kafka.py approle
Il Vault mock riceve:
POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}
Il contrasto tra la modalità sicura control e le modalità vulnerabili token / approle dimostra che il comportamento deriva dal valore codificato in modo fisso:
verify=False
e non dall'ambiente di test.
La correzione sicura di base consiste nel consentire a hvac di eseguire la verifica del certificato:
hvac.Client(
url=vault_url,
token=token,
namespace=ns
)
Poiché la verifica TLS è abilitata per impostazione predefinita, disabilitarla esplicitamente non è necessario.
Un'implementazione robusta dovrebbe:
Abilitare la verifica del certificato TLS per impostazione predefinita.
Supportare un bundle CA configurabile, ad esempio:
ssl.ca.location
VAULT_CACERT
Supportare i certificati client per ambienti che utilizzano mutual TLS.
Impedire che un valore di configurazione vuoto o falso disabiliti silenziosamente la verifica del certificato.
Aggiungere test di regressione che confermino che i certificati autofirmati e altrimenti non attendibili vengono rifiutati per impostazione predefinita.
La vulnerabilità è corretta in:
confluent-kafka 2.15.0
Le versioni interessate sono:
2.8.0
through
2.14.2
Nella 2.15.0, il comportamento del client Vault è stato modificato in modo che la verifica TLS sia abilitata per impostazione predefinita.
L'implementazione aggiornata introduce anche una configurazione relativa al TLS, inclusa:
ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location
Ciò consente alle distribuzioni che utilizzano un'infrastruttura PKI privata di fornire una configurazione CA attendibile e di certificato client senza disabilitare la verifica del certificato.
La vulnerabilità è valutata:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Punteggio CVSS 3.1: 7.4 — Alta
AV:N — Network
La comunicazione Vault vulnerabile avviene su una connessione di rete.
AC:H — High Attack Complexity
L'attaccante deve ottenere una posizione MITM sulla rete o altrimenti reindirizzare la connessione Vault.
Questo è un prerequisito significativo ed è il motivo per cui la vulnerabilità è valutata Alta anziché Critica.
PR:N — No Privileges Required
L'attaccante non richiede privilegi all'interno dell'applicazione interessata.
UI:N — No User Interaction
Non è richiesta alcuna interazione dell'utente dopo che l'attaccante ottiene la posizione di rete necessaria.
S:U — Scope Unchanged
L'impatto rimane all'interno dell'autorità di sicurezza dell'applicazione interessata e della sua interazione con Vault.
C:H — High Confidentiality Impact
I token Vault o le credenziali AppRole possono essere esposti all'attaccante.
I:H — High Integrity Impact
L'attaccante può impersonare Vault e restituire risposte Vault/KMS contraffatte.
A:N — No Availability Impact
Non è stato dimostrato alcun impatto diretto sulla disponibilità.
2.8.0 alla 2.14.22.15.0Il valore codificato in modo fisso verify=False è esistito dall'introduzione dell'integrazione HCVault fino alla versione 2.14.2.
Il comportamento di sicurezza è stato corretto nella 2.15.0.
YYYY-MM-DD — Segnalato a Confluent.2.15.0.Scoperto e segnalato da Rahul Karne.
confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka su PyPI
https://pypi.org/project/confluent-kafka/
Client Python hvac di HashiCorp
https://hvac.readthedocs.io/
Autenticazione AppRole di HashiCorp Vault
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — Validazione del certificato impropria
https://cwe.mitre.org/data/definitions/295.html
Documentazione sulla verifica TLS / certificati di Python
https://docs.python.org/3/library/ssl.html#ssl-security
Questo repository documenta una scoperta di sicurezza in divulgazione coordinata e fornisce un proof of concept innocuo e autonomo.
Il PoC opera interamente contro un server Vault mock locale utilizzando credenziali fittizie.
Non interagisce con HashiCorp Vault, Kafka, Schema Registry, infrastrutture di produzione o credenziali reali.
Il materiale è fornito per la ricerca sulla sicurezza difensiva e scopi educativi.
Richieste dei media: [email protected]. PoC completo (server dell'attaccante, archivio di traversal, applicazione vittima) e ulteriori dettagli tecnici disponibili su richiesta.