Remote Code Execution Vulnerability in Packaging

Instalações padrão do Apache CouchDB anteriores à 3.2.2 usavam um cookie Erlang fixo e conhecido publicamente para autenticar comunicação entre nós do cluster. Quem alcança a porta de distribuição Erlang do CouchDB na rede pode usar esse cookie padrão para se autenticar como um nó confiável e executar código com privilégios de administrador, sem passar pela API HTTP nem por qualquer login do CouchDB. O CVSS 9.8 pressupõe que essa porta de distribuição esteja exposta à rede — o próprio advisory do fornecedor diz que instalações que não expõem essa porta não são vulneráveis, o que muda bastante o risco real em ambientes com firewall correto.

CouchDB roda sobre Erlang/OTP e, para suportar operação em cluster, cada nó abre uma porta de distribuição Erlang aleatória vinculada a todas as interfaces de rede por padrão. O utilitário `epmd` (Erlang Port Mapper Daemon), escutando em porta fixa, anuncia essa porta aleatória para quem perguntar. A comunicação entre nós Erlang distribuídos é autenticada por um segredo compartilhado chamado 'cookie' — não por usuário/senha do CouchDB.

O vetor exige que o atacante alcance na rede o `epmd` (porta fixa) e a porta de distribuição Erlang aleatória do nó CouchDB — nenhum dos dois é a porta HTTP 5984 usada pela API normal. O atacante consulta o epmd para descobrir a porta de distribuição do nó, conecta-se a ela usando o cookie padrão publicamente conhecido (`monster`, usado historicamente pelos pacotes de instalação single-node e clusterizada) e, uma vez aceito como nó Erlang confiável pelo protocolo de distribuição, ganha capacidade de RPC total sobre o nó remoto — equivalente a execução de código arbitrário com privilégios de administrador do CouchDB. Não há exploração de lógica de aplicação nem bypass de autenticação HTTP: é abuso de um mecanismo de cluster projetado para confiar em qualquer peer que apresente o cookie certo.

Atualizar para CouchDB 3.2.2 ou posterior: essa versão se recusa a iniciar se detectar o cookie padrão antigo (`monster`), forçando o operador a definir um valor próprio antes de o serviço subir. A partir da 3.2.2, os pacotes binários oficiais também passaram a vincular `epmd` e a porta de distribuição Erlang a `127.0.0.1`/`::1` em vez de todas as interfaces. Vale notar uma ressalva levantada na lista oss-security por mantenedores de distro: nem todo empacotamento aplicou esse binding automaticamente — no caso do Arch Linux, era necessário configurar manualmente `ERL_EPMD_ADDRESS=127.0.0.1`, enquanto Debian e CentOS/Rocky trataram isso via arquivo de ambiente default no pacote. Ou seja: atualizar a versão não garante por si só que a porta de distribuição ficou restrita ao localhost — é preciso confirmar isso para o pacote/distribuição específica em uso.

Sinais de tentativa de exploração aparecem como conexões externas às portas do subsistema de distribuição Erlang: a porta fixa do `epmd` (tradicionalmente 4369/TCP) e a porta de distribuição aleatória que ele anuncia, originadas de IPs que não deveriam ter esse acesso (fora da rede de cluster legítima). Tentativas de handshake do protocolo de distribuição Erlang seguidas de autenticação usando o cookie `monster` são o padrão característico, e módulos públicos (Metasploit, templates Nuclei) reproduzem esse fluxo de forma padronizada, o que facilita a escrita de assinaturas de IDS/IPS voltadas a esse tráfego. Não há, porém, um log de aplicação do CouchDB que registre essa exploração de forma nativa e óbvia — a autenticação ocorre na camada de distribuição Erlang, abaixo da API HTTP, então ambientes sem inspeção de rede dedicada a essas portas tendem a não ter visibilidade alguma do ataque.