CVE-2021-27561

Falha de execução remota de código pré-autenticação como root no Yealink Device Management (DM) 3.6.0.20 e anteriores, explorável com uma única requisição HTTP. O impacto é total (root em servidor de gestão centralizada de telefones/dispositivos VoIP), e a vulnerabilidade está confirmada como explorada ativamente (catálogo KEV da CISA).

A CVE nasce de uma cadeia de duas falhas distintas, documentadas pela SSD Disclosure (que atribuiu CVE-2021-27561 e CVE-2021-27562 aos dois componentes). A primeira é um SSRF pré-autenticado no endpoint /premise/front/getPingData da aplicação NodeJS 'dmweb' (app.js), que roda em 127.0.0.1:9880 atrás do Nginx (porta 443/tcp). O parâmetro 'url' da requisição é passado sem validação para uma chamada request.get(), permitindo que o servidor DM faça requisições arbitrárias, inclusive para serviços internos que só deveriam ser acessíveis via loopback.

A segunda falha, que é o alvo específico descrito nesta CVE (CWE-78, injeção de comando OS), está no daemon smserver, que roda como root e escuta em 0.0.0.0:9600/tcp (bloqueado por firewall para acesso externo direto, mas alcançável via loopback). No módulo mod_firewall.so, a função fw_restful_service_get() lê o parâmetro GET 'zone' via fw_restful_get_arg_by_key() e monta um comando com snprintf(3) sem sanitização de metacaracteres de shell. Esse comando é entregue a fw_do_cmd(), que é apenas um wrapper de popen(3) — ou seja, qualquer ponto e vírgula, pipe ou substituição de shell inserido em 'zone' é executado literalmente pelo shell do sistema, com os privilégios do processo (root).

O caminho de exploração completo é Nginx (borda) -> NodeJS/dmweb (SSRF) -> smserver (injeção). O atacante usa o SSRF do primeiro componente para fazer o próprio servidor DM enviar, via loopback, a requisição maliciosa para /sm/api/v1/firewall/zone/services?zone=;PAYLOAD; no smserver, contornando a restrição de firewall que impediria acesso direto externo à porta 9600.

O ataque é feito com uma única requisição HTTPS para a porta 443 do servidor Yealink DM, sem qualquer autenticação, sessão ou cabeçalho especial — o AV:N/AC:L/PR:N/UI:N do vetor CVSS reflete exatamente essa realidade: qualquer host com acesso de rede à interface de gestão consegue executar comandos como root. Não há pré-condição de configuração não padrão; o SSRF e o endpoint vulnerável do smserver existem na instalação padrão do produto na versão afetada.

Na prática, o atacante encapsula a URL do endpoint interno vulnerável (http://0.0.0.0:9600/sm/api/v1/firewall/zone/services?zone=;PAYLOAD;) como valor do parâmetro 'url' do SSRF em /premise/front/getPingData. O servidor DM, atuando como proxy involuntário, repassa a requisição para o smserver local, que interpreta o payload injetado em 'zone' como parte de um comando de shell e o executa via popen(3) com privilégios de root. O resultado é execução arbitrária de comandos no sistema operacional subjacente ao servidor de gestão.

A CISA confirma exploração ativa em campo (inclusão no catálogo KEV, adicionada em 03/11/2021, com prazo de correção em 17/11/2021), embora não classifique o caso como associado a campanhas de ransomware conhecidas até a publicação do catálogo. Dado que o Yealink DM é usado para gestão centralizada de telefones IP e outros dispositivos, um servidor comprometido oferece ponto de pivotamento para toda a frota de endpoints gerenciados.

A SSD Disclosure reportou a falha ao fornecedor, que respondeu que liberaria uma nova versão no início de 2021 disponível para download no site oficial, sem numeração de versão de correção divulgada nas fontes consultadas. Não há, portanto, confirmação apurada de qual build específico corrige a falha — a recomendação primária é aplicar a atualização mais recente disponibilizada pelo fornecedor para o Yealink DM e validar diretamente com o fabricante a versão que trata CVE-2021-27561 e CVE-2021-27562.

Como controle compensatório caso a atualização não seja imediata: a interface de gestão do Yealink DM (porta 443 e demais serviços internos) nunca deveria estar exposta à internet pública; restringir acesso à interface via VPN, allow-list de IPs ou segmentação de rede reduz a superfície de exploração, já que o vetor de ataque depende de alcançar a porta HTTPS de borda do servidor. Isso não elimina a falha, apenas limita quem pode alcançá-la — não é substituto para o patch.

Não funciona como mitigação confiar apenas na regra de firewall que bloqueia acesso externo direto à porta 9600 do smserver: é exatamente essa premissa que a cadeia SSRF+injeção contorna, usando o próprio servidor como relay para acessar o serviço interno via loopback.

Em logs do Nginx/NodeJS, procurar requisições para /premise/front/getPingData contendo no parâmetro 'url' referências a endereços internos (127.0.0.1, 0.0.0.0 ou localhost) na porta 9600, especialmente combinadas com o caminho /sm/api/v1/firewall/zone/services e parâmetro 'zone' contendo metacaracteres de shell (;, |, `, $(), &&). Essa combinação é o indicador mais específico da cadeia de exploração documentada.

No lado do smserver, processos filhos inesperados gerados como root (via popen) a partir do binário smserver, ou execução de comandos fora do padrão operacional do firewall-cmd interno, são sinais de exploração bem-sucedida. Não há assinatura oficial publicada pelo fornecedor ou pela CISA para detecção; o template Nuclei existente cobre a verificação de exposição/exploração do endpoint, mas confiar apenas na ausência de tentativas nos logs não garante que o servidor não foi comprometido, já que a exploração deixa poucos artefatos fora do log de acesso HTTP e da execução de processo no host.