Verificaçã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 hvac.Client, 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.
O 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 atacantes.
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 de 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 de 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 simulado local. |
server | Inicia o Vault HTTPS simulado 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: