Análise da vulnerabilidade 0day da Microsoft: pode ameaçar a segurança da infraestrutura Web3
No mês passado, o patch de segurança da Microsoft incluiu uma vulnerabilidade de elevação de privilégios win32k que é explorável na natureza. Esta vulnerabilidade parece existir apenas em versões iniciais do sistema e não pode ser acionada no Windows 11. Este tipo de exploração tem uma longa história; este artigo irá analisar como os atacantes podem continuar a explorar esta vulnerabilidade no contexto atual de novas medidas de mitigação que estão constantemente a melhorar. Concluímos todo o processo de análise no ambiente do Windows Server 2016.
A vulnerabilidade 0day refere-se a uma vulnerabilidade que não foi divulgada e corrigida, podendo ser explorada maliciosamente por hackers sem serem detectados, frequentemente com grande potencial de destruição. A vulnerabilidade 0day recentemente descoberta localiza-se ao nível do sistema Windows, permitindo que hackers obtenham controle total sobre o Windows. Uma vez controlado, isso pode resultar em roubo de informações pessoais, falhas no sistema, perda de dados, perdas financeiras, implantação de malware, entre outras consequências. Em uma pequena escala, pode levar ao roubo de chaves privadas e à transferência de ativos digitais; em uma escala maior, pode ameaçar todo o ecossistema Web3 que opera sobre a infraestrutura Web2.
A análise do patch indica que parece ser apenas um problema de contagem de referências a objetos que foi processado uma vez a mais. No entanto, ao examinar os comentários do código anterior, descobrimos que o código anterior apenas bloqueava o objeto da janela, sem bloquear o objeto do menu dentro do objeto da janela, o que pode ter levado a uma referência incorreta ao objeto do menu.
Analisando o contexto da função de vulnerabilidade, descobrimos que o menu passado para xxxEnableMenuItem() geralmente já está bloqueado na função superior. Então, qual objeto de menu devemos proteger aqui? Uma análise mais aprofundada revela que existem duas possibilidades para o menu retornado em xxxEnableMenuItem: o menu principal da janela ou o submenu do menu (, ou até mesmo o sub-submenu ).
Para construir o POC, projetamos uma estrutura de menu especial de quatro camadas e fizemos configurações especiais em cada menu para detecção através de funções. Quando xxxRedrawTitle retorna à camada do usuário, removemos a relação de referência entre o menu C e o menu B, liberando com sucesso o menu C. Assim, no ponto de retorno da função xxxEnableMenuItem, o objeto de menu C referenciado já está inválido.
No que diz respeito à implementação do EXP, consideramos principalmente duas direções: executar código shellcode e utilizar primitivas de leitura e escrita para modificar o endereço do token. Tendo em conta os mecanismos de segurança das versões mais recentes do Windows, optámos pela segunda. Todo o processo de exploração pode ser dividido em duas partes: como explorar a vulnerabilidade UAF para controlar o valor de cbwndextra e como estabelecer primitivas de leitura e escrita estáveis.
Nós utilizamos um layout de memória cuidadosamente projetado, aproveitando os objetos de nome de janela da classe de janela que ocupam e liberam objetos de menu, e encontramos a oportunidade de escrever dados na função xxxRedrawWindow. Para alcançar um layout de memória estável, projetamos uma estrutura de três objetos HWND consecutivos e utilizamos o endereço do identificador de kernel vazado na memória heap para determinar com precisão a ordem de arranjo dos objetos.
Na leitura e escrita de primitivos, utilizamos GetMenuBarInfo() para implementar leitura arbitrária e SetClassLongPtr() para implementar escrita arbitrária. Exceto pela operação de escrita que substitui o TOKEN, que depende do objeto de classe da segunda janela, todas as outras escritas utilizam o objeto de classe da primeira janela, implementando isso através de um deslocamento.
De um modo geral, embora a vulnerabilidade win32k tenha uma longa história, a Microsoft tentou reestruturar essa parte do código do núcleo usando Rust na versão de pré-visualização do Windows 11, e no futuro, esse tipo de vulnerabilidade pode ser eliminado. O processo de exploração dessa vulnerabilidade é relativamente simples, sendo o principal desafio como controlar a primeira escrita. A descoberta dessa vulnerabilidade pode depender de uma detecção de cobertura de código mais aprimorada. Para a detecção de vulnerabilidades, além de focar nos pontos-chave das funções disparadoras, a detecção de layouts de memória anômalos e leituras/escritas de deslocamento de dados também é uma possível abordagem para descobrir vulnerabilidades similares.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
16 Curtidas
Recompensa
16
5
Compartilhar
Comentário
0/400
TopBuyerBottomSeller
· 07-21 07:25
Mais uma razão para atualizar para o Windows 11~
Ver originalResponder0
FlatTax
· 07-20 03:35
Escândalo, velho Microsoft, não tente enganar.
Ver originalResponder0
SurvivorshipBias
· 07-20 03:34
De quem é este sistema que ainda usa win32k?
Ver originalResponder0
just_another_wallet
· 07-20 03:33
Quase explodiu a minha velha moeda, só de olhar me deu calafrios.
Ver originalResponder0
MrRightClick
· 07-20 03:14
O único sistema que até os cães não gostam é o Windows 11
Vulnerabilidade 0day da Microsoft exposta pode ameaçar a segurança da infraestrutura Web3
Análise da vulnerabilidade 0day da Microsoft: pode ameaçar a segurança da infraestrutura Web3
No mês passado, o patch de segurança da Microsoft incluiu uma vulnerabilidade de elevação de privilégios win32k que é explorável na natureza. Esta vulnerabilidade parece existir apenas em versões iniciais do sistema e não pode ser acionada no Windows 11. Este tipo de exploração tem uma longa história; este artigo irá analisar como os atacantes podem continuar a explorar esta vulnerabilidade no contexto atual de novas medidas de mitigação que estão constantemente a melhorar. Concluímos todo o processo de análise no ambiente do Windows Server 2016.
A vulnerabilidade 0day refere-se a uma vulnerabilidade que não foi divulgada e corrigida, podendo ser explorada maliciosamente por hackers sem serem detectados, frequentemente com grande potencial de destruição. A vulnerabilidade 0day recentemente descoberta localiza-se ao nível do sistema Windows, permitindo que hackers obtenham controle total sobre o Windows. Uma vez controlado, isso pode resultar em roubo de informações pessoais, falhas no sistema, perda de dados, perdas financeiras, implantação de malware, entre outras consequências. Em uma pequena escala, pode levar ao roubo de chaves privadas e à transferência de ativos digitais; em uma escala maior, pode ameaçar todo o ecossistema Web3 que opera sobre a infraestrutura Web2.
A análise do patch indica que parece ser apenas um problema de contagem de referências a objetos que foi processado uma vez a mais. No entanto, ao examinar os comentários do código anterior, descobrimos que o código anterior apenas bloqueava o objeto da janela, sem bloquear o objeto do menu dentro do objeto da janela, o que pode ter levado a uma referência incorreta ao objeto do menu.
Analisando o contexto da função de vulnerabilidade, descobrimos que o menu passado para xxxEnableMenuItem() geralmente já está bloqueado na função superior. Então, qual objeto de menu devemos proteger aqui? Uma análise mais aprofundada revela que existem duas possibilidades para o menu retornado em xxxEnableMenuItem: o menu principal da janela ou o submenu do menu (, ou até mesmo o sub-submenu ).
Para construir o POC, projetamos uma estrutura de menu especial de quatro camadas e fizemos configurações especiais em cada menu para detecção através de funções. Quando xxxRedrawTitle retorna à camada do usuário, removemos a relação de referência entre o menu C e o menu B, liberando com sucesso o menu C. Assim, no ponto de retorno da função xxxEnableMenuItem, o objeto de menu C referenciado já está inválido.
No que diz respeito à implementação do EXP, consideramos principalmente duas direções: executar código shellcode e utilizar primitivas de leitura e escrita para modificar o endereço do token. Tendo em conta os mecanismos de segurança das versões mais recentes do Windows, optámos pela segunda. Todo o processo de exploração pode ser dividido em duas partes: como explorar a vulnerabilidade UAF para controlar o valor de cbwndextra e como estabelecer primitivas de leitura e escrita estáveis.
Nós utilizamos um layout de memória cuidadosamente projetado, aproveitando os objetos de nome de janela da classe de janela que ocupam e liberam objetos de menu, e encontramos a oportunidade de escrever dados na função xxxRedrawWindow. Para alcançar um layout de memória estável, projetamos uma estrutura de três objetos HWND consecutivos e utilizamos o endereço do identificador de kernel vazado na memória heap para determinar com precisão a ordem de arranjo dos objetos.
Na leitura e escrita de primitivos, utilizamos GetMenuBarInfo() para implementar leitura arbitrária e SetClassLongPtr() para implementar escrita arbitrária. Exceto pela operação de escrita que substitui o TOKEN, que depende do objeto de classe da segunda janela, todas as outras escritas utilizam o objeto de classe da primeira janela, implementando isso através de um deslocamento.
De um modo geral, embora a vulnerabilidade win32k tenha uma longa história, a Microsoft tentou reestruturar essa parte do código do núcleo usando Rust na versão de pré-visualização do Windows 11, e no futuro, esse tipo de vulnerabilidade pode ser eliminado. O processo de exploração dessa vulnerabilidade é relativamente simples, sendo o principal desafio como controlar a primeira escrita. A descoberta dessa vulnerabilidade pode depender de uma detecção de cobertura de código mais aprimorada. Para a detecção de vulnerabilidades, além de focar nos pontos-chave das funções disparadoras, a detecção de layouts de memória anômalos e leituras/escritas de deslocamento de dados também é uma possível abordagem para descobrir vulnerabilidades similares.