Introdução
Bring Your Own Vulnerable Driver (BYOVD) é uma técnica de ataque cada vez mais popular, na qual um invasor traz um driver assinado e conhecido como vulnerável junto com seu malware, carrega-o no kernel e o explora para executar alguma ação no kernel que, de outra forma, não seria capaz de fazer. Após obter acesso ao kernel, eles podem adulterar ou desabilitar o software de segurança, despejar credenciais que de outra forma seriam inacessíveis ou modificar o comportamento do sistema operacional para ocultar sua presença. Joe Desimone e eu abordamos isso em detalhes, entre outras ameaças do modo kernel, na Black Hat USA 2018. Empregado por agentes de ameaças avançadas por mais de uma década, o BYOVD está se tornando cada vez mais comum em ransomware e malware de commodities.
O Driver Signing Enforcement (DSE), implantado pela primeira vez em 2007 pelo Windows Vista x64, foi a primeira vez que a Microsoft tentou limitar o poder dos administradores. Com o DSE em vigor, os administradores não podiam mais carregar instantaneamente nenhum código no kernel. As restrições de administrador aumentaram ao longo do tempo com o lançamento do Boot Guard, Secure Boot e Trusted Boot para proteger a cadeia de inicialização de malware de administrador, que anteriormente podia instalar seus próprios carregadores de inicialização/bootkits.
Para limitar ainda mais o poder dos administradores, a Microsoft implantou recentemente a Lista de Bloqueio de Drivers Vulneráveis por padrão, a partir do Windows 11 22H2. Este é um passo na direção certa, tornando o Windows 11 mais seguro por padrão. Infelizmente, o modelo de implantação da lista de bloqueio pode ser lento para se adaptar a novas ameaças, com atualizações implantadas automaticamente, normalmente, apenas uma ou duas vezes por ano. Os usuários podem atualizar manualmente suas listas de bloqueio, mas tais intervenções nos tiram do território “seguro por padrão”.
Limites de segurança
Ao determinar quais vulnerabilidades corrigir, o Microsoft Security Response Center (MSRC) usa o conceito de limite de segurança, que ele define da seguinte forma:
Um limite de segurança fornece uma separação lógica entre o código e os dados de domínios de segurança com diferentes níveis de confiança. Por exemplo, a separação entre o modo kernel e o modo usuário é um limite de segurança clássico e direto.
Com base nessa definição, alguém pode estar inclinado a pensar que o malware executado no modo de usuário não deveria ser capaz de modificar a memória do kernel. Afinal, o limite é “direto”. Logicamente, qualquer violação desse limite deve ser tratada com uma ação corretiva, como um patch ou atualização da lista de bloqueios.
Infelizmente, a situação fica mais obscura a partir daqui. O documento afirma posteriormente que o administrador para o kernel não é um limite de segurança, com a seguinte explicação:
Os processos administrativos e os usuários são considerados parte da Trusted Computing Base (TCB) do Windows e, portanto, não são fortemente isolados do limite do kernel.
Neste ponto, temos dois pontos de vista aparentemente conflitantes. Por um lado, o MSRC afirma que a conexão entre administrador e kernel é uma fronteira indefensável e não vale a pena consertá-la. Por outro lado, a Microsoft está tentando defender esse limite com mecanismos como Driver Signing Enforcement, Secure Boot e Vulnerable Driver Blocklist. Como a defesa é incompleta, o MSRC os chama de “recursos de segurança de defesa em profundidade”.
O MSRC também não considera a conexão entre administrador ePPL um limite de segurança, classificando-a como um recurso de segurança de defesa em profundidade. Mais sobre isso na próxima seção.
O restante deste artigo se referirá ao MSRC e à Microsoft separadamente. Embora o MSRC faça parte da Microsoft, a Microsoft é uma entidade muito maior que o MSRC; elas não devem ser equiparadas.
Explorando vulnerabilidades
Em setembro de 2022, registrei o VULN-074311 no MSRC, notificando-os sobre duas vulnerabilidades de dia zero no Windows: uma de administrador para PPL e uma de PPL para kernel. Forneci o código-fonte para ambos os exploits. A resposta indicou concisamente que eles entendiam as vulnerabilidades e se recusaram a tomar qualquer outra ação, conforme declarado abaixo:
A pesquisa descreve um ataque em várias etapas que aproveita um desvio de PPL para obter execução de código do kernel. Observe que todos os ataques propostos exigem privilégios administrativos para serem executados e, portanto, o problema relatado não atende aos nossos requisitos para manutenção imediata. Não esperamos nenhuma ação adicional e prosseguiremos com o encerramento do caso.
Neste jargão, “manutenção” significa “remendar”. A resposta deles é consistente com a política mencionada acima e seu tratamento histórico do limite entre administrador e kernel. O comportamento deles também é consistente: já se passaram mais de 11 meses e eles ainda não corrigiram nenhuma vulnerabilidade. Acho fascinante que a Microsoft esteja disposta a bloquear drivers que podem modificar a memória do kernel, mas o MSRC não esteja disposto a corrigir vulnerabilidades que podem fazer o mesmo.
Quando anunciei minha palestra no Black Hat Asia 2023 , PPLdump Is Dead. Long Live PPLdump, no Twitter cinco meses após o relatório do MSRC, a equipe do Windows Defender rapidamente entrou em contato para saber mais. Parece que a MSRC encerrou o caso sem informar a equipe do Defender, cujos produtos dependem do PPL para proteger centenas de milhões de máquinas Windows, sobre um desvio do PPL. Esse tipo de falha de comunicação não pode continuar.
Ferramentas prontas para uso
EDRSandBlast é uma ferramenta que transforma drivers vulneráveis em armas para contornar softwares AV e EDR. Ele pode modificar a memória do kernel para remover ganchos instalados pelo AV e EDR, cegando-os temporária ou permanentemente para atividades maliciosas no sistema.
Como discuti na minha palestra no Black Hat Asia, a MSRC demonstrou de fato que não está disposta a atender vulnerabilidades de administrador para PPL e de administrador para kernel e que é necessária a existência de ferramentas prontas para uso no GitHub para motivar a Microsoft a agir. Isso me levou a lançar o exploit de administrador para PPL PPLFault e a cadeia de exploit de administrador para kernel GodFault como ferramentas fáceis de usar no GitHub. Para resumir, a seguir os chamaremos de “vulnerabilidade PPL” e “vulnerabilidade kernel”, respectivamente.
No mesmo espírito de "ferramentas prontas para uso", para destacar a inconsistência de bloquear drivers vulneráveis conhecidos e, ao mesmo tempo, se recusar a corrigir cadeias de exploração do administrador para o kernel, estou lançando uma versão do EDRSandBlast que integra o PPLFault para demonstrar o mesmo resultado, sem drivers vulneráveis. Você pode ver aqui desabilitando o driver do Windows Defender. Meu objetivo ao divulgar isso é motivar o MSRC a tratar as vulnerabilidades do PPL e do kernel com maior urgência.
Mitigação
Lancei um pequeno driver de kernel junto com PPLFault e GodFault chamado NoFault, que quebra o exploit PPL. Até que o Windows seja corrigido, os fornecedores de antimalware podem empregar esse código para mitigar a vulnerabilidade PPL. Incorporamos a proteção do NoFault na versão mais recente do Elastic Endpoint/Defend - atualize para 8.9.0+ se ainda não o fez. Uma solução abrangente poderia ser fazer com que o gerenciador de memória aplicasse hashes de página para todas as imagens executáveis carregadas no PPL, um recurso já empregado para Processos Protegidos completos.
GodFault não é a primeira ferramenta a explorar a vulnerabilidade do kernel. O ANGRYORCHARD o utilizou pela primeira vez com a vulnerabilidade PPL KnownDLLs, agora corrigida. A vulnerabilidade do PPL já foi corrigida, mas a do kernel não. Consegui reutilizar facilmente a vulnerabilidade do kernel no GodFault - são apenas algumas linhas de código. Se isso não for corrigido, quaisquer explorações futuras de PPL serão imediatamente encadeadas ao kernel. Observe que o NoFault quebra a cadeia de exploração do kernel impedindo a execução necessária do código PPL, mas não corrige a vulnerabilidade do kernel em si.
Discussão
Tornar o EDRSandBlast sem driver é apenas um exemplo do que você pode fazer com tais explorações. Explorações do administrador para o kernel permitem um menu completo de recursos de malware que normalmente são impossíveis no modo de usuário, incluindo:
- Desabilite a telemetria do modo kernel, incluindo processos, threads, gerenciadores de objetos, sistemas de arquivos e retornos de chamada do registro. O EDRSandBlast faz algumas dessas coisas.
- Desabilitar registradores ETW do kernel
- Encerrar e/ou injetar malware nos processos anti-malware do PPL
- Ignore o LSA RunAsPPL para despejar credenciais ou adulterar o Credential Guard
- Ler/escrever a memória dos processos de trabalho da VM blindada, que são executados como PPL
- Execute malware com privilégios maiores que o antimalware, de modo que ele não possa ser verificado ou encerrado no modo de usuário
- Implementar comportamento de rootkit, como ocultar processos, arquivos e chaves de registro
- Obtenha acesso total de leitura e gravação à memória física
Esses recursos controlados pelo kernel, muitas vezes habilitados pelo BYOVD, são usados regularmente por criminosos para derrotar e degradar produtos de segurança , permitindo que eles prejudiquem pessoas e empresas. Vulnerabilidades de PPL e kernel permitem esses mesmos recursos, então o MSRC precisa atendê-los proativamente antes que agentes de ameaças abusem deles, não depois.
Não quero subestimar a dificuldade do problema: defender o kernel contra administradores é difícil e exigirá esforço contínuo à medida que novas soluções forem encontradas. Não será uma solução, mas sim uma corrida armamentista difícil e contínua. Felizmente, a Microsoft adotou recentemente uma nova filosofia de “não mais evitar as coisas difíceis” (link com registro de data e hora). Lidar com esses tipos de vulnerabilidades é uma “coisa difícil” que afeta a segurança do Windows hoje, e sobre a qual a Microsoft pode fazer algo enquanto simultaneamente avança em direção à sua visão de um futuro sem administração. Eles são uma grande empresa bem financiada, repleta de pessoas inteligentes, capazes de resolver vários problemas ao mesmo tempo.
Conclusão
A Microsoft criou a Vulnerable Driver Blocklist para impedir que administradores adulterem o kernel, mas eles não fizeram nada sobre uma cadeia de exploração entre administradores e kernel que foi relatada há mais de 11 meses. Ao remover o requisito de driver vulnerável do EDRSandBlast via GodFault, espero provar que as explorações do administrador para o kernel podem ser tão perigosas quanto os drivers vulneráveis e que o MSRC precisa levá-las a sério. Dado o objetivo do Windows 11 de segurança padrão e o fato de que a Lista de Bloqueio de Drivers Vulneráveis agora está habilitada por padrão, o MSRC precisa reconsiderar sua política de indiferença em relação a explorações de PPL e kernel.