Bypass de assinatura de driver no Windows pode permitir instalação de rootkits de kernel
(bleepingcomputer.com)- Mesmo em um Windows aparentemente com os patches mais recentes, se o processo do Windows Update for comprometido, ele pode ser revertido para componentes antigos do kernel, levando ao bypass do Driver Signature Enforcement e à distribuição de rootkits de kernel
- O pesquisador da SafeBreach, Alon Leviev, demonstrou ataques de downgrade/rollback de versão na BlackHat e na DEFCON, e a tomada de controle do Windows Update ainda não foi totalmente corrigida
- Um invasor com privilégios de administrador pode, mesmo no Windows 11 mais recente, trocar o ci.dll por uma versão sem patch e assim permitir o carregamento de drivers de kernel não assinados
- O Virtualization-based Security depende de bloqueio UEFI e de configurações de registro, portanto, em configurações sem a flag Mandatory, alterações no registro ou substituição de arquivos centrais podem servir como caminho de bypass
- A Microsoft está desenvolvendo uma atualização de segurança para descartar arquivos antigos do sistema VBS, mas o momento de lançamento é incerto devido à investigação das versões afetadas, testes de compatibilidade e prevenção de regressões
Ataque de downgrade que neutraliza o estado de patch mais recente
- O invasor pode controlar o processo do Windows Update e reintroduzir componentes vulneráveis antigos em um sistema que parece estar totalmente atualizado
- O sistema operacional continua aparentando estar completamente corrigido, mas na prática volta a ficar exposto a vulnerabilidades já corrigidas
- Os alvos do downgrade incluem DLLs, drivers e o NT kernel
- Alon Leviev publicou a ferramenta Windows Downdate, mostrando que é possível criar downgrades personalizados
Bypass do Driver Signature Enforcement e risco de rootkit
- Leviev demonstrou que ainda é possível contornar o Driver Signature Enforcement(DSE) mesmo após o reforço da segurança do kernel
- Se o bypass do DSE tiver sucesso, o invasor pode carregar drivers de kernel não assinados
- Esses drivers podem ser usados para distribuir malware do tipo rootkit capaz de desativar controles de segurança e dificultar a detecção da invasão
- Leviev chama seu método de
"ItsNotASecurityBoundary" DSE bypass- Esse método faz o downgrade do exploit ItsNotASecurityBoundary
- Esse exploit explora uma classe de vulnerabilidades do Windows de falsa imutabilidade de arquivos (false file immutability), identificada por Gabriel Landau, da Elastic, permitindo execução arbitrária de código com privilégios de kernel
Substituição do ci.dll e condição de reinicialização
- Em uma nova pesquisa, Leviev mostrou que um invasor com privilégios de administrador pode abusar do processo do Windows Update para contornar a proteção do DSE até mesmo em um Windows 11 totalmente atualizado
- O ponto central é substituir o ci.dll, que impõe o DSE, por uma versão sem patch que ignora a assinatura de drivers
- Depois que o componente é rebaixado para uma versão vulnerável, é necessária uma reinicialização do sistema, como em um processo normal de atualização
- Leviev publicou uma demonstração em um sistema Windows 11 23H2 totalmente corrigido, revertendo por downgrade o patch do DSE e depois explorando esse componente
Caminho de bypass quando a configuração do VBS é fraca
- Leviev também aborda formas de desativar ou contornar o Virtualization-based Security(VBS) da Microsoft
- O VBS cria um ambiente isolado para proteger recursos obrigatórios e ativos de segurança do Windows
- Entre os alvos protegidos estão o skci.dll, mecanismo de integridade de código do kernel de segurança, e credenciais autenticadas de usuários
- O VBS normalmente depende de proteções como bloqueio UEFI e configuração de registro
- Se o VBS não estiver configurado com a flag “Mandatory” de segurança máxima, ele pode ser desativado por meio da modificação de chaves específicas do registro
- Se o VBS estiver apenas parcialmente ativado, arquivos centrais do VBS como SecureKernel.exe podem ser substituídos por versões comprometidas para interferir em seu funcionamento
- Esse estado pode abrir caminho para o bypass “ItsNotASecurityBoundary” e para a substituição do ci.dll
Resposta da Microsoft e lacunas restantes
- Embora CVE-2024-21302 e CVE-2024-38202, usadas nos ataques de downgrade divulgados na BlackHat e na DEFCON, tenham sido tratadas, o problema de tomada de controle do Windows Update ainda permanece
- A Microsoft considerou que esse problema não ultrapassa um limite de segurança definido, e julgou que obter execução de código de kernel com privilégios de administrador não constitui uma violação de limite de segurança
- Leviev enfatiza que, até que a Microsoft corrija o problema, as soluções de segurança devem monitorar e detectar ataques de downgrade
- A Microsoft afirmou que está desenvolvendo ativamente medidas de mitigação para bloquear esse risco
- A empresa está desenvolvendo uma atualização de segurança para descartar arquivos antigos e sem patch do sistema VBS
- Esse processo inclui investigar todas as versões afetadas, desenvolver a atualização e realizar testes de compatibilidade
- Para proteger os clientes e minimizar interrupções operacionais, é preciso evitar falhas de integração ou regressões
- Devido à complexidade do problema, ainda não está claro quando a atualização será disponibilizada
- Em uma atualização de 27 de outubro, ficou mais claro que o ataque exige privilégios de administrador, e foram adicionadas informações para reduzir a confusão de que a Microsoft não estaria tomando medidas de mitigação
1 comentários
Comentários do Hacker News
A MS diz que o UAC não é uma fronteira de segurança, no sentido de que isso envolve alguns usuários se elevarem a privilégios de administrador
Mas, como neste caso, também diz que ir de administrador para kernel não é uma fronteira de segurança e, ao mesmo tempo, afirma que a exigência de assinatura de driver é um recurso de segurança
Aqui, justamente esse recurso está sendo contornado, mas ainda assim dizem que nenhuma fronteira de segurança foi cruzada, então seria bom explicarem isso de forma coerente
O UAC já é voltado para usuários que pertencem ao grupo de administradores, não é um recurso para “alguns usuários se tornarem administradores”
A fronteira de segurança está em torno dos usuários padrão, não dos usuários administradores
Pode não agradar, mas, se você quer uma fronteira de segurança, basta não colocar o usuário no grupo Administrators
Acho que conflitos de opinião geralmente envolvem incompatibilidade de definições e incompatibilidade de sistemas de valores
Neste caso, a Microsoft dá valor a minimizar esse problema, e, se isso está no topo das prioridades dela, a decisão pode parecer consistente dentro desse critério
Incompatibilidades de definição são relativamente fáceis de resolver. Por exemplo, ao discutir o projeto de um sistema de software, todos podem usar termos de design patterns, mas, se cada um entende A como A′ ou A″, pode surgir uma grande confusão
O mesmo vale para software open source gerido por empresas
A verdadeira pergunta é por que as pessoas gastam energia intelectual fazendo pesquisa de segurança gratuita para a Microsoft em vez de usar isso para melhorar o Linux desktop
UAC e sudo são ambos mais parecidos com janelas de consentimento de cookies em nível de sistema operacional, e eu diria que seria melhor eliminar todos eles
Em vez de insistir em elevação de privilégios baseada no usuário, como UAC/sudo, deveríamos fazer sandbox de apps, como no Android e no iOS, não de usuários
Também é interessante notar que, tanto no Windows quanto no Linux, uma conta local comum acaba funcionando, na prática, quase como privilégios equivalentes a root
No Linux, treinam você a colocar sudo antes de tarefas de sistema, e no Windows treinam você a clicar e passar pelo prompt do UAC
Fico pensando quando foi a última vez que o sudo disse “não” a alguém por algum motivo que não fosse erro ao digitar a senha
O UAC é uma UI gerenciada pelo sistema, enquanto o sudo é só um programa, então o UAC é um pouco melhor nesse ponto, já que um invasor pode trocar o sudo por um alias malicioso de shell e roubar a senha
Com as configurações padrão, seria mais confortável para o usuário e mais condizente com a segurança real remover sudo e UAC e parar de fingir que existe uma fronteira de segurança sólida entre root e a conta local principal do usuário
No terminal, também é possível usar pkexec em vez de sudo
Em vez de executar comandos arbitrários como root, o aplicativo pode usar ações predefinidas como
org.freedesktop.udisks2.filesystem-mount, e mostrar ao usuário, em uma mensagem localizada, o que o app está tentando fazer para que ele decida se permite ou nãoO administrador do sistema também pode configurar certas ações para não exigir autenticação, como atualização do flatpak, ou, ao contrário, bloquear completamente ações específicas
A suposição subjacente é que o usuário que realizou a instalação deve controlar o sistema. Afinal, ele poderia simplesmente não ter feito a instalação
Assim como o UAC, o sudo não é um mecanismo para dizer “não” à pessoa. Ambos existem para permitir que a pessoa diga “não” quando um administrador tenta executar uma tarefa administrativa inesperada
Quem não tem privilégios administrativos, mas precisa desse tipo de tarefa, deve obter aprovação do administrador
Se não for um sistema de uso individual, quem configura a máquina precisa criar uma conta restrita para uso cotidiano
Não preciso virar root com frequência e, quando preciso, normalmente faço várias tarefas em sequência
Vejo o sudo como útil em computadores multiusuário, como máquinas corporativas de propriedade e gestão da empresa, quando o administrador quer permitir que alguns usuários façam apenas tarefas privilegiadas limitadas
O principal motivo para sempre usar uma conta que não seja root é evitar erros, mais do que segurança. É para não apagar ou sobrescrever arquivos sem querer
Por isso, acho totalmente justificável ter que digitar a senha quando, raramente, preciso trocar de papel
Só que sem o truque de “pressione ctrl+alt+delete para confirmar”
O Windows tem a vantagem de não exigir que tudo seja feito por script
Se quiser, você pode encapsular todas as ferramentas com
runas/System.Management.Automation.PSCredential, mas na maioria dos casos isso não é necessárioParece que o kernel impõe as regras de compartilhamento de arquivos verificando, ao abrir um arquivo, todos os handles já abertos para detectar bloqueios obrigatórios conflitantes, mas não verifica mapeamentos de memória com permissões conflitantes
É um erro, mas a correção parece relativamente simples
Curiosamente, o Linux acabou de remover os últimos vestígios de bloqueio obrigatório. Agora, escrever em um executável carregado não retorna mais EBUSY
É interessante que a mesma funcionalidade, em um sistema operacional, sustenta parte da infraestrutura de segurança, enquanto, em outro, é um resquício legado que precisa ser removido
Não sou especialista em segurança e entendo só o básico, mas parece que estou deixando passar alguma coisa no modelo conceitual
Fico me perguntando por que o Windows é tão fácil de invadir
O Windows é um alvo lucrativo e o sistema operacional de desktop mais amplamente implantado, especialmente em ambientes corporativos, então vale investir muito tempo e dinheiro para comprometê-lo
Não houve investimento suficiente para criar uma plataforma de computação realmente segura
Uma plataforma de segurança ideal deveria oferecer builds reproduzíveis em uma infraestrutura verificável publicamente, como o fdroid, virtualizar todos os aplicativos não confiáveis dentro de sandboxes e implementar um modelo de privilégios mínimos
Hoje estamos no pior estado de segurança. Em todos os níveis, da ME da CPU aos componentes UEFI e aos drivers de terceiros do sistema operacional, roda código inseguro de origem desconhecida e provavelmente sem testes suficientes
SeL4 tem um kernel totalmente verificado, mas ainda não faz virtualização
Uma parte considerável do malware para Windows depende, em algum momento, de drivers vulneráveis de terceiros em nível de kernel
Em contraste, no Linux módulos de kernel de terceiros são raros e malvistos, e no macOS isso é simplesmente proibido
E é fácil demais convencer o usuário a executar qualquer coisa com privilégios elevados
Só foi tratado depois que o analista da CERT Will Dormann perguntou por quê, em 2022
Agora é atualizado regularmente, mas continua sendo absurdo https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
Neste caso, concordo em certa medida com a posição da Microsoft
Um administrador pode fazer coisas arbitrárias no computador, não é exatamente novidade
Não sei se há alguma diferença de detalhe que aumente a gravidade
Também vale a leitura de um texto do Raymond Chen que resume esse tipo de ataque
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Se alguém já pode substituir qualquer DLL arbitrária do sistema, então as pré-condições para esse “exploit” funcionar já foram satisfeitas, e nesse ponto já era
A capacidade de contornar a assinatura de drivers provavelmente estaria entre as menores das preocupações
O ataque parece suspeitosamente simples
A ideia é enganar o processo de atualização para instalar um componente de kernel antigo com vulnerabilidades conhecidas
Mesmo sem ser especialista, dá a impressão de que a Microsoft já deveria ter pensado nisso e ter uma lista de bloqueio ou algum mecanismo de revogação
A questão central é se a causa raiz é um problema de projeto do sistema operacional, ou uma falha de processo quebrado ou incapaz de gravar hashes ruins no lugar certo
Se for a segunda hipótese, é muito mais fácil de corrigir, mas, como sempre, o comunicado de segurança levemente maquiado parece sugerir a primeira
É difícil acreditar que a Microsoft esteja contestando isso quando existe uma demonstração
Essa conta do Vimeo tem várias outras descobertas de segurança. Por exemplo, tem uma em que o WhatsApp executa um script Python; fico curioso se é real ou fraude
Existe o critério de que “processos e usuários administradores são considerados parte da base computacional confiável (TCB) do Windows e, portanto, não são fortemente isolados da fronteira do kernel” [0]
Há também outro caso recente
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Lembro do sufoco que todo mundo passou quando a Microsoft exigiu pela primeira vez assinatura de drivers no Windows [1]
Eu estava criando um driver de inspeção profunda de pacotes para [2], e à primeira vista o processo parecia ainda mais rigoroso que a aprovação de apps na Apple Store, e a documentação não era nada clara
Pensando nos recursos que as empresas gastaram para atender às exigências da Microsoft, ver isso ser explorado dessa forma parece um grande retrocesso
Vulnerabilidades sempre vão existir, mas teria sido reconfortante se alguém tivesse encontrado isso antes
Palmas para Alon Leviev e a SafeBreach por terem descoberto
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
“ser possível ao obter execução de código no kernel como administrador” no fim das contas só quer dizer o banal: um usuário root pode instalar um rootkit
Não podemos esquecer de dar um nome chamativo para isso. Ah, e o pesquisador já publicou uma ferramenta chamada Windows Downdate
Então dá para dizer que já garantiu seus 0xF minutos de fama
Contas de usuário também são apenas objetos dentro do sistema operacional, e mesmo que se restrinja a conta de superusuário, ainda é possível projetar um sistema operacional que imponha certas regras a todas as contas de usuário
Por exemplo, pode haver motivos legítimos para proteger certos segredos, como faz o TPM, mesmo quando a conta de administrador foi comprometida, ou para impedir que um administrador deixe o sistema sem possibilidade de inicialização por engano
Um objetivo mais controverso seria impor DRM
É exatamente isso que a Microsoft está tentando fazer no Windows. O sistema operacional tenta impedir que a conta de administrador interfira no kernel ou instale um rootkit
Nesta discussão, é sempre importante distinguir entre a conta de usuário administradora dentro do sistema operacional e a pessoa “administradora” com acesso físico ou ao hardware
0xFNão está errado, mas é uma escolha curiosa, então bateu a curiosidade. Queria saber se foi só por estilo
Quando preciso usar Windows, sempre parto do princípio de que aquele computador já foi comprometido