Análisis de vulnerabilidades 0day en el sistema Windows de Microsoft: puede obtener el control total del sistema
El mes pasado, un parche de seguridad de Microsoft corrigió una vulnerabilidad de escalada de privilegios en el núcleo de Windows que estaba siendo explotada por hackers. Esta vulnerabilidad existe principalmente en versiones tempranas del sistema operativo Windows y no se puede activar en Windows 11. Este artículo analizará cómo los atacantes podrían continuar explotando esta vulnerabilidad en el contexto de los mecanismos de seguridad en constante mejora. Nuestro entorno de análisis es Windows Server 2016.
Una vulnerabilidad 0day se refiere a un software que aún no ha sido descubierto y reparado. Una vez que es aprovechada por un hacker, puede causar daños graves. La vulnerabilidad 0day de Windows recientemente descubierta permite a los atacantes obtener el control completo del sistema, lo que a su vez puede llevar al robo de información personal, la implantación de software malicioso, el robo de criptomonedas, entre otros. Desde una perspectiva más amplia, esta vulnerabilidad incluso podría afectar a todo el ecosistema Web3 basado en la infraestructura Web2.
El análisis del parche muestra que el problema radica en el manejo del conteo de referencias de un objeto en el módulo win32k. Comentarios en el código fuente anterior indican que el código anterior solo bloqueaba el objeto de la ventana, sin bloquear el objeto del menú en la ventana, lo que podría llevar a una referencia incorrecta del objeto del menú.
Hemos construido una estructura de menú anidado especial para desencadenar la vulnerabilidad. La clave es eliminar la referencia de un submenú y liberarlo cuando la función xxxEnableMenuItem devuelve al nivel de usuario. De este modo, cuando la función vuelve a entrar en el modo kernel, el objeto de menú referenciado anteriormente ya ha quedado obsoleto.
Al implementar la explotación de vulnerabilidades, consideramos principalmente dos enfoques: ejecutar shellcode y utilizar operaciones de lectura/escritura para modificar el token. Teniendo en cuenta el mecanismo de seguridad de las versiones más recientes de Windows, elegimos el segundo. Todo el proceso de explotación se divide en dos pasos: primero, controlar el valor de cbwndextra, y luego establecer operaciones de lectura/escritura estables.
Para escribir los primeros datos, utilizamos un punto de escritura en la función xxxRedrawWindow. Al organizar cuidadosamente la memoria, podemos controlar los datos de memoria de los objetos adyacentes, lo que nos permite verificar a través de las banderas en la función.
En términos de diseño de memoria, hemos diseñado tres objetos HWND consecutivos, liberando el del medio y ocupando con un objeto HWNDClass. Los dos objetos HWND en los extremos se utilizan respectivamente para la verificación y la implementación de primitivas de lectura y escritura. También aprovechamos la dirección del manejador de núcleo filtrado en la memoria del montón para juzgar con precisión si la disposición de los objetos cumple con las expectativas.
Finalmente, utilizamos GetMenuBarInfo() para implementar la lectura arbitraria y SetClassLongPtr() para implementar la escritura arbitraria. Además de modificar las operaciones del TOKEN, otras escrituras se completan utilizando el objeto de clase del primer objeto de ventana.
En general, aunque las vulnerabilidades del módulo win32k han existido durante mucho tiempo, Microsoft está intentando reestructurar el código relacionado utilizando Rust, lo que podría eliminar este tipo de vulnerabilidades en los nuevos sistemas. El proceso de explotación actual no es particularmente difícil, ya que depende principalmente de la filtración de la dirección del manejador de pila de escritorio. Mejorar la detección de cobertura de código y realizar pruebas específicas para detectar operaciones de memoria anómalas podrían ser formas efectivas de identificar este tipo de vulnerabilidades.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
17 me gusta
Recompensa
17
5
Compartir
Comentar
0/400
MissingSats
· 07-11 05:50
¿Billetera en el caballo?
Ver originalesResponder0
GigaBrainAnon
· 07-11 05:50
¡Bah! Otra vez tengo que lidiar con la actualización del sistema.
Ver originalesResponder0
PanicSeller
· 07-11 05:46
¡Es aterrador! 8 Billetera va a cambiar a Android.
Análisis de la vulnerabilidad 0day del núcleo de Windows: podría afectar la seguridad del ecosistema Web3
Análisis de vulnerabilidades 0day en el sistema Windows de Microsoft: puede obtener el control total del sistema
El mes pasado, un parche de seguridad de Microsoft corrigió una vulnerabilidad de escalada de privilegios en el núcleo de Windows que estaba siendo explotada por hackers. Esta vulnerabilidad existe principalmente en versiones tempranas del sistema operativo Windows y no se puede activar en Windows 11. Este artículo analizará cómo los atacantes podrían continuar explotando esta vulnerabilidad en el contexto de los mecanismos de seguridad en constante mejora. Nuestro entorno de análisis es Windows Server 2016.
Una vulnerabilidad 0day se refiere a un software que aún no ha sido descubierto y reparado. Una vez que es aprovechada por un hacker, puede causar daños graves. La vulnerabilidad 0day de Windows recientemente descubierta permite a los atacantes obtener el control completo del sistema, lo que a su vez puede llevar al robo de información personal, la implantación de software malicioso, el robo de criptomonedas, entre otros. Desde una perspectiva más amplia, esta vulnerabilidad incluso podría afectar a todo el ecosistema Web3 basado en la infraestructura Web2.
El análisis del parche muestra que el problema radica en el manejo del conteo de referencias de un objeto en el módulo win32k. Comentarios en el código fuente anterior indican que el código anterior solo bloqueaba el objeto de la ventana, sin bloquear el objeto del menú en la ventana, lo que podría llevar a una referencia incorrecta del objeto del menú.
Hemos construido una estructura de menú anidado especial para desencadenar la vulnerabilidad. La clave es eliminar la referencia de un submenú y liberarlo cuando la función xxxEnableMenuItem devuelve al nivel de usuario. De este modo, cuando la función vuelve a entrar en el modo kernel, el objeto de menú referenciado anteriormente ya ha quedado obsoleto.
Al implementar la explotación de vulnerabilidades, consideramos principalmente dos enfoques: ejecutar shellcode y utilizar operaciones de lectura/escritura para modificar el token. Teniendo en cuenta el mecanismo de seguridad de las versiones más recientes de Windows, elegimos el segundo. Todo el proceso de explotación se divide en dos pasos: primero, controlar el valor de cbwndextra, y luego establecer operaciones de lectura/escritura estables.
Para escribir los primeros datos, utilizamos un punto de escritura en la función xxxRedrawWindow. Al organizar cuidadosamente la memoria, podemos controlar los datos de memoria de los objetos adyacentes, lo que nos permite verificar a través de las banderas en la función.
En términos de diseño de memoria, hemos diseñado tres objetos HWND consecutivos, liberando el del medio y ocupando con un objeto HWNDClass. Los dos objetos HWND en los extremos se utilizan respectivamente para la verificación y la implementación de primitivas de lectura y escritura. También aprovechamos la dirección del manejador de núcleo filtrado en la memoria del montón para juzgar con precisión si la disposición de los objetos cumple con las expectativas.
Finalmente, utilizamos GetMenuBarInfo() para implementar la lectura arbitraria y SetClassLongPtr() para implementar la escritura arbitraria. Además de modificar las operaciones del TOKEN, otras escrituras se completan utilizando el objeto de clase del primer objeto de ventana.
En general, aunque las vulnerabilidades del módulo win32k han existido durante mucho tiempo, Microsoft está intentando reestructurar el código relacionado utilizando Rust, lo que podría eliminar este tipo de vulnerabilidades en los nuevos sistemas. El proceso de explotación actual no es particularmente difícil, ya que depende principalmente de la filtración de la dirección del manejador de pila de escritorio. Mejorar la detección de cobertura de código y realizar pruebas específicas para detectar operaciones de memoria anómalas podrían ser formas efectivas de identificar este tipo de vulnerabilidades.