Hack Alerta

Nova técnica de elevação de privilégios no Windows RPC expõe falha arquitetural sem correção da Microsoft

Pesquisa da Kaspersky revela falha arquitetural no Windows RPC que permite elevação de privilégios sem patch da Microsoft. Veja detalhes técnicos.

Introdução

Uma nova pesquisa de segurança publicada pela Kaspersky Security Services revelou uma vulnerabilidade arquitetural no mecanismo de Remote Procedure Call (RPC) do Windows que permite a elevação de privilégios locais para o nível SYSTEM. A técnica, batizada de PhantomRPC, explora a forma como o Windows gerencia chamadas de RPC para serviços indisponíveis, permitindo que um atacante com privilégios de impersonação crie um servidor RPC falso para escalar privilégios.

Apesar da divulgação adequada ao Microsoft Security Response Center (MSRC), a Microsoft classificou a vulnerabilidade como de severidade moderada e não emitiu um patch imediato, nem atribuiu um CVE. A pesquisa demonstra cinco caminhos de exploração diferentes, afetando todas as versões do Windows, e destaca a necessidade de monitoramento proativo por parte das equipes de segurança.

O que é a falha PhantomRPC

A vulnerabilidade reside na forma como o runtime RPC do Windows (rpcrt4.dll) lida com chamadas de clientes que tentam se conectar a servidores indisponíveis. Quando um cliente RPC tenta se comunicar com um servidor que não está rodando, o Windows retorna um erro de servidor indisponível. No entanto, o sistema permite que outro processo implante um servidor RPC falso que expõe o mesmo endpoint que o serviço legítimo.

Se o cliente RPC estiver configurado para usar um nível de impersonação alto (Impersonate), o servidor falso pode chamar a API RpcImpersonateClient para assumir o contexto de segurança do cliente. Isso permite que um atacante que já tenha comprometido um processo com privilégios de impersonação (como Network Service ou Local Service) eleve seus privilégios para SYSTEM ou Administrador.

Cenários de exploração identificados

A pesquisa identificou cinco caminhos de exploração distintos que demonstram como os privilégios podem ser elevados de vários contextos de serviço local ou de rede para usuários de alto privilégio. Alguns métodos dependem de coerção, outros requerem interação do usuário e outros aproveitam serviços em segundo plano.

Coerção do serviço de Política de Grupo: O serviço de Política de Grupo (gpsvc) tenta se comunicar com o TermService (Terminal Service) usando RPC. Se o TermService estiver desabilitado, um servidor RPC falso pode interceptar a chamada e escalar privilégios de Network Service para SYSTEM.

Interação do usuário: Do Edge ao RDP: O Microsoft Edge (msedge.exe) dispara uma chamada RPC ao TermService durante a inicialização. Se o atacante implantar um servidor RPC falso, pode escalar privilégios de Network Service para Administrador quando um usuário de alto privilégio abrir o navegador.

Serviços em segundo plano: Do WDI ao RDP: O serviço WdiSystemHost realiza chamadas RPC periódicas ao serviço de Área de Trabalho Remota sem interação do usuário. Isso permite a elevação automática para SYSTEM.

Abuso da conta Local Service: Do ipconfig ao DHCP: O serviço DHCP Client expõe um servidor RPC frequentemente invocado por DLLs do sistema. Um servidor falso pode interceptar chamadas do ipconfig.exe para escalar privilégios de Local Service para Administrador.

Abuso do Tempo: O executável w32tm.exe tenta acessar um pipe de nome inexistente. Um servidor RPC falso pode expor esse endpoint para escalar privilégios de Local Service para Administrador.

Por que a Microsoft não corrigiu

Após a descoberta, a Kaspersky Security Services submeteu um relatório técnico de 10 páginas ao MSRC. Vinte dias depois, a Microsoft respondeu indicando que não classificava a vulnerabilidade como de alta severidade. Segundo a avaliação deles, o problema foi classificado como de severidade moderada e, portanto, não seria corrigido imediatamente.

A Microsoft explicou que a classificação de severidade moderada se devia ao requisito de que o processo de origem já precisasse possuir o privilégio SeImpersonatePrivilege para que o ataque tivesse sucesso. Como esse privilégio é tipicamente necessário para o ataque, a Microsoft determinou que o problema não exigia remediação imediata. A Kaspersky respeitou a avaliação e publicou a pesquisa após o término do período de embargo.

Detecção e defesa

Como a vulnerabilidade está relacionada a um comportamento de design arquitetural, preveni-la totalmente exigiria que a Microsoft lançasse um patch que abordasse o problema subjacente. No entanto, as organizações podem tomar medidas para detectar e mitigar o abuso potencial.

O monitoramento baseado em ETW (Event Tracing for Windows) dentro da estrutura descrita na pesquisa permite que defensores identifiquem exceções RPC em seu ambiente, especialmente quando clientes RPC tentam se conectar a servidores indisponíveis. A Kaspersky forneceu as ferramentas usadas na estrutura para que as organizações possam verificar seu ambiente quanto a esse comportamento.

Os administradores podem identificar situações onde servidores RPC legítimos são esperados, mas não estão rodando. Em alguns casos, a superfície de ataque pode ser reduzida habilitando os serviços correspondentes, garantindo que o servidor RPC legítimo esteja disponível. Isso pode impedir que atacantes implantem servidores RPC maliciosos que imitam endpoints legítimos.

Também é boa prática reduzir o uso do privilégio SeImpersonatePrivilege em processos onde não é necessário. Alguns processos do sistema precisam desse privilégio para operações normais, mas concedê-lo a processos personalizados geralmente não é considerado uma boa prática de segurança.

O que os CISOs devem fazer agora

As equipes de segurança devem revisar a configuração de privilégios de impersonação em seus ambientes Windows. É crucial monitorar chamadas RPC que falham com o código de status RPC_S_SERVER_UNAVAILABLE, especialmente quando originadas de processos de alto privilégio. A implementação de regras de detecção baseadas em ETW pode ajudar a identificar tentativas de exploração da técnica PhantomRPC antes que a elevação de privilégios seja concluída.


Baseado em publicação original de Kaspersky Securelist
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.