Análisis de vulnerabilidades graves del sistema Windows de Microsoft

Recientemente, un parche de seguridad lanzado por Microsoft ha corregido una vulnerabilidad de escalación de privilegios en el núcleo de Windows que estaba siendo explotada por hackers. Esta vulnerabilidad afecta principalmente a las versiones anteriores del sistema Windows y no se puede activar en Windows 11. Este tipo de vulnerabilidades ha existido durante mucho tiempo, y este artículo explorará cómo los atacantes continúan aprovechando estas vulnerabilidades en el contexto de un fortalecimiento constante de la seguridad.

Este análisis se realizó en un entorno de Windows Server 2016.

Contexto de la vulnerabilidad

Esta es una vulnerabilidad de día cero, que se refiere a una vulnerabilidad del sistema que aún no ha sido divulgada ni reparada. Los hackers pueden aprovechar la vulnerabilidad de día cero para llevar a cabo ataques sin que los usuarios se den cuenta, lo que tiene un gran potencial destructivo.

La vulnerabilidad de día cero descubierta se encuentra en el nivel del núcleo del sistema Windows, y los hackers pueden obtener el control completo de Windows a través de esta vulnerabilidad. Esto podría llevar a graves consecuencias como la filtración de la privacidad del usuario, fallos del sistema, pérdida de datos y pérdidas financieras. Desde la perspectiva de Web3, es posible que las claves privadas de los usuarios sean robadas, lo que pone en riesgo la transferencia de activos digitales. En un sentido más amplio, esta vulnerabilidad podría incluso afectar a todo el ecosistema Web3 que opera sobre la infraestructura de Web2.

Análisis de vulnerabilidades

Al analizar el código del parche, descubrimos que el problema radica en que el recuento de referencias de un objeto se está procesando múltiples veces. Al revisar los comentarios del código fuente de win32k de versiones anteriores, se puede entender 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ú.

Un análisis más detallado revela que el menú pasado a la función xxxEnableMenuItem() generalmente ha sido bloqueado en una función superior. Entonces, ¿qué objeto de menú se debe proteger aquí? Después de investigar, se ha encontrado que la función MenuItemState dentro de xxxEnableMenuItem podría devolver dos tipos de menú: el menú principal de la ventana o un submenú(, e incluso un sub-submenú).

Explotación de vulnerabilidades

Para verificar la vulnerabilidad, hemos construido una estructura de menú especial de cuatro capas y establecido algunas condiciones específicas:

1. El ID del menú de nivel más bajo D debe ser del tipo de menú del sistema, como cerrar menú (0xf060)
2. El menú superior A también debe ser un menú del sistema, pero se debe eliminar el elemento de menú 0xf060.
3. Eliminar la referencia del menú C en el menú B
4. La existencia del menú B parece tener un impacto en el lanzamiento del menú C

Al activar el fallo, al devolver la capa de usuario en xxxRedrawTitle se elimina la asociación del menú C y B, liberando con éxito el menú C. Cuando la función xxxEnableMenuItem en el núcleo regresa a xxxRedrawTitle, el objeto de menú C que está a punto de ser referenciado ya ha caducado.

Análisis de explotación de vulnerabilidades

Al diseñar un plan de explotación de vulnerabilidades, consideramos principalmente dos direcciones:

1. Ejecutar shellcode: Referirse a los métodos de las CVE-2017-0263 y CVE-2016-0167. Pero en versiones más recientes de Windows, el punto de entrada para la ejecución del shellcode y mecanismos de seguridad como SMEP pueden presentar obstáculos.

2. Modificar la dirección del token utilizando primitivas de lectura/escritura: este método tiene una buena versatilidad. La clave es analizar cómo controlar por primera vez cbwndextra como un valor extremadamente grande durante la reutilización de memoria UAF.

Dividimos la explotación de vulnerabilidades en dos pasos: controlar el valor de cbwndextra y lograr primitivas de lectura y escritura estables.

primera escritura de datos

Los errores del sistema al usar datos de objetos de ventana en memoria controlada ocurren principalmente en la función xxxEnableMenuItem MNGetPopupFromMenu() y xxxMNUpdateShownMenu(). Utilizamos el objeto de nombre de ventana de la clase de ventana WNDClass para ocupar y liberar la memoria de objetos de menú.

La clave es encontrar una estructura de dirección que se pueda escribir de forma arbitraria, aunque solo sea un byte. Finalmente elegimos la solución en la función xxxRedrawWindow, escribiendo en cb-extra de HWNDClass mediante la operación AND 2.

diseño de memoria

Hemos diseñado la disposición de memoria de tres objetos HWND de 0x250 bytes en continuidad, liberando el objeto intermedio y ocupando un objeto HWNDClass de 0x250 bytes. Los datos del final del objeto HWND anterior se utilizan para la verificación a través de xxxRedrawWindow, y el menú del objeto HWND posterior y el objeto HWNDClass se utilizan para las operaciones de lectura y escritura finales.

Intentamos que el tamaño del objeto de ventana y del objeto HWNDClass sea consistente, y determinamos con precisión si la disposición de los objetos cumple con las expectativas a través de la dirección del manejador del núcleo filtrado.

lectura y escritura de primitivos

Para leer cualquier primitiva, utiliza GetMenuBarInfo(); para escribir cualquier primitiva, utiliza SetClassLongPtr(). A excepción de la escritura de TOKEN, todas las demás escrituras se realizan utilizando el objeto de clase del primer objeto de ventana para realizar la escritura desplazada.

Resumen

1. Microsoft está reestructurando el código del núcleo relacionado con win32k utilizando Rust, en el futuro, este tipo de vulnerabilidades podrían ser eliminadas en el nuevo sistema.

2. El proceso de explotación de esta vulnerabilidad es relativamente simple y se basa principalmente en la filtración de la dirección del manejador de la pila de escritorio. Si no se resuelve este problema de manera exhaustiva, los sistemas antiguos seguirán presentando riesgos de seguridad.

3. El descubrimiento de esta vulnerabilidad puede deberse a una detección de cobertura de código más completa.

4. En la detección de explotación de vulnerabilidades, además de centrarse en los puntos clave de las funciones que desencadenan las vulnerabilidades, también se debe prestar atención a la detección de lecturas y escrituras anómalas en los desplazamientos de datos adicionales de la disposición de memoria y de las clases de ventana.