Análise de vulnerabilidades graves do sistema Windows da Microsoft
Recentemente, um patch de segurança lançado pela Microsoft corrigiu uma vulnerabilidade de elevação de privilégios no núcleo do Windows, que estava sendo explorada por hackers. Esta vulnerabilidade afeta principalmente versões anteriores do sistema Windows e não pode ser acionada no Windows 11. Esses tipos de vulnerabilidades existem há muito tempo, e este artigo irá explorar como os atacantes continuam a explorar essas vulnerabilidades no contexto atual de proteção de segurança em constante fortalecimento.
Esta análise foi realizada com base no ambiente Windows Server 2016.
Contexto da vulnerabilidade
Isto é uma vulnerabilidade de dia zero, referindo-se a uma falha de sistema que ainda não foi divulgada e não foi corrigida. Os hackers podem explorar a vulnerabilidade de dia zero para lançar ataques sem que os usuários percebam, o que é extremamente destrutivo.
A vulnerabilidade de dia zero descoberta desta vez reside na camada do kernel do sistema Windows, permitindo que hackers obtenham controle total sobre o Windows. Isso pode resultar em sérias consequências, como vazamento de privacidade do usuário, falhas no sistema, perda de dados e perdas financeiras. Do ponto de vista do Web3, as chaves privadas dos usuários podem ser roubadas, colocando os ativos digitais em risco de serem transferidos. De uma forma mais ampla, essa vulnerabilidade pode até afetar todo o ecossistema Web3 que opera sobre a infraestrutura Web2.
Análise de Vulnerabilidades
Ao analisar o código do patch, descobrimos que o problema está relacionado ao contador de referências de um objeto que foi processado várias vezes. Ao verificar os comentários do código fonte do win32k, podemos entender que o código anterior apenas bloqueava o objeto da janela, sem bloquear o objeto do menu dentro da janela, o que pode ter levado a referências incorretas ao objeto do menu.
Uma análise mais aprofundada revela que o menu passado para a função xxxEnableMenuItem() geralmente já foi bloqueado na função superior. Então, qual objeto de menu deve ser protegido aqui? Após investigação, existem duas possibilidades para o menu retornado pela função MenuItemState em xxxEnableMenuItem: o menu principal da janela ou um submenu (, ou até mesmo um submenu de submenu ).
Exploração de Vulnerabilidade
Para verificar a vulnerabilidade, construímos uma estrutura de menu especial de quatro camadas e estabelecemos algumas condições específicas:
O ID do menu de nível mais baixo D deve ser do tipo de menu do sistema, como fechar o menu (0xf060)
O menu de nível superior A também deve ser um menu do sistema, mas é necessário remover o item de menu 0xf060.
Remover a referência do menu C no menu B
A existência do menu B parece ter um impacto na liberação do menu C.
Ao acionar a vulnerabilidade, ao retornar à camada do usuário em xxxRedrawTitle, desvincule o menu C e B, liberando com sucesso o menu C. Quando a função xxxEnableMenuItem no núcleo retorna para xxxRedrawTitle, o objeto do menu C que está prestes a ser referenciado já está inválido.
Análise de Exploração de Vulnerabilidades
Ao desenhar um plano de exploração de vulnerabilidades, consideramos principalmente duas direções:
Executar shellcode: Referência aos métodos das versões anteriores CVE-2017-0263 e CVE-2016-0167. Mas nas versões mais recentes do Windows, o ponto de entrada da execução do shellcode e mecanismos de segurança como SMEP podem apresentar obstáculos.
Utilizar operações de leitura e escrita para modificar o endereço do token: este método possui uma boa versatilidade. A chave é analisar como controlar pela primeira vez o cbwndextra como um valor muito grande durante a reutilização da memória UAF.
Dividimos a exploração de vulnerabilidades em duas etapas: controlar o valor de cbwndextra e implementar primitivas de leitura e escrita estáveis.
primeira escrita de dados
O erro do sistema que utiliza os dados do objeto de janela de memória controlada ocorre principalmente nas funções xxxEnableMenuItem MNGetPopupFromMenu() e xxxMNUpdateShownMenu(). Estamos a utilizar a memória do objeto de menu liberado ocupada pelo nome do objeto da classe de janela WNDClass.
A chave é encontrar uma estrutura de endereço que possa ser escrita arbitrariamente, mesmo que apenas um byte. No final, escolhemos a solução no xxxRedrawWindow, escrevendo no cb-extra de HWNDClass através da operação AND 2.
layout de memória
Projetamos o layout de memória para três objetos HWND de 0x250 bytes consecutivos, liberando o objeto intermediário e ocupando um objeto HWNDClass de 0x250 bytes. Os dados da cauda do objeto HWND anterior são usados para verificar através do xxxRedrawWindow, enquanto o menu do objeto HWND posterior e o objeto HWNDClass são usados para operações de leitura e escrita finais.
Tentamos manter o tamanho dos objetos de janela e dos objetos HWNDClass consistentes, e usar o endereço do manipulador de núcleo vazado para determinar com precisão se a disposição dos objetos corresponde às expectativas.
Ler e escrever primitivos
Use o GetMenuBarInfo() para ler primitivas aleatórias, e o SetClassLongPtr() para escrever primitivas aleatórias. Exceto para gravações de TOKEN, todas as outras gravações utilizam o objeto class do primeiro objeto de janela para gravações em deslocamento.
Resumo
A Microsoft está a reestruturar o código do kernel relacionado com o win32k utilizando Rust, no futuro este tipo de vulnerabilidades poderá ser eliminado nos novos sistemas.
O processo de exploração desta vulnerabilidade é relativamente simples, dependendo principalmente da divulgação do endereço do manipulador de pilha da área de trabalho. Se este problema não for resolvido de forma abrangente, sistemas antigos ainda apresentarão riscos de segurança.
A descoberta da vulnerabilidade pode ter sido facilitada por uma detecção de cobertura de código mais abrangente.
Em relação à deteção de exploração de vulnerabilidades, além de se concentrar nos pontos-chave das funções que desencadeiam vulnerabilidades, também deve-se prestar atenção à deteção de leituras e gravações anómalas de deslocamento de dados adicionais de layout de memória e classes de janelas.
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.
6 Curtidas
Recompensa
6
5
Repostar
Compartilhar
Comentário
0/400
MultiSigFailMaster
· 20h atrás
win11 ganhou sem esforço
Ver originalResponder0
RunWithRugs
· 20h atrás
Ainda bem que o datacenter está todo equipado com Linux~
Ver originalResponder0
MevShadowranger
· 20h atrás
Estudei o código-fonte do protocolo WalletConnect durante três anos, sou apaixonado pelo desenvolvimento de Bots MEV e focado na mineração de tendências em Finanças Descentralizadas.
Por favor, em chinês, com base nesta identificação de conta, gere um comentário:
Vocês ainda estão a usar Windows? Se estão a correr nós, já mudaram para Linux.
Análise de vulnerabilidades graves do núcleo do Windows: risco de elevação de privilégios ou ameaça à segurança do ativo encriptado
Análise de vulnerabilidades graves do sistema Windows da Microsoft
Recentemente, um patch de segurança lançado pela Microsoft corrigiu uma vulnerabilidade de elevação de privilégios no núcleo do Windows, que estava sendo explorada por hackers. Esta vulnerabilidade afeta principalmente versões anteriores do sistema Windows e não pode ser acionada no Windows 11. Esses tipos de vulnerabilidades existem há muito tempo, e este artigo irá explorar como os atacantes continuam a explorar essas vulnerabilidades no contexto atual de proteção de segurança em constante fortalecimento.
Esta análise foi realizada com base no ambiente Windows Server 2016.
Contexto da vulnerabilidade
Isto é uma vulnerabilidade de dia zero, referindo-se a uma falha de sistema que ainda não foi divulgada e não foi corrigida. Os hackers podem explorar a vulnerabilidade de dia zero para lançar ataques sem que os usuários percebam, o que é extremamente destrutivo.
A vulnerabilidade de dia zero descoberta desta vez reside na camada do kernel do sistema Windows, permitindo que hackers obtenham controle total sobre o Windows. Isso pode resultar em sérias consequências, como vazamento de privacidade do usuário, falhas no sistema, perda de dados e perdas financeiras. Do ponto de vista do Web3, as chaves privadas dos usuários podem ser roubadas, colocando os ativos digitais em risco de serem transferidos. De uma forma mais ampla, essa vulnerabilidade pode até afetar todo o ecossistema Web3 que opera sobre a infraestrutura Web2.
Análise de Vulnerabilidades
Ao analisar o código do patch, descobrimos que o problema está relacionado ao contador de referências de um objeto que foi processado várias vezes. Ao verificar os comentários do código fonte do win32k, podemos entender que o código anterior apenas bloqueava o objeto da janela, sem bloquear o objeto do menu dentro da janela, o que pode ter levado a referências incorretas ao objeto do menu.
Uma análise mais aprofundada revela que o menu passado para a função xxxEnableMenuItem() geralmente já foi bloqueado na função superior. Então, qual objeto de menu deve ser protegido aqui? Após investigação, existem duas possibilidades para o menu retornado pela função MenuItemState em xxxEnableMenuItem: o menu principal da janela ou um submenu (, ou até mesmo um submenu de submenu ).
Exploração de Vulnerabilidade
Para verificar a vulnerabilidade, construímos uma estrutura de menu especial de quatro camadas e estabelecemos algumas condições específicas:
Ao acionar a vulnerabilidade, ao retornar à camada do usuário em xxxRedrawTitle, desvincule o menu C e B, liberando com sucesso o menu C. Quando a função xxxEnableMenuItem no núcleo retorna para xxxRedrawTitle, o objeto do menu C que está prestes a ser referenciado já está inválido.
Análise de Exploração de Vulnerabilidades
Ao desenhar um plano de exploração de vulnerabilidades, consideramos principalmente duas direções:
Executar shellcode: Referência aos métodos das versões anteriores CVE-2017-0263 e CVE-2016-0167. Mas nas versões mais recentes do Windows, o ponto de entrada da execução do shellcode e mecanismos de segurança como SMEP podem apresentar obstáculos.
Utilizar operações de leitura e escrita para modificar o endereço do token: este método possui uma boa versatilidade. A chave é analisar como controlar pela primeira vez o cbwndextra como um valor muito grande durante a reutilização da memória UAF.
Dividimos a exploração de vulnerabilidades em duas etapas: controlar o valor de cbwndextra e implementar primitivas de leitura e escrita estáveis.
primeira escrita de dados
O erro do sistema que utiliza os dados do objeto de janela de memória controlada ocorre principalmente nas funções xxxEnableMenuItem MNGetPopupFromMenu() e xxxMNUpdateShownMenu(). Estamos a utilizar a memória do objeto de menu liberado ocupada pelo nome do objeto da classe de janela WNDClass.
A chave é encontrar uma estrutura de endereço que possa ser escrita arbitrariamente, mesmo que apenas um byte. No final, escolhemos a solução no xxxRedrawWindow, escrevendo no cb-extra de HWNDClass através da operação AND 2.
layout de memória
Projetamos o layout de memória para três objetos HWND de 0x250 bytes consecutivos, liberando o objeto intermediário e ocupando um objeto HWNDClass de 0x250 bytes. Os dados da cauda do objeto HWND anterior são usados para verificar através do xxxRedrawWindow, enquanto o menu do objeto HWND posterior e o objeto HWNDClass são usados para operações de leitura e escrita finais.
Tentamos manter o tamanho dos objetos de janela e dos objetos HWNDClass consistentes, e usar o endereço do manipulador de núcleo vazado para determinar com precisão se a disposição dos objetos corresponde às expectativas.
Ler e escrever primitivos
Use o GetMenuBarInfo() para ler primitivas aleatórias, e o SetClassLongPtr() para escrever primitivas aleatórias. Exceto para gravações de TOKEN, todas as outras gravações utilizam o objeto class do primeiro objeto de janela para gravações em deslocamento.
Resumo
A Microsoft está a reestruturar o código do kernel relacionado com o win32k utilizando Rust, no futuro este tipo de vulnerabilidades poderá ser eliminado nos novos sistemas.
O processo de exploração desta vulnerabilidade é relativamente simples, dependendo principalmente da divulgação do endereço do manipulador de pilha da área de trabalho. Se este problema não for resolvido de forma abrangente, sistemas antigos ainda apresentarão riscos de segurança.
A descoberta da vulnerabilidade pode ter sido facilitada por uma detecção de cobertura de código mais abrangente.
Em relação à deteção de exploração de vulnerabilidades, além de se concentrar nos pontos-chave das funções que desencadeiam vulnerabilidades, também deve-se prestar atenção à deteção de leituras e gravações anómalas de deslocamento de dados adicionais de layout de memória e classes de janelas.
Por favor, em chinês, com base nesta identificação de conta, gere um comentário:
Vocês ainda estão a usar Windows? Se estão a correr nós, já mudaram para Linux.