Verificación de certificado TLS deshabilitada para HashiCorp Vault KMS en confluent-kafka
Severidad: Alta, CVSS 3.1 7.4
Vector (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Afectado: confluent-kafka >= 2.8.0, <= 2.14.2
Corregido en: 2.15.0
CWE: CWE-295 (Validación de certificados incorrecta)
Componente: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Reportado por: Rahul Karne
CNA: VulnCheck
El cliente de HashiCorp Vault KMS en confluent-kafka codifica de forma rígida verify=False al construir su hvac.Client, deshabilitando la verificación de certificados TLS para las conexiones HTTPS a Vault realizadas a través de las reglas de cifrado de campos del Schema Registry.
El código vulnerable se encuentra en:
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
El cliente afectado se inicializa de la siguiente manera:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Debido a que verify=False es incondicional, el cliente acepta certificados TLS no confiables, incluidos certificados autofirmados o controlados por un atacante.
Un atacante con posición de red capaz de interceptar o redirigir el tráfico de Vault de la aplicación puede suplantar el servidor de Vault, capturar credenciales de autenticación de Vault y devolver respuestas falsificadas de Vault/KMS.
La integración HCVault afectada expone configuración para tokens de Vault, namespaces y credenciales de AppRole, pero las versiones afectadas no proporcionan ninguna configuración compatible de CA-bundle ni un mecanismo equivalente para restaurar la verificación de certificados.
Un atacante con una posición de man-in-the-middle de red entre la aplicación y HashiCorp Vault puede:
X-Vault-Tokenrole_idsecret_idEsto puede comprometer la confidencialidad e integridad de los datos protegidos por el flujo de trabajo de KMS respaldado por Vault.
confluent-kafka es el cliente oficial de Confluent para Python para Apache Kafka.
La vulnerabilidad afecta específicamente a despliegues que utilizan:
Schema Registry encryption rules
↓
HCVault KMS integration
↓
hcvault:// key URI
Por lo tanto, la población afectada es más reducida que todos los usuarios de confluent-kafka.
Sin embargo, la funcionalidad afectada es sensible a la seguridad porque estos despliegues dependen de HashiCorp Vault para la gestión de claves criptográficas y el cifrado a nivel de campo.
HcVaultKmsClient.__init__() analiza una URI de clave hcvault://, determina la URL base de Vault y crea un hvac.Client.
En las versiones afectadas, incluida 2.14.2, el código relevante es:
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 librería hvac finalmente depende del stack TLS de requests de Python.
Establecer:
verify=False
indica al cliente que no valide el certificado TLS del servidor remoto.
Como resultado, los certificados que normalmente serían rechazados pueden ser aceptados, incluidos certificados que son:
Esto afecta a ambas rutas de autenticación compatibles.
Cuando se utiliza autenticación por token, el token de Vault se envía a través del encabezado HTTP:
X-Vault-Token
Si un atacante logra suplantar el endpoint de Vault, el servidor controlado por el atacante puede recibir este token.
Cuando se utiliza autenticación AppRole, el cliente envía:
role_id
secret_id
a:
/v1/auth/approle/login
Por lo tanto, un MITM exitoso puede capturar ambas credenciales de AppRole.
El controlador HCVault afectado lee configuración que incluye:
token.id
namespace
approle.role.id
approle.secret.id
así como las variables de entorno VAULT_* relevantes.
Sin embargo, las versiones afectadas no exponen configuración que permita a los operadores:
Como resultado, las aplicaciones que utilizan la integración afectada no pueden restaurar la verificación TLS a través de la configuración normal del paquete.
El paquete deshabilita explícitamente la verificación del certificado del servidor TLS en lugar de confiar en el valor predeterminado seguro.
La construcción vulnerable es efectivamente:
hvac.Client(..., verify=False)
en lugar de:
hvac.Client(..., verify=True)
o simplemente:
hvac.Client(...)
donde la verificación está habilitada de forma predeterminada.
Deshabilitar la verificación de certificados elimina la autenticación del servidor de la conexión TLS.
Aunque la conexión permanece cifrada, el cliente no tiene un mecanismo confiable para determinar si se está comunicando con el servidor de Vault legítimo.
Esto crea la condición necesaria para un ataque de man-in-the-middle de red.
La explotación exitosa requiere:
La aplicación utiliza una versión afectada de confluent-kafka:
2.8.0 hasta 2.14.2.La aplicación utiliza reglas de cifrado del Schema Registry con la integración HCVault KMS.
La clave KMS configurada utiliza el esquema:
hcvault://
Ejemplos posibles incluyen:
No se requieren privilegios a nivel de aplicación ni interacción de la víctima una vez que existe la posición MITM necesaria.
poc_confluent_kafka.py demuestra el problema contra un wheel de confluent-kafka 2.14.2 desempaquetado localmente.
La PoC utiliza:
HcVaultKmsClient.La prueba de concepto contiene cinco modos.