CVE-2019-0543

Elevação de privilégio local no Windows causada pelo tratamento incorreto de requisições de autenticação NTLM loopback via SSPI. Um atacante que já tem uma sessão local com privilégios baixos consegue obter um token autenticado atrelado à Session 0, usado normalmente por serviços do sistema, abrindo caminho para rodar processos fora do isolamento de sessão do usuário. Está no catálogo KEV da CISA por exploração confirmada e tem PoC pública, mas o pré-requisito de acesso local autenticado limita o impacto a cenários pós-comprometimento inicial, não a ataques remotos.

A falha está na interface SSPI (Security Support Provider Interface) do Windows, especificamente no fluxo de autenticação NTLM 'loopback' — quando um processo autentica contra a própria máquina. Nesse cenário, o comportamento esperado é um 'short circuit': o LSASS simplesmente retorna ao chamador uma cópia do próprio token, com mesmo nível de privilégio, mesma authentication ID e mesmo session ID, sem valor prático para escalonamento.

O problema (CWE-287, Improper Authentication) aparece quando o atacante chama AcquireCredentialsHandle fornecendo uma estrutura SEC_WINNT_AUTH_IDENTITY_EX com os campos de username e domínio preenchidos, mas sem senha. Nesse caso o LSASS não faz o short circuit — ele conduz um processo de autenticação de rede real e retorna um token de rede autenticado. A falha central é que o LSASS não ajusta o session ID desse token: autenticação de rede não cria uma nova sessão de console, então o token resultante fica marcado com Session ID 0, a sessão reservada para serviços do sistema desde a introdução do isolamento de sessões no Windows Vista.

Como a autenticação foi feita contra si mesmo, o token retornado pertence ao mesmo usuário e tem o mesmo nível de privilégio do processo que a iniciou — o que satisfaz os requisitos do Windows para impersonar esse token livremente. O atacante controla, portanto, um token válido, plenamente impersonável, mas com session ID 0, algo que o processo original não deveria conseguir obter fora do contexto de serviços.

A descoberta é atribuída ao Google Security Research (Project Zero). Não há indicação nas fontes de mudança relevante entre versões afetadas — o defeito estava presente na lógica de autenticação compartilhada por toda a família de sistemas listada pela Microsoft (Windows 7 até Windows 10 e servidores correspondentes, incluindo Server 2008 a 2019).

A exploração exige acesso local prévio com uma conta de usuário padrão — o vetor CVSS (AV:L/PR:L/UI:N) confirma que não há componente remoto nem interação de outro usuário necessária, mas privilégio baixo local é pré-condição obrigatória. Isso não é uma falha de acesso inicial: é uma ferramenta de escalonamento pós-exploração.

Na prática documentada pelo Exploit-DB (EDB-ID 46156, PoC em C# usando a biblioteca NtApiDotNet), o processo é: negociar a autenticação NTLM contra a própria máquina manipulando os campos da identidade sem senha, capturar o token de rede resultante marcado com Session ID 0, impersoná-lo e então usar o ativador COM/DCOM para instanciar um processo já rodando dentro da Session 0. A partir daí, o atacante ganha a capacidade de manipular objetos nomeados globais no namespace \BaseNamedObjects — algo normalmente restrito a serviços — o que pode servir como passo intermediário para encadear com outras vulnerabilidades de elevação (o próprio pesquisador cita explicitamente outro caso do Project Zero como possível continuação da cadeia).

O autor da PoC testou o comportamento em Windows 10 versões 1803 e 1809, sem verificar versões anteriores, embora a Microsoft tenha listado o defeito como presente em praticamente toda a linha suportada na época (Windows 7 a 10, Server 2008 a 2019). A entrada no catálogo KEV da CISA confirma exploração ativa registrada, mas sem detalhar campanha ou ator específico nas fontes disponíveis.

A correção veio nas atualizações de segurança da Microsoft do ciclo de janeiro de 2019 (Patch Tuesday), que endereçam o tratamento de autenticação NTLM loopback no LSASS. As fontes consultadas não trazem os números de KB/build específicos por sistema operacional — para cada versão listada (Windows 7, 8.1, 10, Server 2008, 2008 R2, 2012, 2012 R2, 2016, 2019, RT 8.1), aplique a atualização de segurança correspondente publicada pela Microsoft no boletim oficial de CVE-2019-0543 e confirme o nível de patch pelo painel de atualizações do Windows Update ou WSUS.

Como paliativo, não há flag de registro ou configuração documentada que neutralize a falha sem o patch — a exposição está no núcleo da lógica de autenticação do LSASS, não em um recurso opcional que possa ser desativado. O controle compensatório real é reduzir a superfície de ataque local: restringir quem tem logon interativo/console nas máquinas afetadas, aplicar princípio de menor privilégio para contas de usuário padrão e monitorar criação anômala de processos em Session 0 por contas não-SYSTEM.

Não funciona como mitigação: desabilitar NTLM completamente na rede não resolve, porque a exploração usa autenticação loopback local — o tráfego não sai pela rede — e não é interceptado por políticas de restrição de NTLM entre hosts (como as GPOs 'Network security: Restrict NTLM').

Não há assinatura de rede a procurar: a exploração ocorre inteiramente no host, via chamadas locais à API SSPI (AcquireCredentialsHandle) e autenticação NTLM contra a própria máquina, sem tráfego externo. Em logs de segurança do Windows, um indício possível é a presença de eventos de logon tipo 3 (network logon) originados do próprio host contra ele mesmo, seguidos de criação de processos com Session ID 0 por contas que não são SYSTEM ou contas de serviço — mas isso não é um sinal documentado como confiável nas fontes consultadas, e pode gerar falsos positivos em ambientes com automação legítima. Na ausência de detecção comportamental específica, a defesa prática é garantir que o patch esteja aplicado.