rahulreddykarne/cve-2026-57836-confluent_kafkaDeaktivierte TLS-Zertifikatsüberprüfung für HashiCorp Vault KMS in confluent-kafka
Schweregrad: Hoch, CVSS 3.1 7.4
Vektor (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Betroffen: confluent-kafka >= 2.8.0, <= 2.14.2
Behoben in: 2.15.0
CWE: CWE-295 (Improper Certificate Validation)
Komponente: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Gemeldet von: Rahul Karne
CNA: VulnCheck
Der HashiCorp Vault KMS-Client in confluent-kafka hardcodiert verify=False bei der Konstruktion seines , wodurch die TLS-Zertifikatsüberprüfung für Vault-HTTPS-Verbindungen deaktiviert wird, die über die Field-Encryption-Regeln der Schema Registry hergestellt werden.
hvac.ClientDer verwundbare Code befindet sich in:
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Der betroffene Client wird wie folgt initialisiert:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Da verify=False bedingungslos gesetzt ist, akzeptiert der Client nicht vertrauenswürdige TLS-Zertifikate, einschließlich selbstsignierter oder von Angreifern kontrollierter Zertifikate.
Ein Angreifer mit Netzwerkposition, der in der Lage ist, den Vault-Datenverkehr der Anwendung abzufangen oder umzuleiten, kann sich als Vault-Server ausgeben, Vault-Authentifizierungsdaten erbeuten und gefälschte Vault/KMS-Antworten zurückgeben.
Die betroffene HCVault-Integration bietet Konfigurationsmöglichkeiten für Vault-Tokens, Namespaces und AppRole-Anmeldedaten, aber betroffene Versionen bieten keine unterstützte CA-Bundle-Konfiguration oder einen gleichwertigen Mechanismus zur Wiederherstellung der Zertifikatsüberprüfung.
Ein Angreifer mit einer Man-in-the-Middle-Position im Netzwerk zwischen der Anwendung und HashiCorp Vault kann:
X-Vault-Tokenrole_idsecret_idDies kann die Vertraulichkeit und Integrität von Daten kompromittieren, die durch den Vault-gestützten KMS-Workflow geschützt sind.
confluent-kafka ist der offizielle Confluent-Python-Client für Apache Kafka.
Die Schwachstelle betrifft speziell Bereitstellungen, die Folgendes verwenden:
Schema Registry encryption rules
↓
HCVault KMS integration
↓
hcvault:// key URI
Die betroffene Nutzergruppe ist daher kleiner als alle confluent-kafka-Benutzer.
Die betroffene Funktionalität ist jedoch sicherheitskritisch, da diese Bereitstellungen auf HashiCorp Vault für kryptografisches Schlüsselmanagement und Field-Level-Verschlüsselung angewiesen sind.
HcVaultKmsClient.__init__() parst eine hcvault://-Schlüssel-URI, bestimmt die Vault-Basis-URL und erstellt einen hvac.Client.
In betroffenen Versionen, einschließlich 2.14.2, lautet der relevante Code:
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
)
Die hvac-Bibliothek stützt sich letztlich auf den TLS-Stack von Python requests.
Die Einstellung:
verify=False
weist den Client an, das TLS-Zertifikat des Remote-Servers nicht zu validieren.
Infolgedessen können Zertifikate akzeptiert werden, die normalerweise abgelehnt würden, einschließlich Zertifikaten, die:
Dies betrifft beide unterstützten Authentifizierungspfade.
Wenn Token-Authentifizierung verwendet wird, wird das Vault-Token über den HTTP-Header:
X-Vault-Token
gesendet.
Wenn ein Angreifer sich erfolgreich als Vault-Endpunkt ausgibt, kann der vom Angreifer kontrollierte Server dieses Token empfangen.
Wenn AppRole-Authentifizierung verwendet wird, sendet der Client:
role_id
secret_id
an:
/v1/auth/approle/login
Ein erfolgreicher MITM kann daher beide AppRole-Anmeldedaten erbeuten.
Der betroffene HCVault-Treiber liest Konfigurationen einschließlich:
token.id
namespace
approle.role.id
approle.secret.id
sowie relevante VAULT_*-Umgebungsvariablen.
Betroffene Versionen bieten jedoch keine Konfiguration, die es Betreibern ermöglicht:
Infolgedessen können Anwendungen, die die betroffene Integration verwenden, die TLS-Überprüfung nicht über die normale Paketkonfiguration wiederherstellen.
Das Paket deaktiviert explizit die TLS-Server-Zertifikatsüberprüfung, anstatt sich auf den sicheren Standard zu verlassen.
Die verwundbare Konstruktion ist effektiv:
hvac.Client(..., verify=False)
anstelle von:
hvac.Client(..., verify=True)
oder einfach:
hvac.Client(...)
wobei die Überprüfung standardmäßig aktiviert ist.
Das Deaktivieren der Zertifikatsüberprüfung entfernt die Server-Authentifizierung aus der TLS-Verbindung.
Obwohl die Verbindung verschlüsselt bleibt, hat der Client keinen zuverlässigen Mechanismus, um festzustellen, ob er mit dem legitimen Vault-Server kommuniziert.
Dies schafft die Voraussetzung für einen Man-in-the-Middle-Angriff im Netzwerk.
Eine erfolgreiche Ausnutzung erfordert:
Die Anwendung verwendet eine betroffene Version von confluent-kafka:
2.8.0 bis 2.14.2.Die Anwendung verwendet Schema-Registry-Verschlüsselungsregeln mit der HCVault KMS-Integration.
Der konfigurierte KMS-Schlüssel verwendet das Schema:
hcvault://
Mögliche Beispiele sind:
Sobald die erforderliche MITM-Position besteht, sind keine Berechtigungen auf Anwendungsebene oder Interaktion des Opfers erforderlich.
poc_confluent_kafka.py demonstriert das Problem gegen ein lokal entpacktes confluent-kafka 2.14.2-Wheel.
Das PoC verwendet:
HcVaultKmsClient-Implementierung.Das Proof of Concept enthält fünf Modi.
| Modus | Beschreibung |
|---|---|
cert | Generiert ein selbstsigniertes Zertifikat und einen Schlüssel für den lokalen Mock-Vault. |
server | Startet den Mock-HTTPS-Vault auf https://localhost:8443 und zeigt empfangene Anfragen an. |
control | Sichere Kontrolle mit verify=True; sollte das selbstsignierte Zertifikat mit CERTIFICATE_VERIFY_FAILED ablehnen. |
token | Lädt den verwundbaren HcVaultKmsClient und demonstriert, dass er das nicht vertrauenswürdige Zertifikat akzeptiert. |
approle | Übt den verwundbaren AppRole-Authentifizierungspfad aus und demonstriert die Offenlegung von role_id und secret_id. |
Installieren Sie die PoC-Abhängigkeiten:
pip install hvac cryptography
Platzieren Sie das entpackte verwundbare Wheel neben dem PoC:
confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
└── schema_registry/
└── ...
Das PoC importiert HcVaultKmsClient direkt aus dem entpackten 2.14.2-Paket.
Es stubbt nicht zusammenhängende Abhängigkeiten wie tink, wodurch die verwundbare Vault-Client-Konstruktion getestet werden kann, ohne eine vollständige Kafka- oder KMS-Umgebung zu benötigen.
Verwenden Sie zwei Terminals.
python poc_confluent_kafka.py server
Der Mock-HTTPS-Vault lauscht auf:
https://localhost:8443
unter Verwendung eines selbstsignierten Zertifikats.
Demonstrieren Sie zunächst, dass eine ordnungsgemäße Zertifikatsvalidierung den selbstsignierten Server ablehnt:
python poc_confluent_kafka.py control
Erwartetes Ergebnis:
EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert
Führen Sie aus:
python poc_confluent_kafka.py token
Der verwundbare HcVaultKmsClient verbindet sich, obwohl der Server ein nicht vertrauenswürdiges Zertifikat präsentiert.
Der Mock-Server kann das Vault-Token beobachten:
GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace
Führen Sie aus:
python poc_confluent_kafka.py approle
Der Mock-Vault empfängt:
POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}
Der Kontrast zwischen dem sicheren control-Modus und den verwundbaren token- / approle-Modi zeigt, dass das Verhalten aus dem hardcodierten:
verify=False
resultiert und nicht aus der Testumgebung.
Die grundlegende sichere Korrektur besteht darin, hvac die Zertifikatsüberprüfung durchführen zu lassen:
hvac.Client(
url=vault_url,
token=token,
namespace=ns
)
Da die TLS-Überprüfung standardmäßig aktiviert ist, ist eine explizite Deaktivierung unnötig.
Eine robuste Implementierung sollte:
Die TLS-Zertifikatsüberprüfung standardmäßig aktivieren.
Ein konfigurierbares CA-Bundle unterstützen, zum Beispiel:
ssl.ca.location
VAULT_CACERT
Client-Zertifikate für Umgebungen mit gegenseitigem TLS unterstützen.
Verhindern, dass ein leerer oder falscher Konfigurationswert die Zertifikatsüberprüfung stillschweigend deaktiviert.
Regressionstests hinzufügen, die bestätigen, dass selbstsignierte und anderweitig nicht vertrauenswürdige Zertifikate standardmäßig abgelehnt werden.
Die Schwachstelle ist behoben in:
confluent-kafka 2.15.0
Betroffene Versionen sind:
2.8.0
through
2.14.2
In 2.15.0 wurde das Verhalten des Vault-Clients so geändert, dass die TLS-Überprüfung standardmäßig aktiviert ist.
Die aktualisierte Implementierung führt außerdem TLS-bezogene Konfigurationen ein, einschließlich:
ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location
Dies ermöglicht Bereitstellungen mit privater PKI-Infrastruktur, vertrauenswürdige CA- und Client-Zertifikatskonfigurationen bereitzustellen, ohne die Zertifikatsüberprüfung zu deaktivieren.
Die Schwachstelle wird bewertet mit:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
CVSS 3.1 Score: 7.4 — Hoch
AV:N — Netzwerk
Die verwundbare Vault-Kommunikation erfolgt über eine Netzwerkverbindung.
AC:H — Hohe Angriffskomplexität
Der Angreifer muss eine Netzwerk-MITM-Position erlangen oder die Vault-Verbindung anderweitig umleiten.
Dies ist eine erhebliche Voraussetzung und der Grund, warum die Schwachstelle als Hoch statt Kritisch eingestuft wird.
PR:N — Keine Berechtigungen erforderlich
Der Angreifer benötigt keine Berechtigungen innerhalb der betroffenen Anwendung.
UI:N — Keine Benutzerinteraktion
Nachdem der Angreifer die erforderliche Netzwerkposition erlangt hat, ist keine Benutzerinteraktion erforderlich.
S:U — Scope Unchanged
Die Auswirkung bleibt innerhalb der Sicherheitsautorität der betroffenen Anwendung und ihrer Vault-Interaktion.
C:H — Hohe Vertraulichkeitsauswirkung
Vault-Tokens oder AppRole-Anmeldedaten können für den Angreifer offengelegt werden.
I:H — Hohe Integritätsauswirkung
Der Angreifer kann sich als Vault ausgeben und gefälschte Vault/KMS-Antworten zurückgeben.
A:N — Keine Verfügbarkeitsauswirkung
Es wurde keine direkte Verfügbarkeitsauswirkung nachgewiesen.
2.8.0 bis 2.14.22.15.0Das hardcodierte verify=False existierte seit der Einführung der HCVault-Integration bis Version 2.14.2.
Das Sicherheitsverhalten wurde in 2.15.0 korrigiert.
YYYY-MM-DD — An Confluent gemeldet.2.15.0 veröffentlicht.Entdeckt und gemeldet von Rahul Karne.
confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka auf PyPI
https://pypi.org/project/confluent-kafka/
HashiCorp hvac Python-Client
https://hvac.readthedocs.io/
HashiCorp Vault AppRole-Authentifizierung
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — Improper Certificate Validation
https://cwe.mitre.org/data/definitions/295.html
Python TLS / Zertifikatsüberprüfungs-Dokumentation
https://docs.python.org/3/library/ssl.html#ssl-security
Dieses Repository dokumentiert einen Sicherheitsbefund aus einer koordinierten Offenlegung und stellt ein harmloses, in sich geschlossenes Proof of Concept bereit.
Das PoC arbeitet ausschließlich gegen einen lokalen Mock-Vault-Server mit Dummy-Anmeldedaten.
Es interagiert nicht mit echtem HashiCorp Vault, Kafka, Schema Registry, Produktionsinfrastruktur oder echten Anmeldedaten.
Das Material wird für defensive Sicherheitsforschung und Bildungszwecke bereitgestellt.
Medienanfragen: [email protected]. Vollständiges PoC (Angreifer-Server, Traversal-Archiv, Opfer-Anwendung) und zusätzliche technische Details auf Anfrage erhältlich.