rahulreddykarne/cve-2026-57836-confluent_kafkaVerificação de Certificado TLS Desativada para HashiCorp Vault KMS no confluent-kafka
Severidade: Alta, CVSS 3.1 7.4
Vetor (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Afetado: confluent-kafka >= 2.8.0, <= 2.14.2
Corrigido em: 2.15.0
CWE: CWE-295 (Validação de Certificado Imprópria)
Componente: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
Reportado por: Rahul Karne
CNA: VulnCheck
O cliente HashiCorp Vault KMS no confluent-kafka codifica de forma fixa verify=False ao construir seu , desativando a verificação de certificado TLS para conexões HTTPS do Vault feitas através das regras de criptografia de campo do Schema Registry.
hvac.ClientO código vulnerável está localizado em:
confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py
O cliente afetado é inicializado da seguinte forma:
self._client = hvac.Client(
url=vault_url,
token=token,
namespace=ns,
verify=False
)
Como verify=False é incondicional, o cliente aceita certificados TLS não confiáveis, incluindo certificados autoassinados ou controlados por atacante.
Um atacante posicionado na rede capaz de interceptar ou redirecionar o tráfego do Vault da aplicação pode se passar pelo servidor Vault, capturar credenciais de autenticação do Vault e retornar respostas forjadas do Vault/KMS.
A integração HCVault afetada expõe configuração para tokens do Vault, namespaces e credenciais AppRole, mas as versões afetadas não fornecem configuração suportada de CA-bundle ou mecanismo equivalente para restaurar a verificação de certificado.
Um atacante com posição de man-in-the-middle na rede entre a aplicação e o HashiCorp Vault pode:
X-Vault-Tokenrole_idsecret_idIsso pode comprometer a confidencialidade e integridade dos dados protegidos pelo fluxo de trabalho KMS baseado no Vault.
confluent-kafka é o cliente Python oficial da Confluent para Apache Kafka.
A vulnerabilidade afeta especificamente implantações que usam:
Schema Registry encryption rules
↓
HCVault KMS integration
↓
hcvault:// key URI
A população afetada é, portanto, mais restrita do que todos os usuários de confluent-kafka.
No entanto, a funcionalidade afetada é sensível à segurança porque essas implantações dependem do HashiCorp Vault para gerenciamento de chaves criptográficas e criptografia em nível de campo.
HcVaultKmsClient.__init__() analisa uma URI de chave hcvault://, determina a URL base do Vault e cria um hvac.Client.
Nas versões afetadas, incluindo 2.14.2, o código relevante é:
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
)
A biblioteca hvac depende, em última análise, da pilha TLS do requests do Python.
Definir:
verify=False
instrui o cliente a não validar o certificado TLS do servidor remoto.
Como resultado, certificados que normalmente seriam rejeitados podem ser aceitos, incluindo certificados que são:
Isso afeta ambos os caminhos de autenticação suportados.
Quando a autenticação por token é usada, o token do Vault é enviado através do cabeçalho HTTP:
X-Vault-Token
Se um atacante conseguir se passar com sucesso pelo endpoint do Vault, o servidor controlado pelo atacante pode receber esse token.
Quando a autenticação AppRole é usada, o cliente envia:
role_id
secret_id
para:
/v1/auth/approle/login
Um MITM bem-sucedido pode, portanto, capturar ambas as credenciais AppRole.
O driver HCVault afetado lê configuração incluindo:
token.id
namespace
approle.role.id
approle.secret.id
bem como variáveis de ambiente VAULT_* relevantes.
No entanto, as versões afetadas não expõem configuração que permita aos operadores:
Como resultado, aplicações que usam a integração afetada não podem restaurar a verificação TLS através da configuração normal do pacote.
O pacote desativa explicitamente a verificação de certificado do servidor TLS em vez de confiar no padrão seguro.
A construção vulnerável é efetivamente:
hvac.Client(..., verify=False)
em vez de:
hvac.Client(..., verify=True)
ou simplesmente:
hvac.Client(...)
onde a verificação é habilitada por padrão.
Desativar a verificação de certificado remove a autenticação do servidor da conexão TLS.
Embora a conexão permaneça criptografada, o cliente não tem mecanismo confiável para determinar se está se comunicando com o servidor Vault legítimo.
Isso cria a condição necessária para um ataque man-in-the-middle na rede.
A exploração bem-sucedida requer:
A aplicação usa uma versão afetada de confluent-kafka:
2.8.0 até 2.14.2.A aplicação usa regras de criptografia do Schema Registry com a integração HCVault KMS.
A chave KMS configurada usa o esquema:
hcvault://
Exemplos possíveis incluem:
Nenhum privilégio em nível de aplicação ou interação da vítima é necessário uma vez que a posição MITM necessária exista.
poc_confluent_kafka.py demonstra o problema contra um wheel confluent-kafka 2.14.2 descompactado localmente.
A PoC usa:
HcVaultKmsClient.A prova de conceito contém cinco modos.
| Modo | Descrição |
|---|---|
cert | Gera um certificado autoassinado e chave para o Vault mock local. |
server | Inicia o Vault HTTPS mock em https://localhost:8443 e exibe as requisições recebidas. |
control | Controle seguro usando verify=True; deve rejeitar o certificado autoassinado com CERTIFICATE_VERIFY_FAILED. |
token | Carrega o HcVaultKmsClient vulnerável e demonstra que ele aceita o certificado não confiável. |
approle | Exercita o caminho de autenticação AppRole vulnerável e demonstra a exposição de role_id e secret_id. |
Instale as dependências da PoC:
pip install hvac cryptography
Coloque o wheel vulnerável descompactado ao lado da PoC:
confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
└── schema_registry/
└── ...
A PoC importa HcVaultKmsClient diretamente do pacote 2.14.2 descompactado.
Ela substitui dependências não relacionadas, como tink, permitindo que a construção vulnerável do cliente Vault seja testada sem exigir um ambiente Kafka ou KMS completo.
Use dois terminais.
python poc_confluent_kafka.py server
O Vault HTTPS mock escuta em:
https://localhost:8443
usando um certificado autoassinado.
Primeiro demonstre que a validação adequada de certificado rejeita o servidor autoassinado:
python poc_confluent_kafka.py control
Resultado esperado:
EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert
Execute:
python poc_confluent_kafka.py token
O HcVaultKmsClient vulnerável se conecta apesar do servidor apresentar um certificado não confiável.
O servidor mock pode observar o token do Vault:
GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace
Execute:
python poc_confluent_kafka.py approle
O Vault mock recebe:
POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}
O contraste entre o modo control seguro e os modos vulneráveis token / approle demonstra que o comportamento resulta do verify=False codificado de forma fixa:
verify=False
e não do ambiente de teste.
A correção segura básica é permitir que o hvac realize a verificação de certificado:
hvac.Client(
url=vault_url,
token=token,
namespace=ns
)
Como a verificação TLS é habilitada por padrão, desativá-la explicitamente é desnecessário.
Uma implementação robusta deve:
Habilitar a verificação de certificado TLS por padrão.
Suportar um CA bundle configurável, por exemplo:
ssl.ca.location
VAULT_CACERT
Suportar certificados de cliente para ambientes que usam mutual TLS.
Impedir que um valor de configuração vazio ou falso desative silenciosamente a verificação de certificado.
Adicionar testes de regressão confirmando que certificados autoassinados e de outra forma não confiáveis são rejeitados por padrão.
A vulnerabilidade é corrigida em:
confluent-kafka 2.15.0
As versões afetadas são:
2.8.0
through
2.14.2
Em 2.15.0, o comportamento do cliente Vault foi alterado para que a verificação TLS seja habilitada por padrão.
A implementação atualizada também introduz configuração relacionada a TLS, incluindo:
ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location
Isso permite que implantações que usam infraestrutura PKI privada forneçam configuração de CA confiável e certificado de cliente sem desativar a verificação de certificado.
A vulnerabilidade é pontuada como:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Pontuação CVSS 3.1: 7.4 — Alta
AV:N — Rede
A comunicação vulnerável com o Vault ocorre através de uma conexão de rede.
AC:H — Alta Complexidade de Ataque
O atacante deve obter uma posição MITM na rede ou de outra forma redirecionar a conexão com o Vault.
Este é um pré-requisito significativo e é por isso que a vulnerabilidade é classificada como Alta em vez de Crítica.
PR:N — Nenhum Privilégio Necessário
O atacante não requer privilégios dentro da aplicação afetada.
UI:N — Nenhuma Interação do Usuário
Nenhuma interação do usuário é necessária após o atacante obter a posição de rede necessária.
S:U — Escopo Inalterado
O impacto permanece dentro da autoridade de segurança da aplicação afetada e sua interação com o Vault.
C:H — Alto Impacto na Confidencialidade
Tokens do Vault ou credenciais AppRole podem ser expostos ao atacante.
I:H — Alto Impacto na Integridade
O atacante pode se passar pelo Vault e retornar respostas forjadas do Vault/KMS.
A:N — Nenhum Impacto na Disponibilidade
Nenhum impacto direto na disponibilidade foi demonstrado.
2.8.0 até 2.14.22.15.0O verify=False codificado de forma fixa existiu desde a introdução da integração HCVault até a versão 2.14.2.
O comportamento de segurança foi corrigido em 2.15.0.
YYYY-MM-DD — Reportado à Confluent.2.15.0.Descoberto e reportado por Rahul Karne.
confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka no PyPI
https://pypi.org/project/confluent-kafka/
Cliente Python hvac da HashiCorp
https://hvac.readthedocs.io/
Autenticação AppRole do HashiCorp Vault
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — Validação de Certificado Imprópria
https://cwe.mitre.org/data/definitions/295.html
Documentação de TLS / verificação de certificado do Python
https://docs.python.org/3/library/ssl.html#ssl-security
Este repositório documenta uma descoberta de segurança de divulgação coordenada e fornece uma prova de conceito inofensiva e autocontida.
A PoC opera inteiramente contra um servidor Vault mock local usando credenciais fictícias.
Ela não interage com HashiCorp Vault, Kafka, Schema Registry, infraestrutura de produção ou credenciais reais.
O material é fornecido para pesquisa de segurança defensiva e fins educacionais.
Consultas da mídia: [email protected]. PoC completa (servidor do atacante, arquivo de traversal, aplicação vítima) e detalhes técnicos adicionais disponíveis sob solicitação.