Análise e Exploração de Vulnerabilidades 0day em Sistemas Microsoft
Introdução
Recentemente, um patch de segurança da Microsoft corrigiu uma vulnerabilidade de elevação de privilégios do win32k que estava sendo explorada por hackers. Esta vulnerabilidade afeta principalmente versões anteriores do sistema Windows, e parece ser ineficaz no Windows 11. Este artigo irá analisar em profundidade como esse tipo de vulnerabilidade pode continuar a ser explorado por atacantes, no contexto de constantes melhorias nas novas medidas de proteção. Nosso ambiente de análise é o Windows Server 2016.
Contexto da Vulnerabilidade
0day vulnerabilidade refere-se a falhas de segurança que não foram divulgadas e ainda não foram corrigidas, semelhante ao conceito de negociação T+0 nos mercados financeiros. Uma vez que esse tipo de vulnerabilidade é explorado maliciosamente, pode causar danos enormes. A vulnerabilidade 0day de nível de sistema do Windows descoberta desta vez permite que atacantes obtenham controle total do sistema.
As consequências de um sistema controlado pelo atacante são graves, incluindo a divulgação de informações pessoais, falhas no sistema, perda de dados, perdas financeiras e a inserção de programas maliciosos. Para os usuários de criptomoedas, as chaves privadas podem ser roubadas e os ativos digitais transferidos. Em uma escala mais ampla, essa vulnerabilidade pode até afetar todo o ecossistema Web3 baseado na infraestrutura Web2.
Análise de Patch
Analisar o código do patch, o problema parece estar no fato de que a contagem de referências de um objeto foi manipulada várias vezes. Ao olhar os comentários do código antigo, descobrimos que o código anterior apenas bloqueava o objeto da janela, sem bloquear o objeto do menu na janela, o que pode levar a referências erradas do objeto do menu.
Verificação de Vulnerabilidades
Analisando o contexto da função de vulnerabilidade, descobrimos que o menu passado para xxxEnableMenuItem() geralmente já está bloqueado na função de nível superior. Então, qual objeto de menu deve ser protegido especificamente? Ao analisar mais a fundo o tratamento do objeto de menu na função xxxEnableMenuItem, descobrimos que a função MenuItemState retorna dois tipos possíveis de menu: o menu principal da janela ou o submenu(, que inclui sub-submenus).
Para verificar a vulnerabilidade, construímos uma estrutura de menu especial de quatro camadas e definimos algumas condições específicas para contornar a detecção na função xxxEnableMenuItem. Quando a função xxxRedrawTitle retorna à camada do usuário, removemos a relação de referência entre os menus C e B, liberando com sucesso o menu C. Finalmente, quando a função xxxEnableMenuItem no núcleo retorna à função xxxRedrawTitle, o objeto de menu C referenciado já estava inválido.
Exploração de vulnerabilidades
abordagem geral
Antes de determinar um plano de exploração, geralmente realizamos algumas análises teóricas para evitar desperdiçar tempo em planos inviáveis. Esta exploração de vulnerabilidades considerou principalmente duas direções:
Executar shellcode: Referência a vulnerabilidades semelhantes anteriores, mas pode enfrentar alguns problemas difíceis de resolver em versões mais recentes do Windows.
Utilizar operações de leitura e escrita para modificar o token: mesmo nos últimos dois anos, ainda existem casos públicos de referência. Precisamos focar em como controlar o cbwndextra para um valor extra grande na primeira vez em que a memória UAF é reutilizada.
Portanto, dividimos todo o processo de exploração em duas partes: como explorar a vulnerabilidade UAF para controlar o valor cbwndextra e, após controlar esse valor, como implementar operações de leitura e escrita estáveis.
Escrita de dados inicial
Após a exploração da vulnerabilidade, o sistema pode não colapsar imediatamente. O uso incorreto dos dados do objeto de janela da memória controlada ocorre principalmente nas funções MNGetPopupFromMenu() e xxxMNUpdateShownMenu().
Usamos o objeto de nome da janela na classe WNDClass para ocupar a memória do objeto de menu liberado. O importante é encontrar uma posição na estrutura de endereço que possamos construir onde possamos escrever dados arbitrariamente, mesmo que seja apenas um byte.
Finalmente, encontramos duas soluções viáveis na função xxxRedrawWindow. Considerando algumas restrições, optamos pela solução que depende da operação AND 2 com a variável de controle e decidimos escrever no cb-extra da HWNDClass em vez do cb-extra do objeto da janela.
Layout de memória estável
Desenhamos um layout de memória para pelo menos três objetos HWND de 0x250 bytes em sequência. Libere os objetos intermediários, ocupando um objeto HWNDClass de 0x250 bytes. Os dados do final do objeto HWND anterior são utilizados para verificação através do sinalizador xxxRedrawWindow, e os objetos de menu do objeto HWND posterior e o objeto HWNDClass atuam como meios de leitura e escrita finais.
Tentamos controlar o tamanho do objeto da janela e do objeto HWNDClass para que sejam consistentes, e garantir que os dados de extensão do objeto da janela sejam suficientemente grandes. Através do endereço do manipulador do núcleo que vaza na memória heap, podemos determinar com precisão se o objeto da janela solicitado está organizado na ordem esperada.
implementação de primitivos de leitura e escrita
Qualquer leitura da linguagem original ainda usa GetMenuBarInfo(). Qualquer escrita da linguagem original usa SetClassLongPtr(). Exceto a operação de escrita que substitui TOKEN, que depende do objeto de classe da segunda janela, todas as outras escritas utilizam o objeto de classe da primeira janela com um deslocamento para serem realizadas.
Resumo
A vulnerabilidade win32k existe há muito tempo, mas a Microsoft está a reescrever o código do núcleo relacionado em Rust, e os novos sistemas no futuro poderão eliminar esse tipo de vulnerabilidade.
O processo de exploração desta vulnerabilidade não é difícil, sendo o principal desafio controlar a primeira escrita. A vulnerabilidade ainda depende seriamente da divulgação do endereço do manipulador de pilha da área de trabalho, o que ainda representa um risco de segurança para sistemas antigos.
A descoberta desta vulnerabilidade pode ser atribuída a uma detecção de cobertura de código mais eficaz. Assim que a API do sistema conseguir alcançar o ponto de falha 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, os testes de fuzz podem descobrir essa vulnerabilidade.
Para a detecção de exploração de vulnerabilidades, além de se concentrar nos pontos críticos das funções que acionam as vulnerabilidades, também deve-se prestar atenção ao layout de memória anômalo e à leitura e escrita de deslocamentos não convencionais de dados adicionais em janelas ou classes de janelas, o que pode ajudar a identificar vulnerabilidades do mesmo tipo.
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.
23 gostos
Recompensa
23
3
Partilhar
Comentar
0/400
OnChainDetective
· 08-01 09:21
ah clássico win32k... padrão coincide com explorações APT anteriores tbh
Análise Profundidade e Técnicas de Exploração de Vulnerabilidades 0day em Sistemas Windows
Análise e Exploração de Vulnerabilidades 0day em Sistemas Microsoft
Introdução
Recentemente, um patch de segurança da Microsoft corrigiu uma vulnerabilidade de elevação de privilégios do win32k que estava sendo explorada por hackers. Esta vulnerabilidade afeta principalmente versões anteriores do sistema Windows, e parece ser ineficaz no Windows 11. Este artigo irá analisar em profundidade como esse tipo de vulnerabilidade pode continuar a ser explorado por atacantes, no contexto de constantes melhorias nas novas medidas de proteção. Nosso ambiente de análise é o Windows Server 2016.
Contexto da Vulnerabilidade
0day vulnerabilidade refere-se a falhas de segurança que não foram divulgadas e ainda não foram corrigidas, semelhante ao conceito de negociação T+0 nos mercados financeiros. Uma vez que esse tipo de vulnerabilidade é explorado maliciosamente, pode causar danos enormes. A vulnerabilidade 0day de nível de sistema do Windows descoberta desta vez permite que atacantes obtenham controle total do sistema.
As consequências de um sistema controlado pelo atacante são graves, incluindo a divulgação de informações pessoais, falhas no sistema, perda de dados, perdas financeiras e a inserção de programas maliciosos. Para os usuários de criptomoedas, as chaves privadas podem ser roubadas e os ativos digitais transferidos. Em uma escala mais ampla, essa vulnerabilidade pode até afetar todo o ecossistema Web3 baseado na infraestrutura Web2.
Análise de Patch
Analisar o código do patch, o problema parece estar no fato de que a contagem de referências de um objeto foi manipulada várias vezes. Ao olhar os comentários do código antigo, descobrimos que o código anterior apenas bloqueava o objeto da janela, sem bloquear o objeto do menu na janela, o que pode levar a referências erradas do objeto do menu.
Verificação de Vulnerabilidades
Analisando o contexto da função de vulnerabilidade, descobrimos que o menu passado para xxxEnableMenuItem() geralmente já está bloqueado na função de nível superior. Então, qual objeto de menu deve ser protegido especificamente? Ao analisar mais a fundo o tratamento do objeto de menu na função xxxEnableMenuItem, descobrimos que a função MenuItemState retorna dois tipos possíveis de menu: o menu principal da janela ou o submenu(, que inclui sub-submenus).
Para verificar a vulnerabilidade, construímos uma estrutura de menu especial de quatro camadas e definimos algumas condições específicas para contornar a detecção na função xxxEnableMenuItem. Quando a função xxxRedrawTitle retorna à camada do usuário, removemos a relação de referência entre os menus C e B, liberando com sucesso o menu C. Finalmente, quando a função xxxEnableMenuItem no núcleo retorna à função xxxRedrawTitle, o objeto de menu C referenciado já estava inválido.
Exploração de vulnerabilidades
abordagem geral
Antes de determinar um plano de exploração, geralmente realizamos algumas análises teóricas para evitar desperdiçar tempo em planos inviáveis. Esta exploração de vulnerabilidades considerou principalmente duas direções:
Executar shellcode: Referência a vulnerabilidades semelhantes anteriores, mas pode enfrentar alguns problemas difíceis de resolver em versões mais recentes do Windows.
Utilizar operações de leitura e escrita para modificar o token: mesmo nos últimos dois anos, ainda existem casos públicos de referência. Precisamos focar em como controlar o cbwndextra para um valor extra grande na primeira vez em que a memória UAF é reutilizada.
Portanto, dividimos todo o processo de exploração em duas partes: como explorar a vulnerabilidade UAF para controlar o valor cbwndextra e, após controlar esse valor, como implementar operações de leitura e escrita estáveis.
Escrita de dados inicial
Após a exploração da vulnerabilidade, o sistema pode não colapsar imediatamente. O uso incorreto dos dados do objeto de janela da memória controlada ocorre principalmente nas funções MNGetPopupFromMenu() e xxxMNUpdateShownMenu().
Usamos o objeto de nome da janela na classe WNDClass para ocupar a memória do objeto de menu liberado. O importante é encontrar uma posição na estrutura de endereço que possamos construir onde possamos escrever dados arbitrariamente, mesmo que seja apenas um byte.
Finalmente, encontramos duas soluções viáveis na função xxxRedrawWindow. Considerando algumas restrições, optamos pela solução que depende da operação AND 2 com a variável de controle e decidimos escrever no cb-extra da HWNDClass em vez do cb-extra do objeto da janela.
Layout de memória estável
Desenhamos um layout de memória para pelo menos três objetos HWND de 0x250 bytes em sequência. Libere os objetos intermediários, ocupando um objeto HWNDClass de 0x250 bytes. Os dados do final do objeto HWND anterior são utilizados para verificação através do sinalizador xxxRedrawWindow, e os objetos de menu do objeto HWND posterior e o objeto HWNDClass atuam como meios de leitura e escrita finais.
Tentamos controlar o tamanho do objeto da janela e do objeto HWNDClass para que sejam consistentes, e garantir que os dados de extensão do objeto da janela sejam suficientemente grandes. Através do endereço do manipulador do núcleo que vaza na memória heap, podemos determinar com precisão se o objeto da janela solicitado está organizado na ordem esperada.
implementação de primitivos de leitura e escrita
Qualquer leitura da linguagem original ainda usa GetMenuBarInfo(). Qualquer escrita da linguagem original usa SetClassLongPtr(). Exceto a operação de escrita que substitui TOKEN, que depende do objeto de classe da segunda janela, todas as outras escritas utilizam o objeto de classe da primeira janela com um deslocamento para serem realizadas.
Resumo
A vulnerabilidade win32k existe há muito tempo, mas a Microsoft está a reescrever o código do núcleo relacionado em Rust, e os novos sistemas no futuro poderão eliminar esse tipo de vulnerabilidade.
O processo de exploração desta vulnerabilidade não é difícil, sendo o principal desafio controlar a primeira escrita. A vulnerabilidade ainda depende seriamente da divulgação do endereço do manipulador de pilha da área de trabalho, o que ainda representa um risco de segurança para sistemas antigos.
A descoberta desta vulnerabilidade pode ser atribuída a uma detecção de cobertura de código mais eficaz. Assim que a API do sistema conseguir alcançar o ponto de falha 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, os testes de fuzz podem descobrir essa vulnerabilidade.
Para a detecção de exploração de vulnerabilidades, além de se concentrar nos pontos críticos das funções que acionam as vulnerabilidades, também deve-se prestar atenção ao layout de memória anômalo e à leitura e escrita de deslocamentos não convencionais de dados adicionais em janelas ou classes de janelas, o que pode ajudar a identificar vulnerabilidades do mesmo tipo.