CVE-2020-0796

SMBGhost é uma falha crítica no driver de kernel do servidor SMBv3.1.1 do Windows (srv2.sys), causada por um erro no cálculo do tamanho de buffer ao processar mensagens comprimidas do protocolo. Afeta apenas as builds 1903 e 1909 do Windows 10 e do Windows Server (Server Core) — não o restante do parque Windows —, mas nesses ramos permite execução de código sem autenticação, tanto contra um servidor SMB exposto quanto contra um cliente que se conecta a um servidor malicioso. O CVSS 10.0 reflete corretamente a gravidade técnica; a limitação real de impacto é o escopo estreito de versões afetadas.

A falha está na forma como o driver srv2.sys (componente servidor do SMBv3) e o cliente SMBv3 tratam o recurso de compressão introduzido no SMB 3.1.1. Ao processar um cabeçalho de mensagem comprimida, o código lê o campo OriginalCompressedSegmentSize enviado pelo peer e usa esse valor, sem validação adequada, para calcular o tamanho do buffer de descompressão. Um valor manipulado provoca um integer overflow (CWE-190) que resulta em alocação de buffer menor que o necessário, levando a um buffer overflow no espaço de kernel (CWE-122/CWE-787) quando os dados descomprimidos são copiados.

O atacante controla o campo de tamanho declarado e o conteúdo do payload comprimido enviado na negociação/transporte da mensagem SMB3. Como o processamento ocorre em kernel-mode antes de qualquer autenticação de sessão SMB, a corrupção de memória acontece em contexto privilegiado — daí a nota de exploração 'pré-autenticação'.

Existe um vetor duplo: servidor (um cliente malicioso ataca uma máquina Windows vulnerável que expõe SMB na porta 445) e cliente (um servidor SMB malicioso controlado pelo atacante ataca um cliente Windows vulnerável que se conecta a ele, por exemplo via montagem de compartilhamento). A vulnerabilidade correlata CVE-2020-1206 (SMBleed), no mesmo caminho de código de compressão, permite leitura de memória de kernel e foi combinada por pesquisadores com o SMBGhost (cadeia 'SMBleedingGhost') para obter RCE mais confiável, contornando mitigações como KASLR.

As primeiras provas de conceito públicas (CoronaBlue e variantes) produziam apenas negação de serviço — BSOD por corrupção de memória no kernel —, e essa continua sendo a forma mais simples e confiável de explorar a falha remotamente contra a porta TCP 445 sem qualquer autenticação. A escalada para execução de código arbitrário em kernel é significativamente mais complexa: exige controle preciso do layout de heap do kernel e, na prática, foi demonstrada de forma mais robusta combinando o SMBGhost com o vazamento de memória do SMBleed (CVE-2020-1206) para vencer proteções de mitigação de exploração.

O vetor mais comumente visto em campo e em módulos de teste (incluindo Metasploit) é a negação de serviço contra hosts com SMB exposto à rede — cenário típico de máquinas Windows 10/Server 1903/1909 acessíveis pela porta 445, seja na rede interna, seja, em configurações mal seguras, diretamente na internet. Não é necessária credencial nem interação do usuário (UI:N) para o vetor servidor; para o vetor cliente, basta a máquina vulnerável se conectar a um compartilhamento SMB controlado pelo atacante.

A CISA incluiu a CVE-2020-0796 no catálogo KEV por exploração confirmada em ambiente real, e a disponibilidade de exploit público, módulo Metasploit e templates de scanner (Nuclei) tornou a varredura e a tentativa de exploração triviais de automatizar assim que o patch saiu — inclusive antes da divulgação oficial completa, já que detalhes da falha vazaram brevemente em advisories de terceiros antes do Patch Tuesday de março de 2020.

A correção definitiva é aplicar a atualização de segurança da Microsoft para os ramos afetados (Windows 10 1903/1909 e Windows Server 1903/1909 Server Core), lançada fora do ciclo normal em 12 de março de 2020 como parte do ADV200005/patch associado à KB4551762. Não há correção para versões anteriores ou posteriores do Windows porque elas simplesmente não contêm o código de compressão SMB 3.1.1 introduzido nesses builds — o problema é específico dessas duas versões.

Se a atualização não puder ser aplicada imediatamente, a Microsoft publicou um paliativo oficial: desabilitar a compressão SMBv3 via registro (chave em Services\LanmanServer\Parameters, valor DisableCompression). Isso neutraliza o vetor servidor, pois impede o processamento do caminho de código vulnerável na recepção de mensagens comprimidas, mas não protege o vetor cliente — uma máquina vulnerável ainda pode ser atacada ao se conectar a um servidor SMB malicioso. Bloquear a porta TCP 445 de entrada e saída no perímetro de rede reduz a exposição ao vetor servidor pela internet, mas não protege contra ataques originados dentro da rede interna nem contra o vetor cliente.

Não funciona como mitigação: apenas manter firewall pessoal do Windows ativo sem bloquear explicitamente 445, ou confiar em segmentação de rede que ainda permita tráfego SMB lateral entre estações — o histórico de exploração do EternalBlue mostrou que esse tipo de suposição falha na prática. Antivírus e EDR não bloqueiam de forma confiável a corrupção de memória em kernel antes que ela ocorra; detectam, na melhor hipótese, o comportamento pós-exploração.

Em tráfego de rede, o indício é a presença de mensagens SMB2 com o flag de compressão habilitado no header (SMB2_COMPRESSION_TRANSFORM) e valores anômalos ou inconsistentes no campo de tamanho original declarado (OriginalCompressedSegmentSize) trafegando na porta TCP 445 — sensores de rede e IDS/IPS com assinaturas para SMBGhost focam nesse padrão. Em nível de host, sinais de exploração de DoS aparecem como crash/BSOD do processo do driver srv2.sys nos logs de sistema e no Windows Error Reporting, com referência a falha em ntfs.sys/srv2.sys ou a um bug check de corrupção de memória.

Não há assinatura única e confiável para distinguir exploração de RCE bem-sucedida de simples tentativa de DoS a partir apenas de logs padrão do Windows — a confirmação de comprometimento normalmente exige análise forense de memória/kernel após um crash suspeito, já que o overflow ocorre antes de qualquer autenticação e não deixa rastro nos logs de aplicação SMB.