La vulnerabilidad del sistema Windows de Microsoft puede causar riesgos de seguridad en Web3
El parche de seguridad lanzado por Microsoft el mes pasado contiene una vulnerabilidad de escalada de privilegios win32k que está siendo explotada. Esta vulnerabilidad parece existir solo en versiones anteriores de Windows y no se puede activar en Windows 11.
La explotación de este tipo de vulnerabilidades ha existido durante mucho tiempo. En el contexto de las nuevas medidas de seguridad que se están mejorando continuamente, esperamos analizar cómo los atacantes podrían seguir aprovechando esta vulnerabilidad. El proceso de análisis de este artículo se completó en un entorno de Windows Server 2016.
Esta vulnerabilidad de día cero no ha sido divulgada ni reparada, y puede ser explotada maliciosamente sin ser detectada, lo que tiene un gran potencial destructivo. A través de esta vulnerabilidad, los hackers pueden obtener control total sobre el sistema Windows. Esto puede resultar en el robo de información personal, fallos del sistema, pérdida de datos, pérdidas financieras, inserción de malware y otras consecuencias graves. Para los usuarios de Web3, las claves privadas pueden ser robadas y los activos digitales pueden ser transferidos. Desde una perspectiva más amplia, esta vulnerabilidad incluso podría afectar a todo el ecosistema Web3 que opera sobre la infraestructura de Web2.
Al analizar el parche, encontramos que el problema radica en que el recuento de referencias del objeto se ha procesado una vez más. win32k es un código más antiguo, los comentarios en el código fuente temprano muestran que el código anterior solo bloqueaba el objeto de la ventana, sin bloquear el objeto del menú dentro del objeto de la ventana, lo que podría llevar a una referencia incorrecta del objeto del menú.
Al implementar la verificación de concepto (PoC), encontramos que el menú que se pasa a xxxEnableMenuItem() generalmente ya está bloqueado en la función superior, no está claro qué objeto de menú se debe proteger aquí. Un análisis más detallado revela que el menú que devuelve la función MenuItemState puede ser el menú principal de la ventana, un submenú o incluso un sub-submenú.
Para desencadenar la vulnerabilidad, construimos una estructura de menú especial de cuatro capas y establecimos algunas condiciones específicas para pasar la verificación de la función xxxEnableMenuItem. Cuando xxxRedrawTitle devuelve la capa de usuario, eliminamos la relación de referencia entre los menús C y B, liberando con éxito el menú C. Al final, cuando la función xxxEnableMenuItem regresa a xxxRedrawTitle, el objeto de menú C que estaba a punto de ser referenciado ya es inválido.
Al desarrollar la explotación de (Exp), consideramos principalmente dos enfoques: ejecutar shellcode y utilizar primitivas de lectura y escritura para modificar la dirección del token. Teniendo en cuenta la viabilidad, elegimos el segundo. Todo el proceso de explotación se puede dividir en dos pasos: cómo aprovechar la vulnerabilidad UAF para controlar el valor de cbwndextra, y cómo implementar primitivas de lectura y escritura estables.
Diseñamos cuidadosamente la disposición de la memoria y utilizamos el objeto de nombre de ventana en la clase de ventana WNDClass para ocupar el objeto de menú liberado. A través de operaciones específicas en la función xxxRedrawWindow, logramos la primera escritura de datos.
Para lograr una disposición de memoria estable, diseñamos tres objetos HWND consecutivos, liberando el del medio y ocupando el objeto HWNDClass. Los objetos HWND en los extremos se utilizan para verificar e implementar primitivas de lectura y escritura. También determinamos con precisión si la disposición de los objetos cumple con las expectativas a través de la fuga de direcciones de manejadores del núcleo.
En la implementación de lectura y escritura de primitivas, utilizamos GetMenuBarInfo() para lectura arbitraria y SetClassLongPtr() para escritura arbitraria. Aparte de la operación de reemplazo de TOKEN, otras escrituras se realizan utilizando el objeto de clase del primer objeto de ventana a través de desplazamientos.
Aunque la vulnerabilidad win32k ha existido durante mucho tiempo, Microsoft está intentando reestructurar el código del núcleo relacionado utilizando Rust, y en los futuros sistemas este tipo de vulnerabilidades podrían eliminarse. El proceso de explotación de esta vulnerabilidad es relativamente simple, siendo el principal desafío cómo controlar la primera escritura. Esta vulnerabilidad depende en gran medida de la filtración de la dirección del manejador del montón de escritorio, lo que sigue siendo un riesgo de seguridad en los sistemas antiguos.
Suponemos que el descubrimiento de esta vulnerabilidad podría deberse a una mejor detección de la cobertura del código. En cuanto a la detección de explotaciones de vulnerabilidades, además de monitorear puntos clave, la detección específica de la disposición anómala de la memoria y la lectura y escritura de datos de la ventana también podría ayudar a descubrir este tipo de vulnerabilidades.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Las vulnerabilidades del sistema Windows amenazan la seguridad del activo Web3; la llave privada podría ser robada.
La vulnerabilidad del sistema Windows de Microsoft puede causar riesgos de seguridad en Web3
El parche de seguridad lanzado por Microsoft el mes pasado contiene una vulnerabilidad de escalada de privilegios win32k que está siendo explotada. Esta vulnerabilidad parece existir solo en versiones anteriores de Windows y no se puede activar en Windows 11.
La explotación de este tipo de vulnerabilidades ha existido durante mucho tiempo. En el contexto de las nuevas medidas de seguridad que se están mejorando continuamente, esperamos analizar cómo los atacantes podrían seguir aprovechando esta vulnerabilidad. El proceso de análisis de este artículo se completó en un entorno de Windows Server 2016.
Esta vulnerabilidad de día cero no ha sido divulgada ni reparada, y puede ser explotada maliciosamente sin ser detectada, lo que tiene un gran potencial destructivo. A través de esta vulnerabilidad, los hackers pueden obtener control total sobre el sistema Windows. Esto puede resultar en el robo de información personal, fallos del sistema, pérdida de datos, pérdidas financieras, inserción de malware y otras consecuencias graves. Para los usuarios de Web3, las claves privadas pueden ser robadas y los activos digitales pueden ser transferidos. Desde una perspectiva más amplia, esta vulnerabilidad incluso podría afectar a todo el ecosistema Web3 que opera sobre la infraestructura de Web2.
Al analizar el parche, encontramos que el problema radica en que el recuento de referencias del objeto se ha procesado una vez más. win32k es un código más antiguo, los comentarios en el código fuente temprano muestran que el código anterior solo bloqueaba el objeto de la ventana, sin bloquear el objeto del menú dentro del objeto de la ventana, lo que podría llevar a una referencia incorrecta del objeto del menú.
Al implementar la verificación de concepto (PoC), encontramos que el menú que se pasa a xxxEnableMenuItem() generalmente ya está bloqueado en la función superior, no está claro qué objeto de menú se debe proteger aquí. Un análisis más detallado revela que el menú que devuelve la función MenuItemState puede ser el menú principal de la ventana, un submenú o incluso un sub-submenú.
Para desencadenar la vulnerabilidad, construimos una estructura de menú especial de cuatro capas y establecimos algunas condiciones específicas para pasar la verificación de la función xxxEnableMenuItem. Cuando xxxRedrawTitle devuelve la capa de usuario, eliminamos la relación de referencia entre los menús C y B, liberando con éxito el menú C. Al final, cuando la función xxxEnableMenuItem regresa a xxxRedrawTitle, el objeto de menú C que estaba a punto de ser referenciado ya es inválido.
Al desarrollar la explotación de (Exp), consideramos principalmente dos enfoques: ejecutar shellcode y utilizar primitivas de lectura y escritura para modificar la dirección del token. Teniendo en cuenta la viabilidad, elegimos el segundo. Todo el proceso de explotación se puede dividir en dos pasos: cómo aprovechar la vulnerabilidad UAF para controlar el valor de cbwndextra, y cómo implementar primitivas de lectura y escritura estables.
Diseñamos cuidadosamente la disposición de la memoria y utilizamos el objeto de nombre de ventana en la clase de ventana WNDClass para ocupar el objeto de menú liberado. A través de operaciones específicas en la función xxxRedrawWindow, logramos la primera escritura de datos.
Para lograr una disposición de memoria estable, diseñamos tres objetos HWND consecutivos, liberando el del medio y ocupando el objeto HWNDClass. Los objetos HWND en los extremos se utilizan para verificar e implementar primitivas de lectura y escritura. También determinamos con precisión si la disposición de los objetos cumple con las expectativas a través de la fuga de direcciones de manejadores del núcleo.
En la implementación de lectura y escritura de primitivas, utilizamos GetMenuBarInfo() para lectura arbitraria y SetClassLongPtr() para escritura arbitraria. Aparte de la operación de reemplazo de TOKEN, otras escrituras se realizan utilizando el objeto de clase del primer objeto de ventana a través de desplazamientos.
Aunque la vulnerabilidad win32k ha existido durante mucho tiempo, Microsoft está intentando reestructurar el código del núcleo relacionado utilizando Rust, y en los futuros sistemas este tipo de vulnerabilidades podrían eliminarse. El proceso de explotación de esta vulnerabilidad es relativamente simple, siendo el principal desafío cómo controlar la primera escritura. Esta vulnerabilidad depende en gran medida de la filtración de la dirección del manejador del montón de escritorio, lo que sigue siendo un riesgo de seguridad en los sistemas antiguos.
Suponemos que el descubrimiento de esta vulnerabilidad podría deberse a una mejor detección de la cobertura del código. En cuanto a la detección de explotaciones de vulnerabilidades, además de monitorear puntos clave, la detección específica de la disposición anómala de la memoria y la lectura y escritura de datos de la ventana también podría ayudar a descubrir este tipo de vulnerabilidades.