CVE-2023-29552

SLP (Service Location Protocol, RFC 2608) permite que qualquer atacante não autenticado registre serviços arbitrários em um daemon SLP acessível na rede. Combinando isso com spoofing de UDP, um atacante consegue forçar o daemon a devolver respostas de até ~65KB a partir de requisições de ~29 bytes, gerando um fator de amplificação de até 2200x — um dos maiores já documentados em ataques de reflexão. Não é uma falha de um produto específico: é um defeito de design do protocolo, presente em qualquer implementação de SLP (OpenSLP e derivados) exposta à rede, incluindo hipervisores, impressoras e placas de gerenciamento remoto.

SLP nasceu em 1997 (RFC 2165, atualizado pela RFC 2608) para descoberta de serviços em redes locais corporativas — nunca foi desenhado para operar na Internet pública. O protocolo roda sobre UDP/TCP porta 427 e permite duas operações relevantes aqui: registro de serviço (SrvReg) e consulta de serviço (SrvRqst/SrvTypeRqst). Nenhuma das duas exige autenticação por padrão.

O problema (CWE-406, amplificação de rede por volume de mensagem não controlado, combinado com CWE-306, ausência de autenticação em função crítica) é que um cliente remoto não autenticado pode registrar um serviço com uma URL de serviço e atributos de tamanho arbitrário — o pesquisador da Curesec demonstrou, com a ferramenta slpload, que é possível inflar esse registro até o buffer máximo aceito pelo daemon, gerando respostas de dezenas de KB para uma única consulta.

Uma resposta SLP típica sem exploração fica entre 48 e 350 bytes, dando um fator de amplificação natural de 1,6x a 12x sobre uma requisição de ~29 bytes. Ao registrar previamente um serviço malicioso volumoso, o atacante controla tanto o conteúdo quanto o tamanho da resposta que o daemon vai devolver a qualquer requisição subsequente — chegando a respostas de ~65.000 bytes e fator de amplificação medido em mais de 2200x.

O atacante não precisa comprometer o daemon nem burlar controle de acesso: ele só precisa que a porta 427/UDP esteja acessível para registrar o serviço forjado e, depois, para disparar requisições com IP de origem falsificado (spoofed) apontando para a vítima.

A cadeia de exploração tem duas fases. Primeiro, o atacante localiza daemons SLP expostos na Internet (varredura de UDP/427) e envia uma mensagem de registro de serviço com payload inflado ao tamanho máximo que o daemon aceitar — essa etapa exige resposta legítima ao atacante, então não pode ser spoofada. Depois, ele envia repetidamente pacotes UDP de consulta com o IP de origem falsificado para o endereço da vítima; o daemon SLP responde à vítima com o registro volumoso, não ao atacante. Repetindo esse envio, o atacante gera um volume de tráfego de saturação contra o alvo usando apenas uma fração da largura de banda que teria de gastar em um flood direto.

Pré-requisitos reais: nenhuma autenticação, nenhuma interação do usuário, e a única condição de rede necessária é que o serviço SLP esteja acessível via UDP/427 a partir da Internet ou de uma rede que o atacante controle parcialmente (para spoofing eficaz). Pesquisa de Bitsight identificou mais de 54.000 instâncias SLP expostas publicamente em fevereiro de 2023, em produtos como hipervisores VMware ESXi, impressoras Konica Minolta, roteadores Planex, e placas de gerenciamento remoto IBM IMM e SMC IPMI — ou seja, o volume de refletores potenciais na Internet é grande e heterogêneo.

A CVE está no catálogo KEV da CISA (exploração confirmada) e possui PoC pública (ferramenta slpload da Curesec, que mede o fator de amplificação contra um daemon alvo). O impacto final é indisponibilidade — o CVSS reflete apenas A:H, sem comprometer confidencialidade ou integridade do daemon SLP em si; o dano recai sobre o terceiro cujo IP foi usado como alvo do spoofing.

Não existe patch que 'corrija' o protocolo SLP em si — a falha é de design (registro não autenticado + resposta arbitrariamente grande). A mitigação real é desabilitar o serviço SLP quando ele não for necessário, ou impedir que a porta 427/UDP e TCP fique acessível a redes não confiáveis (incluindo a Internet). Para VMware ESXi especificamente: as linhas atualmente suportadas ESXi 7.x e 8.x não são afetadas, porque desde a versão 7.0 U2c e a linha 8.0 GA o serviço SLP vem desabilitado por padrão, com hardening adicional e filtragem pelo firewall do ESXi. As linhas ESXi 6.5 e 6.7, que já atingiram fim de suporte geral (EOGS), são afetadas e não recebem correção — a orientação do fornecedor é migrar para uma linha suportada ou, se isso não for possível, desabilitar o SLP manualmente (procedimento documentado pela VMware) e garantir que o host não esteja exposto a redes não confiáveis.

Para qualquer outro dispositivo com SLP (impressoras, placas de gerenciamento remoto, roteadores, appliances diversos), o controle compensatório é o mesmo: desabilitar o serviço SLP se não for usado, ou bloquear UDP/TCP 427 no perímetro e em qualquer segmentação interna voltada à Internet. Filtragem de saída (anti-spoofing, BCP38) na borda da rede reduz o risco de a própria infraestrutura ser usada como refletor contra terceiros, mas não protege o host onde o SLP roda de ser abusado internamente.

O que não funciona: manter o SLP ativo apenas 'atrás' de um firewall que permita tráfego UDP/427 de qualquer origem não impede o ataque, porque o vetor depende de spoofing de IP de origem — o firewall do host alvo não bloqueia pacotes que chegam com endereço de origem forjado da vítima; a defesa eficaz é impedir que o daemon SLP seja alcançável externamente, não filtrar por origem aparente.

Monitorar tráfego UDP/TCP na porta 427: presença de mensagens SrvReg (registro de serviço) com payloads anormalmente grandes, vindas de origens não administrativas, é indício de tentativa de preparar um refletor. No lado da vítima de um ataque, o sinal é volume elevado de tráfego UDP de origem porta 427 chegando sem requisição correspondente prévia — característico de reflexão/amplificação. Não há assinatura confiável para distinguir tráfego SLP legítimo de abuso apenas pelo formato do pacote de consulta, já que o protocolo em si não exige autenticação; a detecção depende de correlação de volume e de origem/destino atípicos, e de inventariar e monitorar quais hosts na rede expõem SLP publicamente.