Vulnerabilidades no sistema Windows da Microsoft podem levar a riscos de segurança no Web3
No patch de segurança lançado pela Microsoft no mês passado, foi incluída uma vulnerabilidade de elevação de privilégios win32k que está sendo explorada. Esta vulnerabilidade parece existir apenas em versões anteriores do sistema Windows e não pode ser acionada no Windows 11.
A exploração desse tipo de vulnerabilidade já é antiga. No contexto atual, com as novas medidas de mitigação de segurança sendo continuamente aprimoradas, esperamos analisar como os atacantes podem continuar a explorar essa vulnerabilidade. O processo de análise deste artigo foi realizado no ambiente do Windows Server 2016.
Esta vulnerabilidade zero-day não foi divulgada nem corrigida, podendo ser explorada maliciosamente sem ser detectada, apresentando um grande potencial destrutivo. Através dessa vulnerabilidade, hackers podem obter controle total sobre o sistema Windows. Isso pode levar a sérias consequências, como o roubo de informações pessoais, colapso do sistema, perda de dados, perdas financeiras e a inserção de malware. Para os usuários de Web3, as chaves privadas podem ser roubadas e os ativos digitais podem ser transferidos. De uma perspectiva mais ampla, essa vulnerabilidade pode até afetar todo o ecossistema Web3 que opera em infraestruturas baseadas em Web2.
Através da análise do patch, descobrimos que o problema estava no fato de que a contagem de referências do objeto foi manipulada uma vez a mais. O win32k é um código mais antigo, e os comentários do código-fonte mais antigos mostram 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 resultar em uma referência incorreta do objeto do menu.
Ao implementar a prova de conceito (PoC), descobrimos que o menu xxxEnableMenuItem() que entra geralmente já está bloqueado na função superior, e não está claro qual objeto de menu deve ser protegido aqui. Análises adicionais revelaram que o menu retornado pela função MenuItemState pode ser o menu principal da janela, um submenu ou até mesmo um submenu de submenu.
Para desencadear a vulnerabilidade, construímos uma estrutura de menu especial de quatro camadas e definimos algumas condições específicas para passar pela verificação da função xxxEnableMenuItem. Quando xxxRedrawTitle retorna ao nível do usuário, removemos a relação de referência entre os menus C e B, conseguindo liberar com sucesso o menu C. Por fim, quando a função xxxEnableMenuItem retorna ao xxxRedrawTitle, o objeto do menu C, prestes a ser referenciado, já está inválido.
Ao desenvolver a exploração (Exp), considerámos principalmente duas abordagens: executar shellcode e utilizar primitivas de leitura/escrita para modificar o endereço do token. Tendo em conta a viabilidade, escolhemos a segunda. Todo o processo de exploração pode ser dividido em duas etapas: como explorar a vulnerabilidade UAF para controlar o valor de cbwndextra, e como implementar primitivas de leitura/escrita estáveis.
Nós ocupamos o objeto de menu liberado com o objeto de nome da janela na classe de janela WNDClass, projetando cuidadosamente a disposição da memória. Através de operações específicas na função xxxRedrawWindow, realizamos a primeira gravação de dados.
Para alcançar um layout de memória estável, projetamos três objetos HWND consecutivos, liberando o do meio e usando um objeto HWNDClass para ocupá-lo. Os objetos HWND nas extremidades são usados para verificar e implementar primitivas de leitura e escrita. Também avaliamos com precisão se a disposição dos objetos atende às expectativas através da revelação do endereço do manipulador do núcleo.
Na implementação de leitura e escrita de primitivos, usamos GetMenuBarInfo() para leitura arbitrária e SetClassLongPtr() para escrita arbitrária. Além da operação de substituição de TOKEN, outras escritas são realizadas utilizando o objeto class do primeiro objeto de janela através de deslocamento.
Embora a vulnerabilidade win32k exista há muito tempo, a Microsoft está tentando reescrever o código do kernel relacionado em Rust, e no futuro, esse tipo de vulnerabilidade pode ser eliminado em novos sistemas. O processo de exploração desta vulnerabilidade é relativamente simples, sendo o principal desafio como controlar a primeira escrita. Esta vulnerabilidade depende fortemente do vazamento do endereço do manipulador de heap da área de trabalho, que continua a ser um risco de segurança em sistemas antigos.
Suspeitamos que a descoberta da vulnerabilidade possa ter sido facilitada por uma detecção de cobertura de código mais abrangente. Para a deteção de exploração de vulnerabilidades, além de monitorizar pontos críticos, a deteção direcionada de layouts de memória anómalos e leitura/escrita de dados de janelas também pode ajudar a descobrir esse tipo de vulnerabilidade.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
20 gostos
Recompensa
20
8
Republicar
Partilhar
Comentar
0/400
RunWhenCut
· 08-08 14:14
Atualizar o patch em breve
Ver originalResponder0
LiquidityWizard
· 08-08 03:20
Se o sistema não for atualizado, é melhor esperar a morte.
Ver originalResponder0
BlockchainTalker
· 08-07 08:27
Esteja extra seguro agora.
Ver originalResponder0
FlyingLeek
· 08-06 06:24
Atualizar o sistema para manter a segurança
Ver originalResponder0
ImpermanentSage
· 08-05 14:49
Apresse-se em atualizar, não seja preguiçoso
Ver originalResponder0
SelfCustodyIssues
· 08-05 14:48
Apresse-se a atualizar o sistema.
Ver originalResponder0
TopBuyerBottomSeller
· 08-05 14:42
Atualize para o sistema 11 o mais rápido possível.
Ameaça de vulnerabilidades do sistema Windows à segurança do ativo Web3 Chave privada pode ser roubada
Vulnerabilidades no sistema Windows da Microsoft podem levar a riscos de segurança no Web3
No patch de segurança lançado pela Microsoft no mês passado, foi incluída uma vulnerabilidade de elevação de privilégios win32k que está sendo explorada. Esta vulnerabilidade parece existir apenas em versões anteriores do sistema Windows e não pode ser acionada no Windows 11.
A exploração desse tipo de vulnerabilidade já é antiga. No contexto atual, com as novas medidas de mitigação de segurança sendo continuamente aprimoradas, esperamos analisar como os atacantes podem continuar a explorar essa vulnerabilidade. O processo de análise deste artigo foi realizado no ambiente do Windows Server 2016.
Esta vulnerabilidade zero-day não foi divulgada nem corrigida, podendo ser explorada maliciosamente sem ser detectada, apresentando um grande potencial destrutivo. Através dessa vulnerabilidade, hackers podem obter controle total sobre o sistema Windows. Isso pode levar a sérias consequências, como o roubo de informações pessoais, colapso do sistema, perda de dados, perdas financeiras e a inserção de malware. Para os usuários de Web3, as chaves privadas podem ser roubadas e os ativos digitais podem ser transferidos. De uma perspectiva mais ampla, essa vulnerabilidade pode até afetar todo o ecossistema Web3 que opera em infraestruturas baseadas em Web2.
Através da análise do patch, descobrimos que o problema estava no fato de que a contagem de referências do objeto foi manipulada uma vez a mais. O win32k é um código mais antigo, e os comentários do código-fonte mais antigos mostram 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 resultar em uma referência incorreta do objeto do menu.
Ao implementar a prova de conceito (PoC), descobrimos que o menu xxxEnableMenuItem() que entra geralmente já está bloqueado na função superior, e não está claro qual objeto de menu deve ser protegido aqui. Análises adicionais revelaram que o menu retornado pela função MenuItemState pode ser o menu principal da janela, um submenu ou até mesmo um submenu de submenu.
Para desencadear a vulnerabilidade, construímos uma estrutura de menu especial de quatro camadas e definimos algumas condições específicas para passar pela verificação da função xxxEnableMenuItem. Quando xxxRedrawTitle retorna ao nível do usuário, removemos a relação de referência entre os menus C e B, conseguindo liberar com sucesso o menu C. Por fim, quando a função xxxEnableMenuItem retorna ao xxxRedrawTitle, o objeto do menu C, prestes a ser referenciado, já está inválido.
Ao desenvolver a exploração (Exp), considerámos principalmente duas abordagens: executar shellcode e utilizar primitivas de leitura/escrita para modificar o endereço do token. Tendo em conta a viabilidade, escolhemos a segunda. Todo o processo de exploração pode ser dividido em duas etapas: como explorar a vulnerabilidade UAF para controlar o valor de cbwndextra, e como implementar primitivas de leitura/escrita estáveis.
Nós ocupamos o objeto de menu liberado com o objeto de nome da janela na classe de janela WNDClass, projetando cuidadosamente a disposição da memória. Através de operações específicas na função xxxRedrawWindow, realizamos a primeira gravação de dados.
Para alcançar um layout de memória estável, projetamos três objetos HWND consecutivos, liberando o do meio e usando um objeto HWNDClass para ocupá-lo. Os objetos HWND nas extremidades são usados para verificar e implementar primitivas de leitura e escrita. Também avaliamos com precisão se a disposição dos objetos atende às expectativas através da revelação do endereço do manipulador do núcleo.
Na implementação de leitura e escrita de primitivos, usamos GetMenuBarInfo() para leitura arbitrária e SetClassLongPtr() para escrita arbitrária. Além da operação de substituição de TOKEN, outras escritas são realizadas utilizando o objeto class do primeiro objeto de janela através de deslocamento.
Embora a vulnerabilidade win32k exista há muito tempo, a Microsoft está tentando reescrever o código do kernel relacionado em Rust, e no futuro, esse tipo de vulnerabilidade pode ser eliminado em novos sistemas. O processo de exploração desta vulnerabilidade é relativamente simples, sendo o principal desafio como controlar a primeira escrita. Esta vulnerabilidade depende fortemente do vazamento do endereço do manipulador de heap da área de trabalho, que continua a ser um risco de segurança em sistemas antigos.
Suspeitamos que a descoberta da vulnerabilidade possa ter sido facilitada por uma detecção de cobertura de código mais abrangente. Para a deteção de exploração de vulnerabilidades, além de monitorizar pontos críticos, a deteção direcionada de layouts de memória anómalos e leitura/escrita de dados de janelas também pode ajudar a descobrir esse tipo de vulnerabilidade.