Bypass de Proteção do Administrador do Windows: Explorando Acesso à UI para Escalada de Privilégios

Por [Jornalista de Cibersegurança]

Principais Descobertas

O pesquisador de segurança James Forshaw divulgou detalhes técnicos de cinco vulnerabilidades críticas na implementação do UI Access da Microsoft, que permitiam a invasores contornar a Proteção do Administrador do Windows. Todas as nove técnicas de bypass identificadas durante a pesquisa de Forshaw — incluindo as cinco detalhadas nesta análise — foram corrigidas pela Microsoft.

As falhas têm origem no recurso UI Access, introduzido originalmente no Windows Vista para suportar ferramentas de acessibilidade, como leitores de tela. Ao abusar dessa funcionalidade, invasores poderiam alcançar a execução arbitrária de código em um processo UI Access de alta integridade, comprometendo o limite de segurança da Proteção do Administrador sem interação do usuário.

Contexto Técnico: UI Access e UIPI

A Evolução da Segurança na Interação com Janelas

Antes do Windows Vista, qualquer processo em execução na área de trabalho de um usuário podia controlar qualquer janela criada por outro processo — incluindo processos privilegiados — por meio de mensagens de janela. Esse comportamento foi explorado nos chamados Ataques Shatter, onde um usuário limitado podia manipular componentes de UI privilegiados para elevar privilégios. A Microsoft mitigou isso removendo elementos de UI de códigos privilegiados.

Com a introdução do Controle de Conta de Usuário (UAC) no Windows Vista, os processos passaram a ser executados em diferentes níveis de privilégio na mesma área de trabalho. Para evitar a manipulação cruzada de janelas entre privilégios, a Microsoft implementou o User Interface Privilege Isolation (UIPI), utilizando o Mandatory Integrity Control (MIC) para restringir interações entre processos. O UIPI impede que um processo envie mensagens de janela ou utilize hooks para interagir com janelas criadas por um processo de integridade superior.

Por exemplo:

• Um processo de usuário limitado (integridade Média) não pode enviar mensagens para um processo de administrador (integridade Alta).
• O UIPI também impede outras funcionalidades de UI, como hooks de janelas, de serem usadas entre níveis de integridade.

O Dilema da Acessibilidade

As restrições do UIPI criaram um problema significativo para ferramentas de acessibilidade, como leitores de tela. Esses aplicativos, executados como usuários limitados, não podiam mais interagir com processos de administrador — impedindo-os de ler o conteúdo de janelas ou realizar ações como clicar em botões. Para resolver isso, a Microsoft introduziu a flag UI Access.

Quando definida no token de acesso de um processo durante sua inicialização, a flag UI Access concede permissões especiais para contornar muitas das restrições do UIPI. A ativação dessa flag requer o privilégio SE_TCB_NAME, disponível apenas para serviços de sistema. Como resultado, a criação de um processo UI Access envolve um serviço de sistema — tipicamente o serviço UAC — por meio da chamada RPC RAiLaunchAdminProcess.

Fluxo de Criação de Processos UI Access

Para evitar o uso indevido, o serviço UAC aplica verificações rigorosas no arquivo executável antes de ativar a flag UI Access.

1. Requisito de Manifesto: O executável deve ter um manifesto embutido com o atributo uiAccess definido como true.
2. Assinatura de Código: O arquivo deve ser assinado por um certificado de assinatura de código confiável pela loja de certificados raiz da máquina local.
3. Localização Segura: O executável deve residir em um local acessível apenas por administradores no drive do sistema, como:
   • Diretório Program Files
   • Diretório Windows (excluindo locais graváveis conhecidos)
   • Diretório System32 (excluindo locais graváveis conhecidos)

Se esses critérios forem atendidos, o serviço UAC:

• Faz uma cópia do token de acesso do chamador.
• Ativa a flag UI Access.
• Aumenta o nível de integridade com base no chamador:
  • Usuário limitado de um administrador UAC: Define a integridade como Alta.
  • Administrador: Define a integridade como Alta (geralmente sem alteração).
  • Usuário normal: Define a integridade como a do chamador + 16, até um máximo de Alta.

Nota Importante: A flag UI Access permite apenas contornar um conjunto limitado de operações, como o envio de mensagens de janela para processos de integridade superior. Ela não permite o uso de hooks de janelas, que poderiam possibilitar a injeção de código.

Explorando o UI Access na Proteção do Administrador

A Vulnerabilidade Central

A Proteção do Administrador, um recurso mais recente do Windows, foi projetada para criar um limite seguro para o UAC, separando o usuário limitado do administrador oculto. No entanto, Forshaw descobriu que processos UI Access poderiam minar esse limite:

• Quando um usuário limitado cria um processo UI Access via RAiLaunchAdminProcess, o processo é executado sob o token do chamador (o usuário limitado), mas com a flag UI Access ativada e a integridade definida como Alta.
• Um processo de integridade Alta pode comprometer qualquer outro processo de integridade Alta na mesma área de trabalho, mesmo que seja executado como um usuário diferente.
• Como o processo UI Access é executado como o usuário limitado, não há separação de perfil — uma melhoria chave na Proteção do Administrador.
• A elevação para integridade Alta ocorre de forma silenciosa, permitindo que invasores quebrem o limite de segurança sem alertar o usuário.

Obtendo Execução Arbitrária em UI Access

Forshaw identificou múltiplos métodos para alcançar a execução arbitrária de código em um processo UI Access de integridade Alta. Embora a Microsoft tenha indicado anteriormente que essas questões não eram prioritárias para correção, várias delas foram corrigidas desde então. As técnicas se enquadram em três categorias principais:

1. Contornando a Verificação de Diretório Seguro da Aplicação

O método AiCheckSecureApplicationDirectory do serviço UAC valida se o executável reside em um local seguro. Forshaw descobriu várias maneiras de contornar essa verificação:

• Fluxos Nomeados do NTFS: Em 2017, Forshaw relatou um bypass onde um invasor poderia escrever um fluxo nomeado do NTFS em um diretório gravável por um usuário limitado. Por exemplo, o diretório C:\Windows\tracing é gravável, mas excluído da verificação segura. Ao escrever um fluxo nomeado (por exemplo, C:\Windows\tracing:file.exe), o arquivo seria considerado seguro porque o caminho parece estar dentro de C:\Windows. Esse problema foi resolvido em uma versão posterior do Windows.

• Arquivos/Diretórios Graváveis em Locais Seguros: Invasores poderiam sobrescrever um arquivo gravável existente em um local seguro com um executável malicioso. A API CreateProcessAsUser, usada pelo serviço UAC, não exige uma extensão de arquivo específica, permitindo que qualquer arquivo seja executado. Alternativamente, invasores poderiam copiar um executável para um diretório gravável dentro de um local seguro.

• Abuso do Instalador MSIX: Em pesquisas recentes, Forshaw descobriu que o instalador do Windows poderia colocar arquivos MSIX no diretório C:\Program Files\WindowsApps, que não era excluído pela verificação segura. O Windows 11 permite a instalação de arquivos MSIX assinados sem privilégios de administrador por padrão. Ao empacotar um executável UI Access em um instalador MSIX e assiná-lo com um certificado arbitrário, invasores poderiam colocar o executável em um local seguro. Esse problema foi corrigido excluindo o diretório WindowsApps.

2. Outros Bypasses Históricos

Forshaw também mencionou outros métodos históricos para obter execução arbitrária em UI Access, incluindo:

• DLL Planting: Sequestro de executáveis legítimos em locais seguros por meio da inserção de DLLs maliciosas.
• Abuso de COM: Exploração de componentes COM que utilizam janelas somente de mensagem para comprometer processos sem exibir UI.

Análise de Impacto

As vulnerabilidades descritas nesta pesquisa representam um risco significativo para sistemas Windows com a Proteção do Administrador ativada:

• Escalada de Privilégios: Invasores poderiam elevar privilégios de um usuário limitado para integridade Alta, contornando efetivamente o limite de segurança da Proteção do Administrador.
• Exploração Silenciosa: A elevação para integridade Alta ocorre sem interação do usuário, dificultando a detecção.
• Execução Arbitrária de Código: Uma vez alcançada a execução arbitrária de código em um processo UI Access de integridade Alta, invasores podem comprometer qualquer outro processo de integridade Alta na mesma área de trabalho.
• Falta de Separação de Perfil: A ausência de separação de perfil compromete uma das principais melhorias de segurança da Proteção do Administrador.

Recomendações

Profissionais de segurança e administradores de sistema devem adotar as seguintes medidas para mitigar os riscos associados a essas vulnerabilidades:

1. Aplicar Patches: Certifique-se de que todos os sistemas Windows estejam atualizados com os últimos patches de segurança da Microsoft para corrigir os bypasses.
2. Monitorar Processos UI Access: Implemente monitoramento para a criação incomum de processos UI Access, especialmente aqueles executados com integridade Alta.
3. Restringir Acesso a Locais Seguros: Limite o acesso de gravação a diretórios como Program Files, Windows e System32 apenas a administradores.
4. Auditar Certificados de Assinatura de Código: Revise e restrinja os certificados de assinatura de código confiáveis pela loja de certificados raiz da máquina local para evitar abusos.
5. Desativar Recursos de Acessibilidade Desnecessários: Desative o UI Access para aplicativos que não o exigem, reduzindo a superfície de ataque.

Conclusão

A pesquisa de James Forshaw destaca os desafios contínuos na segurança dos mecanismos de escalada de privilégios do Windows. Embora o UI Access tenha sido projetado para suportar acessibilidade, sua implementação introduziu riscos significativos de segurança que poderiam ser explorados para contornar a Proteção do Administrador. A Microsoft corrigiu as vulnerabilidades descritas nesta análise, mas a pesquisa reforça a importância de testes de segurança rigorosos e monitoramento proativo para defender contra ameaças similares no futuro.

Para mais detalhes técnicos, consulte o post original de Forshaw no Project Zero.