Análisis y explotación de vulnerabilidades 0day a nivel de sistema de Microsoft
Introducción
Recientemente, un parche de seguridad de Microsoft ha solucionado una vulnerabilidad de escalada de privilegios en win32k que estaba siendo explotada por hackers. Esta vulnerabilidad afecta principalmente a versiones anteriores del sistema operativo Windows y parece ser ineficaz en Windows 11. Este artículo analizará en profundidad cómo los atacantes podrían seguir explotando este tipo de vulnerabilidades en el contexto de las nuevas medidas de protección que se están mejorando continuamente. Nuestro entorno de análisis es Windows Server 2016.
Contexto de la vulnerabilidad
0day vulnerabilidades se refieren a vulnerabilidades de seguridad que no han sido publicadas ni reparadas, similar al concepto de transacciones T+0 en el mercado financiero. Una vez que este tipo de vulnerabilidades son explotadas maliciosamente, pueden causar un gran daño. La vulnerabilidad 0day a nivel de sistema operativo de Windows recientemente descubierta permite a los atacantes obtener el control total del sistema.
Las consecuencias de tener un sistema controlado por atacantes son graves, incluyendo la filtración de información personal, el colapso del sistema, la pérdida de datos, la pérdida de propiedades y la inserción de programas maliciosos. Para los usuarios de criptomonedas, 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 basado en la infraestructura Web2.
Análisis de parches
Analizando el código del parche, el problema parece estar en que el conteo de referencias de un objeto se ha manejado varias veces. Al revisar los comentarios del código anterior, descubrimos que el código anterior solo bloqueaba el objeto de la ventana y no bloqueaba el objeto del menú dentro de la ventana, lo que podría causar que el objeto del menú se referencie incorrectamente.
Validación de vulnerabilidades
Al analizar el contexto de la función de vulnerabilidad, encontramos que el menú pasado a xxxEnableMenuItem() generalmente ya ha sido bloqueado en la función superior, ¿qué objeto de menú específico debe protegerse? Al analizar más a fondo el manejo del objeto de menú en xxxEnableMenuItem, se descubrió que la función MenuItemState devuelve dos posibles menús: el menú principal de la ventana o un submenú( que incluye un sub-submenú).
Para verificar la vulnerabilidad, construimos una estructura de menú especial de cuatro capas y establecimos algunas condiciones específicas para eludir la detección en la función xxxEnableMenuItem. Cuando xxxRedrawTitle devuelve a la capa de usuario, eliminamos la relación de referencia entre los menús C y B, liberando con éxito el menú C. Finalmente, cuando la función xxxEnableMenuItem en el núcleo regresa a la función xxxRedrawTitle, el objeto de menú C referenciado ya no es válido.
Explotación de vulnerabilidades
Enfoque general
Antes de determinar el plan de explotación, normalmente realizamos un análisis teórico para evitar perder tiempo en un plan inviable. Esta explotación de vulnerabilidades consideró principalmente dos direcciones:
Ejecutar shellcode: Referencia a vulnerabilidades similares anteriores, pero en versiones más recientes de Windows puede enfrentar algunos problemas difíciles de resolver.
Modificar el token utilizando primitivas de lectura y escritura: incluso en los últimos dos años, todavía hay casos de referencia públicos. Necesitamos centrarnos en cómo controlar por primera vez cbwndextra como un valor muy grande cuando la memoria UAF es reutilizada.
Por lo tanto, dividimos todo el proceso de explotación en dos partes: cómo aprovechar la vulnerabilidad UAF para controlar el valor de cbwndextra, y cómo lograr operaciones de lectura y escritura estables una vez que se controla ese valor.
Escritura de datos inicial
Después de activar la vulnerabilidad, el sistema no necesariamente se bloqueará de inmediato. El uso incorrecto de los datos del objeto de ventana de memoria controlada ocurre principalmente en las funciones MNGetPopupFromMenu() y xxxMNUpdateShownMenu().
Utilizamos el objeto de nombre de ventana en la clase de ventana WNDClass para ocupar la memoria del objeto de menú liberado. La clave es encontrar una posición en la estructura de direcciones que podemos construir donde se pueda escribir datos de forma arbitraria, incluso si es solo un byte.
Finalmente encontramos dos soluciones viables en la función xxxRedrawWindow. Teniendo en cuenta algunos factores limitantes, optamos por la solución que depende de la operación AND 2 con la bandera y decidimos escribir en el cb-extra de HWNDClass en lugar de en el cb-extra del objeto de ventana.
disposición de memoria estable
Hemos diseñado un esquema de memoria para al menos tres objetos HWND de 0x250 bytes de forma continua. Liberar el objeto intermedio, ocupando un objeto HWNDClass de 0x250 bytes. Los datos del final del objeto HWND anterior se utilizan para la verificación mediante la bandera xxxRedrawWindow, y el objeto de menú del siguiente objeto HWND y el objeto HWNDClass actúan como el medio de lectura/escritura final.
Intentamos mantener el tamaño del objeto de ventana y el objeto HWNDClass一致, y aseguramos que los datos extendidos del objeto de ventana sean lo suficientemente grandes. A través de la dirección del controlador del núcleo filtrado en la memoria del montón, podemos determinar con precisión si el objeto de ventana solicitado está ordenado como se esperaba.
implementación de primitivos de lectura y escritura
Cualquier lectura de la primitiva original aún utiliza GetMenuBarInfo(). Cualquier escritura de la primitiva original utiliza SetClassLongPtr(). Aparte de la operación de escritura que reemplaza TOKEN que depende del objeto de clase de la segunda ventana, las demás escrituras utilizan el objeto de clase de la primera ventana utilizando un desplazamiento para implementarse.
Resumen
La vulnerabilidad win32k ha existido durante mucho tiempo, pero Microsoft está reescribiendo el código del núcleo relacionado en Rust, y los nuevos sistemas en el futuro podrían eliminar este tipo de vulnerabilidades.
El proceso de explotación de esta vulnerabilidad no es difícil, el principal desafío radica en cómo controlar la primera escritura. La vulnerabilidad sigue dependiendo en gran medida de la filtración de la dirección del manejador de la pila de escritorio, lo que sigue siendo un riesgo de seguridad para los sistemas antiguos.
El descubrimiento de esta vulnerabilidad puede deberse a una detección de cobertura de código más completa. Una vez que la API del sistema puede alcanzar el punto más profundo de vulnerabilidad en el camino de ejecución de la función objetivo, y el objeto de ventana está en un estado de referencia anidada múltiple, las pruebas de fuzz pueden descubrir esta vulnerabilidad.
En la detección de explotación de vulnerabilidades, además de centrarse en los puntos clave de las funciones que desencadenan vulnerabilidades, también se debe prestar atención a la disposición anómala de la memoria y a las lecturas y escrituras de desplazamientos no convencionales de datos adicionales de ventanas o clases de ventanas, lo que podría ayudar a descubrir vulnerabilidades de tipo similar.
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.
23 me gusta
Recompensa
23
3
Compartir
Comentar
0/400
OnChainDetective
· 08-01 09:21
ah clásico win32k... el patrón coincide con los anteriores exploits de APT, la verdad
Análisis profundo y técnicas de explotación de vulnerabilidades 0day a nivel del sistema Windows
Análisis y explotación de vulnerabilidades 0day a nivel de sistema de Microsoft
Introducción
Recientemente, un parche de seguridad de Microsoft ha solucionado una vulnerabilidad de escalada de privilegios en win32k que estaba siendo explotada por hackers. Esta vulnerabilidad afecta principalmente a versiones anteriores del sistema operativo Windows y parece ser ineficaz en Windows 11. Este artículo analizará en profundidad cómo los atacantes podrían seguir explotando este tipo de vulnerabilidades en el contexto de las nuevas medidas de protección que se están mejorando continuamente. Nuestro entorno de análisis es Windows Server 2016.
Contexto de la vulnerabilidad
0day vulnerabilidades se refieren a vulnerabilidades de seguridad que no han sido publicadas ni reparadas, similar al concepto de transacciones T+0 en el mercado financiero. Una vez que este tipo de vulnerabilidades son explotadas maliciosamente, pueden causar un gran daño. La vulnerabilidad 0day a nivel de sistema operativo de Windows recientemente descubierta permite a los atacantes obtener el control total del sistema.
Las consecuencias de tener un sistema controlado por atacantes son graves, incluyendo la filtración de información personal, el colapso del sistema, la pérdida de datos, la pérdida de propiedades y la inserción de programas maliciosos. Para los usuarios de criptomonedas, 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 basado en la infraestructura Web2.
Análisis de parches
Analizando el código del parche, el problema parece estar en que el conteo de referencias de un objeto se ha manejado varias veces. Al revisar los comentarios del código anterior, descubrimos que el código anterior solo bloqueaba el objeto de la ventana y no bloqueaba el objeto del menú dentro de la ventana, lo que podría causar que el objeto del menú se referencie incorrectamente.
Validación de vulnerabilidades
Al analizar el contexto de la función de vulnerabilidad, encontramos que el menú pasado a xxxEnableMenuItem() generalmente ya ha sido bloqueado en la función superior, ¿qué objeto de menú específico debe protegerse? Al analizar más a fondo el manejo del objeto de menú en xxxEnableMenuItem, se descubrió que la función MenuItemState devuelve dos posibles menús: el menú principal de la ventana o un submenú( que incluye un sub-submenú).
Para verificar la vulnerabilidad, construimos una estructura de menú especial de cuatro capas y establecimos algunas condiciones específicas para eludir la detección en la función xxxEnableMenuItem. Cuando xxxRedrawTitle devuelve a la capa de usuario, eliminamos la relación de referencia entre los menús C y B, liberando con éxito el menú C. Finalmente, cuando la función xxxEnableMenuItem en el núcleo regresa a la función xxxRedrawTitle, el objeto de menú C referenciado ya no es válido.
Explotación de vulnerabilidades
Enfoque general
Antes de determinar el plan de explotación, normalmente realizamos un análisis teórico para evitar perder tiempo en un plan inviable. Esta explotación de vulnerabilidades consideró principalmente dos direcciones:
Ejecutar shellcode: Referencia a vulnerabilidades similares anteriores, pero en versiones más recientes de Windows puede enfrentar algunos problemas difíciles de resolver.
Modificar el token utilizando primitivas de lectura y escritura: incluso en los últimos dos años, todavía hay casos de referencia públicos. Necesitamos centrarnos en cómo controlar por primera vez cbwndextra como un valor muy grande cuando la memoria UAF es reutilizada.
Por lo tanto, dividimos todo el proceso de explotación en dos partes: cómo aprovechar la vulnerabilidad UAF para controlar el valor de cbwndextra, y cómo lograr operaciones de lectura y escritura estables una vez que se controla ese valor.
Escritura de datos inicial
Después de activar la vulnerabilidad, el sistema no necesariamente se bloqueará de inmediato. El uso incorrecto de los datos del objeto de ventana de memoria controlada ocurre principalmente en las funciones MNGetPopupFromMenu() y xxxMNUpdateShownMenu().
Utilizamos el objeto de nombre de ventana en la clase de ventana WNDClass para ocupar la memoria del objeto de menú liberado. La clave es encontrar una posición en la estructura de direcciones que podemos construir donde se pueda escribir datos de forma arbitraria, incluso si es solo un byte.
Finalmente encontramos dos soluciones viables en la función xxxRedrawWindow. Teniendo en cuenta algunos factores limitantes, optamos por la solución que depende de la operación AND 2 con la bandera y decidimos escribir en el cb-extra de HWNDClass en lugar de en el cb-extra del objeto de ventana.
disposición de memoria estable
Hemos diseñado un esquema de memoria para al menos tres objetos HWND de 0x250 bytes de forma continua. Liberar el objeto intermedio, ocupando un objeto HWNDClass de 0x250 bytes. Los datos del final del objeto HWND anterior se utilizan para la verificación mediante la bandera xxxRedrawWindow, y el objeto de menú del siguiente objeto HWND y el objeto HWNDClass actúan como el medio de lectura/escritura final.
Intentamos mantener el tamaño del objeto de ventana y el objeto HWNDClass一致, y aseguramos que los datos extendidos del objeto de ventana sean lo suficientemente grandes. A través de la dirección del controlador del núcleo filtrado en la memoria del montón, podemos determinar con precisión si el objeto de ventana solicitado está ordenado como se esperaba.
implementación de primitivos de lectura y escritura
Cualquier lectura de la primitiva original aún utiliza GetMenuBarInfo(). Cualquier escritura de la primitiva original utiliza SetClassLongPtr(). Aparte de la operación de escritura que reemplaza TOKEN que depende del objeto de clase de la segunda ventana, las demás escrituras utilizan el objeto de clase de la primera ventana utilizando un desplazamiento para implementarse.
Resumen
La vulnerabilidad win32k ha existido durante mucho tiempo, pero Microsoft está reescribiendo el código del núcleo relacionado en Rust, y los nuevos sistemas en el futuro podrían eliminar este tipo de vulnerabilidades.
El proceso de explotación de esta vulnerabilidad no es difícil, el principal desafío radica en cómo controlar la primera escritura. La vulnerabilidad sigue dependiendo en gran medida de la filtración de la dirección del manejador de la pila de escritorio, lo que sigue siendo un riesgo de seguridad para los sistemas antiguos.
El descubrimiento de esta vulnerabilidad puede deberse a una detección de cobertura de código más completa. Una vez que la API del sistema puede alcanzar el punto más profundo de vulnerabilidad en el camino de ejecución de la función objetivo, y el objeto de ventana está en un estado de referencia anidada múltiple, las pruebas de fuzz pueden descubrir esta vulnerabilidad.
En la detección de explotación de vulnerabilidades, además de centrarse en los puntos clave de las funciones que desencadenan vulnerabilidades, también se debe prestar atención a la disposición anómala de la memoria y a las lecturas y escrituras de desplazamientos no convencionales de datos adicionales de ventanas o clases de ventanas, lo que podría ayudar a descubrir vulnerabilidades de tipo similar.