CVE-2020-1350

SIGRed é uma falha de heap overflow no serviço Windows DNS Server (dns.exe) explorável remotamente e sem autenticação, permitindo execução de código como SYSTEM. A Microsoft classificou como 'wormable' — potencial para se propagar de servidor DNS para servidor DNS sem interação humana, o que justifica o CVSS 10.0. Não é um bug de configuração exótica: qualquer Windows Server com a role DNS Server instalada e habilitada para forwarding/recursão está no caminho de exploração.

A falha está no parsing de registros SIG (Signature, definidos na RFC 2065/2535) dentro do código que trata respostas DNS recebidas via TCP. O componente de parsing calcula incorretamente o tamanho de um campo ao decodificar nomes comprimidos dentro do registro SIG, resultando em um integer overflow que leva a um heap-based buffer overflow (classe CWE-122/CWE-190) na hora de copiar os dados para um buffer alocado com tamanho menor que o necessário.

O gatilho depende de mensagens DNS grandes — acima do limite tradicional de 64KB usado em UDP — o que só é viável via TCP, protocolo que o DNS Server do Windows aceita para respostas grandes. Um atacante que controle o conteúdo de uma resposta DNS processada pelo servidor Windows (por exemplo, sendo o servidor autoritativo do domínio consultado, ou injetando a resposta em um cenário de forwarding/cache) controla os bytes que sobrescrevem a região de heap corrompida.

A exploração completa para RCE (além do DoS trivial) exige contornar mitigações do heap do Windows, o que pesquisadores da Check Point Research — que descobriram e nomearam a falha SIGRed — descreveram como algo que exige encadear a corrupção de heap com técnicas de manipulação de layout de memória; não é um overflow de exploração direta e óbvia.

O serviço roda como Local System, então qualquer execução de código bem-sucedida herda os privilégios máximos da máquina — não há elevação adicional necessária depois da exploração.

Existem dois vetores documentados. No primeiro, o atacante controla um domínio (ou subdomínio delegado) e faz com que o Windows DNS Server, atuando como resolver recursivo ou forwarder, envie uma query para o servidor DNS autoritativo malicioso do atacante; a resposta maliciosa (o registro SIG malformado) é processada pelo alvo e desencadeia o overflow. Isso não exige autenticação nem interação do usuário — só exige que o DNS Server do Windows faça, em algum momento, uma resolução que chegue até o servidor do atacante, algo comum em ambientes onde o servidor resolve nomes externos.

O segundo vetor, mais direto, é enviar a mensagem TCP maliciosa diretamente à porta 53 do DNS Server exposto — sem depender de resolução recursiva —, desde que o serviço esteja acessível na rede (interna ou, em configurações mal segmentadas, na internet).

O PoC público conhecido e catalogado (referenciado no Packet Storm) demonstra a negação de serviço — crash do serviço DNS — que é trivial de reproduzir e serve como prova de vulnerabilidade sem exigir bypass de heap. A escalada para execução de código arbitrário é mais complexa e foi demonstrada por pesquisadores em ambiente controlado, mas a CISA classifica a CVE como exploração confirmada em campo (presença no catálogo KEV), o que eleva a prioridade de correção independentemente da dificuldade de weaponização completa.

A correção definitiva é aplicar a atualização de segurança da Microsoft lançada no Patch Tuesday de julho de 2020, que corrige o parsing do registro SIG no DNS Server. Não há substituto funcional para o patch quando se trata do vetor de RCE completo.

Para quem não pode reiniciar/patchear imediatamente, a Microsoft publicou um workaround via registro: limitar o tamanho máximo de pacote de resposta TCP DNS aceito pelo serviço (chave TcpReceivePacketSize) para um valor menor que o necessário para acionar o overflow (0xFF00 / 65.280 bytes, segundo a orientação oficial), aplicado e seguido de reinício do serviço DNS — não do servidor inteiro. Esse workaround reduz a superfície mas pode interferir em respostas DNS legitimamente grandes, incluindo cenários com DNSSEC, então é paliativo, não solução.

Segmentar o serviço DNS para não aceitar tráfego TCP de origens não confiáveis, ou restringir quais servidores externos ele pode consultar recursivamente, reduz a exposição ao vetor de forwarding, mas não elimina o vetor direto se a porta 53/TCP estiver acessível a uma rede maior. A CISA emitiu a Emergency Directive 20-03 exigindo que agências federais dos EUA aplicassem o patch ou o workaround dentro de prazo curto — sinal da severidade percebida, não de que o workaround substitua o patch em definitivo.

Não há assinatura de payload confiável e pública para o vetor de RCE completo, dado que a exploração para execução de código é mais complexa que o PoC de DoS disponível. O sinal mais prático é monitorar crashes/reinícios inesperados do serviço DNS Server (dns.exe) nos logs de eventos do Windows, especialmente correlacionados com tráfego DNS via TCP anormalmente grande ou respostas contendo registros SIG de tamanho incomum vindas de servidores autoritativos externos não usuais. Ambientes com captura de tráfego DNS podem inspecionar respostas TCP na porta 53 buscando registros SIG malformados ou de tamanho fora do padrão, mas a ausência desse sinal não garante que não houve tentativa, dado que o vetor de DoS é trivial e pode ter sido usado apenas para reconhecimento sem deixar rastro de exploração bem-sucedida.