rahulreddykarne/cve-2026-57836-confluent_kafkaVérification du certificat TLS désactivée pour HashiCorp Vault KMS dans confluent-kafka
Sévérité : Élevée, CVSS 3.1 7.4
Vecteur (v3.1) : CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Affecté : confluent-kafka >= 2.8.0, <= 2.14.2
Corrigé dans : 2.15.0
CWE : CWE-295 (Validation de certificat incorrecte)
Composant : confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Rapporté par : Rahul Karne
CNA : VulnCheck
Le client HashiCorp Vault KMS dans confluent-kafka code en dur verify=False lors de la construction de son , désactivant la vérification du certificat TLS pour les connexions HTTPS à Vault effectuées via les règles de chiffrement de champs du Schema Registry.
hvac.ClientLe code vulnérable se trouve dans :
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Le client affecté est initialisé comme suit :
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Comme verify=False est inconditionnel, le client accepte les certificats TLS non fiables, y compris les certificats auto-signés ou contrôlés par un attaquant.
Un attaquant positionné sur le réseau, capable d'intercepter ou de rediriger le trafic Vault de l'application, peut usurper l'identité du serveur Vault, capturer les identifiants d'authentification Vault et renvoyer des réponses Vault/KMS falsifiées.
L'intégration HCVault affectée expose la configuration pour les jetons Vault, les espaces de noms et les identifiants AppRole, mais les versions affectées ne fournissent aucune configuration prise en charge de bundle CA ni mécanisme équivalent pour restaurer la vérification des certificats.
Un attaquant disposant d'une position d'homme du milieu sur le réseau entre l'application et HashiCorp Vault peut :
X-Vault-Tokenrole_idsecret_idCela peut compromettre la confidentialité et l'intégrité des données protégées par le flux de travail KMS adossé à Vault.
confluent-kafka est le client Python officiel de Confluent pour Apache Kafka.
La vulnérabilité affecte spécifiquement les déploiements utilisant :
Règles de chiffrement du Schema Registry
↓
Intégration HCVault KMS
↓
URI de clé hcvault://
La population affectée est donc plus restreinte que l'ensemble des utilisateurs de confluent-kafka.
Cependant, la fonctionnalité affectée est sensible en matière de sécurité, car ces déploiements reposent sur HashiCorp Vault pour la gestion des clés cryptographiques et le chiffrement au niveau des champs.
HcVaultKmsClient.__init__() analyse une URI de clé hcvault://, détermine l'URL de base de Vault et crée un hvac.Client.
Dans les versions affectées, y compris 2.14.2, le code pertinent est :
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 bibliothèque hvac s'appuie en fin de compte sur la pile TLS de requests de Python.
Définir :
verify=False
indique au client de ne pas valider le certificat TLS du serveur distant.
Par conséquent, des certificats qui seraient normalement rejetés peuvent être acceptés, y compris les certificats qui sont :
Cela affecte les deux chemins d'authentification pris en charge.
Lorsque l'authentification par jeton est utilisée, le jeton Vault est envoyé via l'en-tête HTTP :
X-Vault-Token
Si un attaquant réussit à usurper le point de terminaison Vault, le serveur contrôlé par l'attaquant peut recevoir ce jeton.
Lorsque l'authentification AppRole est utilisée, le client envoie :
role_id
secret_id
à :
/v1/auth/approle/login
Un MITM réussi peut donc capturer les deux identifiants AppRole.
Le pilote HCVault affecté lit la configuration, notamment :
token.id
namespace
approle.role.id
approle.secret.id
ainsi que les variables d'environnement VAULT_* pertinentes.
Cependant, les versions affectées n'exposent pas de configuration permettant aux opérateurs de :
Par conséquent, les applications utilisant l'intégration affectée ne peuvent pas restaurer la vérification TLS via la configuration normale du paquet.
Le paquet désactive explicitement la vérification du certificat serveur TLS au lieu de s'appuyer sur la valeur par défaut sécurisée.
La construction vulnérable est effectivement :
hvac.Client(..., verify=False)
plutôt que :
hvac.Client(..., verify=True)
ou simplement :
hvac.Client(...)
où la vérification est activée par défaut.
La désactivation de la vérification des certificats supprime l'authentification du serveur de la connexion TLS.
Bien que la connexion reste chiffrée, le client ne dispose d'aucun mécanisme fiable pour déterminer s'il communique avec le serveur Vault légitime.
Cela crée la condition nécessaire à une attaque par homme du milieu sur le réseau.
Une exploitation réussie nécessite :
L'application utilise une version affectée de confluent-kafka :
2.8.0 à 2.14.2.L'application utilise les règles de chiffrement du Schema Registry avec l'intégration HCVault KMS.
La clé KMS configurée utilise le schéma :
hcvault://
Les exemples possibles incluent :
Aucun privilège au niveau de l'application ni interaction de la victime n'est requis une fois la position MITM nécessaire obtenue.
poc_confluent_kafka.py démontre le problème contre une wheel confluent-kafka 2.14.2 décompressée localement.
La PoC utilise :
HcVaultKmsClient.La preuve de concept contient cinq modes.
| Mode | Description |
|---|---|
cert | Génère un certificat auto-signé et une clé pour le Vault simulé local. |
server | Démarre le Vault HTTPS simulé sur https://localhost:8443 et affiche les requêtes reçues. |
control | Contrôle sécurisé utilisant verify=True ; doit rejeter le certificat auto-signé avec CERTIFICATE_VERIFY_FAILED. |
token | Charge le HcVaultKmsClient vulnérable et démontre qu'il accepte le certificat non fiable. |
approle | Exerce le chemin d'authentification AppRole vulnérable et démontre l'exposition de role_id et secret_id. |
Installez les dépendances de la PoC :
pip install hvac cryptography
Placez la wheel vulnérable décompressée à côté de la PoC :
confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
└── schema_registry/
└── ...
La PoC importe HcVaultKmsClient directement depuis le paquet 2.14.2 décompressé.
Elle remplace les dépendances non liées telles que tink, permettant de tester la construction vulnérable du client Vault sans nécessiter un environnement Kafka ou KMS complet.
Utilisez deux terminaux.
python poc_confluent_kafka.py server
Le Vault HTTPS simulé écoute sur :
https://localhost:8443
en utilisant un certificat auto-signé.
Démontrez d'abord qu'une validation correcte du certificat rejette le serveur auto-signé :
python poc_confluent_kafka.py control
Résultat attendu :
EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert
Exécutez :
python poc_confluent_kafka.py token
Le HcVaultKmsClient vulnérable se connecte malgré le fait que le serveur présente un certificat non fiable.
Le serveur simulé peut observer le jeton Vault :
GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace
Exécutez :
python poc_confluent_kafka.py approle
Le Vault simulé reçoit :
POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}
Le contraste entre le mode control sécurisé et les modes token / approle vulnérables démontre que le comportement résulte du :
verify=False
codé en dur, plutôt que de l'environnement de test.
Le correctif sécurisé de base consiste à permettre à hvac d'effectuer la vérification du certificat :
hvac.Client(
url=vault_url,
token=token,
namespace=ns
)
Comme la vérification TLS est activée par défaut, la désactiver explicitement est inutile.
Une implémentation robuste devrait :
Activer la vérification du certificat TLS par défaut.
Prendre en charge un bundle CA configurable, par exemple :
ssl.ca.location
VAULT_CACERT
Prendre en charge les certificats clients pour les environnements utilisant TLS mutuel.
Empêcher une valeur de configuration vide ou falsy de désactiver silencieusement la vérification du certificat.
Ajouter des tests de régression confirmant que les certificats auto-signés et autrement non fiables sont rejetés par défaut.
La vulnérabilité est corrigée dans :
confluent-kafka 2.15.0
Les versions affectées sont :
2.8.0
à
2.14.2
Dans 2.15.0, le comportement du client Vault a été modifié afin que la vérification TLS soit activée par défaut.
L'implémentation mise à jour introduit également une configuration liée à TLS, notamment :
ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location
Cela permet aux déploiements utilisant une infrastructure PKI privée de fournir une configuration CA de confiance et de certificat client sans désactiver la vérification du certificat.
La vulnérabilité est notée :
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Score CVSS 3.1 : 7.4 — Élevée
AV:N — Réseau
La communication Vault vulnérable se produit sur une connexion réseau.
AC:H — Complexité d'attaque élevée
L'attaquant doit obtenir une position MITM sur le réseau ou rediriger autrement la connexion Vault.
Il s'agit d'un prérequis important, ce qui explique pourquoi la vulnérabilité est classée Élevée plutôt que Critique.
PR:N — Aucun privilège requis
L'attaquant n'a pas besoin de privilèges au sein de l'application affectée.
UI:N — Aucune interaction utilisateur
Aucune interaction utilisateur n'est requise après que l'attaquant a obtenu la position réseau nécessaire.
S:U — Portée inchangée
L'impact reste dans le périmètre de sécurité de l'application affectée et de son interaction avec Vault.
C:H — Impact élevé sur la confidentialité
Les jetons Vault ou les identifiants AppRole peuvent être exposés à l'attaquant.
I:H — Impact élevé sur l'intégrité
L'attaquant peut usurper l'identité de Vault et renvoyer des réponses Vault/KMS falsifiées.
A:N — Aucun impact sur la disponibilité
Aucun impact direct sur la disponibilité n'a été démontré.
2.8.0 à 2.14.22.15.0Le verify=False codé en dur existait depuis l'introduction de l'intégration HCVault jusqu'à la version 2.14.2.
Le comportement de sécurité a été corrigé dans 2.15.0.
YYYY-MM-DD — Signalé à Confluent.2.15.0.Découvert et rapporté par Rahul Karne.
confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka sur PyPI
https://pypi.org/project/confluent-kafka/
Client Python hvac de HashiCorp
https://hvac.readthedocs.io/
Authentification AppRole de HashiCorp Vault
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — Validation de certificat incorrecte
https://cwe.mitre.org/data/definitions/295.html
Documentation Python TLS / vérification de certificat
https://docs.python.org/3/library/ssl.html#ssl-security
Ce dépôt documente une découverte de sécurité en divulgation coordonnée et fournit une preuve de concept inoffensive et autonome.
La PoC opère entièrement contre un serveur Vault simulé local utilisant des identifiants factices.
Elle n'interagit pas avec un véritable HashiCorp Vault, Kafka, Schema Registry, une infrastructure de production ou de véritables identifiants.
Le matériel est fourni à des fins de recherche défensive en sécurité et d'éducation.
Demandes des médias : [email protected]. PoC complète (serveur attaquant, archive de traversée, application victime) et détails techniques supplémentaires disponibles sur demande.