CVE-2014-8361

Falha de injeção de comando no serviço SOAP miniigd, parte do SDK UPnP da Realtek usado por dezenas de fabricantes de roteadores domésticos (D-Link, NEC Aterm, ELECOM, entre outros). A ação NewInternalClient do serviço injeta dados de entrada não sanitizados em uma chamada de sistema, permitindo execução de código como root sem autenticação. É crítica porque o SDK foi licenciado por múltiplos vendors e nunca teve um patch único na origem — cada fabricante corrigiu (ou não) por conta própria, o que explica por que a CISA registra exploração ativa até 2023, quase uma década depois da publicação.

O serviço miniigd implementa a interface UPnP IGD (Internet Gateway Device) via SOAP. Ao processar a ação NewInternalClient (chamada a partir de AddPortMapping), o código monta uma chamada de sistema (system call) usando o valor recebido no campo do SOAP request sem escapar ou validar caracteres de shell. Isso é uma injeção de comando OS clássica (CWE-78): o atacante controla o conteúdo do parâmetro NewInternalClient e consegue anexar comandos arbitrários que são executados com os privilégios do processo miniigd — tipicamente root, dado que o daemon UPnP roda com privilégios elevados para manipular regras de NAT/firewall.

A exploração consiste em enviar uma requisição SOAP UPnP crafted contendo o comando injetado no campo NewInternalClient para o endpoint de controle do miniigd. O ZDI classificou o vetor como rede sem necessidade de autenticação (AV:N no CVSS 3.1 usado pelo NVD), mas entradas posteriores do JVN (JPCERT/CC) para produtos NEC e ELECOM classificam o vetor como AV:A (rede adjacente) — ou seja, na prática a maioria dos dispositivos expõe o serviço UPnP apenas na LAN, não na WAN, salvo em configurações onde o UPnP foi exposto para fora (port forwarding mal configurado, ou dispositivos que aceitam UPnP também na interface WAN). Isso é a pré-condição real que a manchete 'crítica, sem autenticação' esconde: o atacante típico precisa estar na rede local, ser outro dispositivo já comprometido nessa rede, ou explorar um roteador cujo UPnP está acessível pela internet.

Há PoC pública (Exploit-DB 37169, Packet Storm) e módulo Metasploit, o que reduz a complexidade de exploração a praticamente zero para quem já tem acesso à rede-alvo. A CISA lista a falha no catálogo KEV com exploração confirmada 'in the wild through 2023' — o uso documentado inclui recrutamento de dispositivos para botnets DDoS (caso do botnet Hinatabot, citado por pesquisadores), que escaneiam a internet em busca de UPnP exposto e usam esse CVE para ganhar execução remota e instalar payloads.

Não existe patch da Realtek na origem do SDK — o ZDI publicou o advisory como 0-day sem correção após meses sem resposta do fornecedor. A correção real depende de cada fabricante que licenciou o SDK: a D-Link liberou firmwares corrigidos para modelos específicos (DIR-501, DIR-515, DIR-600L, DIR-605L, DIR-615 Fx/J1, DIR-619L, DIR-809, DIR-900L, DIR-905L) listados no SAP10055, cada um com versão de firmware própria — é preciso conferir modelo e revisão de hardware exatos antes de atualizar. A NEC liberou firmware corrigido para parte da linha Aterm (WG1900HP2, WG1900HP, WG1800HP4, WG1200HS2, WG1200HP3, WG1200HP2, W1200EX, W1200EX-MS), mas vários modelos mais antigos (WG1200HS, WG1200HP, WF800HP, WF300HP2, WR8165N, W500P, W300P) nunca receberão correção. A ELECOM confirmou, em 2021, que a falha ainda persistia em produtos ativos e que não planeja lançar correção para os modelos afetados, recomendando descontinuar o uso.

O paliativo real, recomendado por todos os fornecedores citados, é desabilitar o UPnP no dispositivo — isso elimina o vetor por completo, ao custo de perder o encaminhamento automático de portas para aplicações que dependem disso (jogos online, VoIP, alguns serviços de streaming/torrent). Restringir o acesso ao serviço UPnP por firewall/whitelisting, como sugerido pelo ZDI, é mitigação parcial e só funciona se o UPnP não precisar aceitar requisições de qualquer host da LAN — não é solução completa em redes domésticas típicas, onde qualquer dispositivo comprometido na mesma rede (IoT, notebook infectado) pode originar o ataque. Trocar senha de administração ou usar HTTPS no painel web não mitiga nada aqui — a falha está no daemon UPnP, não na autenticação web.

Em nível de rede/log, o indicador é uma requisição SOAP UPnP (tipicamente POST para o control URL do IGD, ação AddPortMapping) contendo no campo NewInternalClient caracteres de metacaracteres de shell (`;`, `|`, `&&`, backticks, `$()`) em vez de um endereço IP válido. Como a implementação varia por OEM (caminhos de control URL, nomes de serviço) e não há uma assinatura IDS única publicada e amplamente validada, a confiabilidade da detecção por assinatura é baixa — ambientes que expõem UPnP devem tratar qualquer processo filho inesperado gerado pelo daemon UPnP/miniigd, ou conexões de saída não usuais originadas do roteador, como sinal mais forte do que o payload em si. Dado o histórico de uso em botnets (scanners de UPnP exposto seguidos de exploração automatizada), tráfego de descoberta SSDP/UPnP seguido imediatamente por um SOAP request malformado para a mesma origem é um padrão a monitorar.