Análise da vulnerabilidade de dia zero do sistema Windows da Microsoft: pode causar um impacto significativo no ecossistema Web3
No mês passado, uma atualização de segurança da Microsoft corrigiu uma vulnerabilidade de elevação de privilégios no núcleo do Windows que estava sendo explorada maliciosamente. Esta vulnerabilidade afeta principalmente versões mais antigas do sistema Windows, e o Windows 11 parece não ser afetado. Este artigo analisará como, no contexto do fortalecimento contínuo das medidas de segurança atuais, os atacantes podem continuar a explorar esse tipo de vulnerabilidade.
Concluímos todo o trabalho de análise no ambiente Windows Server 2016.
Uma vulnerabilidade de dia zero refere-se a uma vulnerabilidade de sistema que ainda não foi descoberta e corrigida, semelhante ao conceito de negociação T+0 nos mercados financeiros. Uma vez que uma vulnerabilidade de dia zero é explorada maliciosamente, geralmente causa danos significativos. A vulnerabilidade de dia zero do sistema Windows descoberta desta vez permite que os atacantes obtenham controle total do sistema.
As consequências de ter o sistema controlado por atacantes são graves, incluindo, mas não se limitando a, vazamento de privacidade pessoal, perda de dados devido a falhas no sistema, perdas financeiras e inserção de malware. Para os usuários individuais, isso pode resultar no roubo de chaves privadas de criptomoedas e na transferência de ativos digitais; em uma escala maior, essa vulnerabilidade pode até afetar todo o ecossistema Web3 baseado na infraestrutura Web2.
Análise de Patch
Ao analisar o patch, descobrimos que o problema parece ser apenas um contagem de referência de um objeto que foi processada uma vez a mais. Como o win32k é um código mais antigo, podemos encontrar alguns comentários de código anteriores que indicam 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 levar a uma referência incorreta do objeto do menu.
Prova de Conceito de Exploração de Vulnerabilidades(PoC) implementação
Analisando o contexto da função de vulnerabilidade, descobrimos que o menu passado para xxxEnableMenuItem() geralmente já foi bloqueado na função superior. Então, qual objeto de menu estamos realmente tentando proteger aqui?
Ao analisar mais a fundo o processo de tratamento do objeto de menu em xxxEnableMenuItem, descobrimos que a função MenuItemState retorna dois tipos possíveis de menu: o menu principal da janela ou o submenu (, ou até mesmo um submenu de submenu ).
No PoC, construímos uma estrutura de menu especial em quatro camadas, onde os menus adjacentes têm uma relação pai-filho. Estes menus têm algumas características específicas, que são detectadas e avaliadas através da função xxxEnableMenuItem.
Ao retornar à camada do usuário em xxxRedrawTitle, removemos a relação de referência entre o menu C e o menu B, liberando com sucesso o menu C. No final, quando a função xxxEnableMenuItem no núcleo retorna para a função xxxRedrawTitle, o objeto do menu C que estava prestes a ser referenciado já está inválido.
Exploração de Vulnerabilidades(Exploit)Implementação
Antes de determinar a abordagem de exploração, geralmente fazemos alguns julgamentos teóricos preliminares para evitar desperdiçar tempo em soluções inviáveis. Esta exploração de vulnerabilidades considera principalmente duas direções:
Executar código shellcode: consulte os CVEs anteriores CVE-2017-0263 e CVE-2016-0167. No entanto, em versões mais recentes do Windows, esse método pode enfrentar alguns problemas difíceis de resolver.
Utilizando primitivas de leitura e escrita para modificar o endereço do token: nos últimos anos, já existem métodos públicos disponíveis para referência. O layout da memória heap de desktop e as primitivas de leitura e escrita têm uma utilidade a longo prazo. Precisamos principalmente analisar como controlar pela primeira vez cbwndextra como um valor extremamente grande quando a memória UAF é reutilizada.
Dividimos todo o processo de exploração em duas questões: como explorar a vulnerabilidade UAF para controlar o valor cbwndextra e, após controlar o valor cbwndextra, como implementar primitivas de leitura e escrita estáveis.
No final, escolhemos escrever o cb-extra de HWNDClass através da operação AND 2 no sinalizador na função xxxRedrawWindow. Isso se deve ao fato de o cb-extra de HWNDClass ter um deslocamento pequeno, podendo controlar os dados de memória do objeto anterior através do layout de memória, permitindo assim a verificação do sinalizador do objeto na função xxxRedrawWindow.
Para alcançar um layout de memória estável, projetamos pelo menos três objetos HWND de 0x250 bytes consecutivos. Após liberar o objeto intermediário, ocupamos essa posição com um objeto HWNDClass de 0x250 bytes. Os dados de cauda do objeto HWND anterior são usados para verificação através da bandeira xxxRedrawWindow, enquanto o objeto de menu do próximo HWND e o objeto HWNDClass são usados como meio para as operações de leitura e escrita finais.
Tentamos manter o tamanho do objeto da janela consistente com o objeto HWNDClass e garantir que os dados de extensão do objeto da janela sejam grandes o suficiente. Através do endereço do manipulador de núcleo que vaza na memória heap, podemos determinar com precisão se o objeto da janela solicitado está disposto na ordem esperada.
Na leitura e escrita de primitivos, usamos GetMenuBarInfo() para implementar leitura arbitrária e SetClassLongPtr() para implementar escrita arbitrária. Exceto pela operação de escrita que substitui TOKEN e depende do objeto de classe da segunda janela, outras escritas utilizam o objeto de classe da primeira janela através de deslocamento.
Resumo
Estado atual do win32k: A Microsoft está tentando reestruturar o código do núcleo relacionado na versão de pré-visualização do Windows 11 usando Rust, e o novo sistema pode eliminar esse tipo de vulnerabilidade no futuro.
O processo de exploração de vulnerabilidades é relativamente simples: além de como controlar a primeira escrita, que requer tentativas cuidadosas, não é necessário usar novas técnicas de exploração. Este tipo de vulnerabilidade depende fortemente da divulgação do endereço do manipulador de pilha de desktop.
Descoberta de vulnerabilidades: supõe-se que possa depender de uma deteção de cobertura de código mais robusta. Assim que a API do sistema conseguir alcançar o ponto de vulnerabilidade mais profundo no caminho de execução da função alvo, e o objeto da janela estiver em um estado de referência aninhada múltipla, essa vulnerabilidade poderá ser descoberta através de testes de fuzz.
Outras maneiras de descobrir: Além da detecção dos pontos-chave da função que dispara a vulnerabilidade, a detecção de anomalias de leitura e escrita em layouts de memória não comuns e em dados adicionais de janelas ou classes de janelas também pode ser uma das formas de descobrir vulnerabilidades semelhantes.
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.
12 Curtidas
Recompensa
12
2
Compartilhar
Comentário
0/400
AltcoinHunter
· 19h atrás
Ver mas não dizer que já sou um idiota no mundo crypto.
Análise de vulnerabilidades zero-day do Windows: o ecossistema Web3 pode ser gravemente afetado
Análise da vulnerabilidade de dia zero do sistema Windows da Microsoft: pode causar um impacto significativo no ecossistema Web3
No mês passado, uma atualização de segurança da Microsoft corrigiu uma vulnerabilidade de elevação de privilégios no núcleo do Windows que estava sendo explorada maliciosamente. Esta vulnerabilidade afeta principalmente versões mais antigas do sistema Windows, e o Windows 11 parece não ser afetado. Este artigo analisará como, no contexto do fortalecimento contínuo das medidas de segurança atuais, os atacantes podem continuar a explorar esse tipo de vulnerabilidade.
Concluímos todo o trabalho de análise no ambiente Windows Server 2016.
Uma vulnerabilidade de dia zero refere-se a uma vulnerabilidade de sistema que ainda não foi descoberta e corrigida, semelhante ao conceito de negociação T+0 nos mercados financeiros. Uma vez que uma vulnerabilidade de dia zero é explorada maliciosamente, geralmente causa danos significativos. A vulnerabilidade de dia zero do sistema Windows descoberta desta vez permite que os atacantes obtenham controle total do sistema.
As consequências de ter o sistema controlado por atacantes são graves, incluindo, mas não se limitando a, vazamento de privacidade pessoal, perda de dados devido a falhas no sistema, perdas financeiras e inserção de malware. Para os usuários individuais, isso pode resultar no roubo de chaves privadas de criptomoedas e na transferência de ativos digitais; em uma escala maior, essa vulnerabilidade pode até afetar todo o ecossistema Web3 baseado na infraestrutura Web2.
Análise de Patch
Ao analisar o patch, descobrimos que o problema parece ser apenas um contagem de referência de um objeto que foi processada uma vez a mais. Como o win32k é um código mais antigo, podemos encontrar alguns comentários de código anteriores que indicam 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 levar a uma referência incorreta do objeto do menu.
Prova de Conceito de Exploração de Vulnerabilidades(PoC) implementação
Analisando o contexto da função de vulnerabilidade, descobrimos que o menu passado para xxxEnableMenuItem() geralmente já foi bloqueado na função superior. Então, qual objeto de menu estamos realmente tentando proteger aqui?
Ao analisar mais a fundo o processo de tratamento do objeto de menu em xxxEnableMenuItem, descobrimos que a função MenuItemState retorna dois tipos possíveis de menu: o menu principal da janela ou o submenu (, ou até mesmo um submenu de submenu ).
No PoC, construímos uma estrutura de menu especial em quatro camadas, onde os menus adjacentes têm uma relação pai-filho. Estes menus têm algumas características específicas, que são detectadas e avaliadas através da função xxxEnableMenuItem.
Ao retornar à camada do usuário em xxxRedrawTitle, removemos a relação de referência entre o menu C e o menu B, liberando com sucesso o menu C. No final, quando a função xxxEnableMenuItem no núcleo retorna para a função xxxRedrawTitle, o objeto do menu C que estava prestes a ser referenciado já está inválido.
Exploração de Vulnerabilidades(Exploit)Implementação
Antes de determinar a abordagem de exploração, geralmente fazemos alguns julgamentos teóricos preliminares para evitar desperdiçar tempo em soluções inviáveis. Esta exploração de vulnerabilidades considera principalmente duas direções:
Executar código shellcode: consulte os CVEs anteriores CVE-2017-0263 e CVE-2016-0167. No entanto, em versões mais recentes do Windows, esse método pode enfrentar alguns problemas difíceis de resolver.
Utilizando primitivas de leitura e escrita para modificar o endereço do token: nos últimos anos, já existem métodos públicos disponíveis para referência. O layout da memória heap de desktop e as primitivas de leitura e escrita têm uma utilidade a longo prazo. Precisamos principalmente analisar como controlar pela primeira vez cbwndextra como um valor extremamente grande quando a memória UAF é reutilizada.
Dividimos todo o processo de exploração em duas questões: como explorar a vulnerabilidade UAF para controlar o valor cbwndextra e, após controlar o valor cbwndextra, como implementar primitivas de leitura e escrita estáveis.
No final, escolhemos escrever o cb-extra de HWNDClass através da operação AND 2 no sinalizador na função xxxRedrawWindow. Isso se deve ao fato de o cb-extra de HWNDClass ter um deslocamento pequeno, podendo controlar os dados de memória do objeto anterior através do layout de memória, permitindo assim a verificação do sinalizador do objeto na função xxxRedrawWindow.
Para alcançar um layout de memória estável, projetamos pelo menos três objetos HWND de 0x250 bytes consecutivos. Após liberar o objeto intermediário, ocupamos essa posição com um objeto HWNDClass de 0x250 bytes. Os dados de cauda do objeto HWND anterior são usados para verificação através da bandeira xxxRedrawWindow, enquanto o objeto de menu do próximo HWND e o objeto HWNDClass são usados como meio para as operações de leitura e escrita finais.
Tentamos manter o tamanho do objeto da janela consistente com o objeto HWNDClass e garantir que os dados de extensão do objeto da janela sejam grandes o suficiente. Através do endereço do manipulador de núcleo que vaza na memória heap, podemos determinar com precisão se o objeto da janela solicitado está disposto na ordem esperada.
Na leitura e escrita de primitivos, usamos GetMenuBarInfo() para implementar leitura arbitrária e SetClassLongPtr() para implementar escrita arbitrária. Exceto pela operação de escrita que substitui TOKEN e depende do objeto de classe da segunda janela, outras escritas utilizam o objeto de classe da primeira janela através de deslocamento.
Resumo
Estado atual do win32k: A Microsoft está tentando reestruturar o código do núcleo relacionado na versão de pré-visualização do Windows 11 usando Rust, e o novo sistema pode eliminar esse tipo de vulnerabilidade no futuro.
O processo de exploração de vulnerabilidades é relativamente simples: além de como controlar a primeira escrita, que requer tentativas cuidadosas, não é necessário usar novas técnicas de exploração. Este tipo de vulnerabilidade depende fortemente da divulgação do endereço do manipulador de pilha de desktop.
Descoberta de vulnerabilidades: supõe-se que possa depender de uma deteção de cobertura de código mais robusta. Assim que a API do sistema conseguir alcançar o ponto de vulnerabilidade mais profundo no caminho de execução da função alvo, e o objeto da janela estiver em um estado de referência aninhada múltipla, essa vulnerabilidade poderá ser descoberta através de testes de fuzz.
Outras maneiras de descobrir: Além da detecção dos pontos-chave da função que dispara a vulnerabilidade, a detecção de anomalias de leitura e escrita em layouts de memória não comuns e em dados adicionais de janelas ou classes de janelas também pode ser uma das formas de descobrir vulnerabilidades semelhantes.