Análisis de vulnerabilidades 0day en las primeras versiones de Microsoft Windows: desde la escalada de privilegios hasta la explotación del proceso completo
Análisis y explotación de vulnerabilidades 0day del sistema Windows de Microsoft
Recientemente, un parche de seguridad publicado por Microsoft ha reparado una vulnerabilidad de escalada de privilegios en win32k que estaba siendo explotada. Esta vulnerabilidad solo existe en versiones anteriores del sistema operativo Windows, y no se puede activar en Windows 11. Este artículo analizará cómo los atacantes continúan aprovechando este tipo de vulnerabilidades en el contexto de un continuo perfeccionamiento de la seguridad.
Contexto de la vulnerabilidad
Una vulnerabilidad 0day se refiere a una vulnerabilidad de seguridad que no ha sido divulgada ni reparada, similar al concepto de negociación T+0 en los mercados financieros. Una vez que se descubre este tipo de vulnerabilidad, puede ser explotada maliciosamente sin ser detectada, causando un daño enorme.
La vulnerabilidad 0day del sistema Windows descubierta esta vez podría permitir a los atacantes obtener el control total del sistema. Esto podría resultar en la filtración de información personal, fallos del sistema, pérdida de datos, pérdidas económicas y otras consecuencias graves. Desde la perspectiva de Web3, podría llevar al robo de claves privadas, la transferencia de activos digitales e incluso afectar todo el ecosistema Web3 basado en la infraestructura de Web2.
Análisis de parches
El análisis del código del parche revela que el problema radica en el manejo múltiple del recuento de referencias de objetos. Al revisar los comentarios del código fuente anterior, se puede deducir que el código anterior solo bloqueaba el objeto de la ventana, pero no bloqueaba el objeto del menú dentro de la ventana, lo que podría provocar una referencia incorrecta al objeto del menú.
Reproducción de vulnerabilidades
Al analizar el contexto de la función de vulnerabilidad, se descubrió que el menú que se pasa a xxxEnableMenuItem() generalmente ya ha sido bloqueado en la función superior. Un análisis adicional revela que el menú devuelto por la función MenuItemState puede ser el menú principal de la ventana, o puede ser un submenú o un sub-submenú.
Para activar la vulnerabilidad, se construyó una estructura de menú especial de cuatro niveles y se establecieron las siguientes características:
El ID del menú de nivel más bajo D debe ser del tipo de menú del sistema.
El menú de nivel superior A también debe ser un menú del sistema, pero se debe eliminar el tipo de menú del sistema correspondiente.
Eliminar la referencia del menú C en el menú B
La existencia del menú B parece ayudar a la liberación del menú C
Al devolver la capa de usuario en xxxRedrawTitle, elimina la relación de referencia entre los menús C y B y libera el menú C. De esta manera, cuando se regrese al punto de la función xxxEnableMenuItem, el objeto de menú C referenciado ya estará inválido.
Explotación de vulnerabilidades
La explotación de vulnerabilidades considera principalmente dos direcciones:
Ejecutar el código shellcode: refiérase a vulnerabilidades anteriores como CVE-2017-0263, pero en versiones más recientes de Windows puede enfrentar problemas de mecanismos de seguridad como el punto de entrada y SMEP.
Utilizar primitivas de lectura y escritura para modificar la dirección del token: en los últimos años, hay múltiples ejemplos públicos a los que se puede referir, que tienen aplicabilidad general en la disposición de la memoria de la pila de escritorio y en las primitivas de lectura y escritura. La clave es analizar cómo controlar por primera vez cbwndextra para que tenga un valor extremadamente grande al reutilizar la memoria de UAF.
En esta ocasión, se utiliza el segundo plan, dividiendo todo el proceso en dos pasos:
Utilizar la vulnerabilidad UAF para controlar el valor de cbwndextra
Controlar cbwndextra para lograr primitivas de lectura y escritura estables
Primera escritura de datos
Después de que se activa la vulnerabilidad, el sistema puede usar incorrectamente los datos del objeto de ventana controlado en MNGetPopupFromMenu() y xxxMNUpdateShownMenu(). Usamos el objeto de nombre de ventana en la clase de ventana WNDClass para ocupar el objeto de menú liberado.
La clave es encontrar una ubicación en la estructura de dirección que podamos construir donde se pueda escribir datos de manera arbitraria, aunque solo sea un byte. Finalmente, se eligió la solución en la función xxxRedrawWindow, controlando los datos de memoria del objeto anterior a través de la memoria de diseño para determinar mediante la bandera del objeto en la función.
disposición de memoria estable
Diseñar al menos tres objetos HWND de 0x250 bytes consecutivos, liberar el del medio y ocuparlo con un objeto HWNDClass. Los datos del final del objeto HWND anterior se utilizan para verificar mediante la bandera en xxxRedrawWindow, el objeto de menú del siguiente objeto HWND y el objeto HWNDClass se utilizan como medio de lectura/escritura final.
A través de la dirección del manejador del núcleo filtrado en la memoria de la pila, se puede determinar con precisión si los objetos de ventana solicitados están organizados en el orden esperado.
Leer y escribir primitivos
Para leer cualquier primitivo, utiliza GetMenuBarInfo(); para escribir cualquier primitivo, utiliza SetClassLongPtr(). A excepción de la escritura de sustitución de TOKEN, las demás escrituras se realizan utilizando un desplazamiento con el objeto de class del primer objeto de ventana.
Resumen
La vulnerabilidad win32k tiene una larga historia, pero Microsoft está intentando reestructurar el código relacionado con Rust, por lo que en los futuros sistemas este tipo de vulnerabilidades podrían ser erradicadas.
El proceso de explotación de esta vulnerabilidad es relativamente simple, siendo el principal desafío cómo controlar la primera escritura. 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 sistemas obsoletos.
El descubrimiento de esta vulnerabilidad puede deberse a una mejor detección de la cobertura del código.
Para la detección de explotación de vulnerabilidades, además de centrarse en los puntos clave de la función de activación, también se debe prestar atención a la disposición anómala de la memoria y a la lectura/escritura de desplazamientos de datos en ventanas.
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.
6 me gusta
Recompensa
6
4
Compartir
Comentar
0/400
ChainSauceMaster
· hace16h
¿Qué le pasa al viejo win? Hay vulnerabilidades todos los días.
Ver originalesResponder0
FloorPriceWatcher
· hace16h
win11 ha escapado de un desastre
Ver originalesResponder0
MEVSandwichVictim
· hace16h
Los paquetes de vulnerabilidades son un juego de ilusiones. Quien especula, toma a la gente por tonta.
Análisis de vulnerabilidades 0day en las primeras versiones de Microsoft Windows: desde la escalada de privilegios hasta la explotación del proceso completo
Análisis y explotación de vulnerabilidades 0day del sistema Windows de Microsoft
Recientemente, un parche de seguridad publicado por Microsoft ha reparado una vulnerabilidad de escalada de privilegios en win32k que estaba siendo explotada. Esta vulnerabilidad solo existe en versiones anteriores del sistema operativo Windows, y no se puede activar en Windows 11. Este artículo analizará cómo los atacantes continúan aprovechando este tipo de vulnerabilidades en el contexto de un continuo perfeccionamiento de la seguridad.
Contexto de la vulnerabilidad
Una vulnerabilidad 0day se refiere a una vulnerabilidad de seguridad que no ha sido divulgada ni reparada, similar al concepto de negociación T+0 en los mercados financieros. Una vez que se descubre este tipo de vulnerabilidad, puede ser explotada maliciosamente sin ser detectada, causando un daño enorme.
La vulnerabilidad 0day del sistema Windows descubierta esta vez podría permitir a los atacantes obtener el control total del sistema. Esto podría resultar en la filtración de información personal, fallos del sistema, pérdida de datos, pérdidas económicas y otras consecuencias graves. Desde la perspectiva de Web3, podría llevar al robo de claves privadas, la transferencia de activos digitales e incluso afectar todo el ecosistema Web3 basado en la infraestructura de Web2.
Análisis de parches
El análisis del código del parche revela que el problema radica en el manejo múltiple del recuento de referencias de objetos. Al revisar los comentarios del código fuente anterior, se puede deducir que el código anterior solo bloqueaba el objeto de la ventana, pero no bloqueaba el objeto del menú dentro de la ventana, lo que podría provocar una referencia incorrecta al objeto del menú.
Reproducción de vulnerabilidades
Al analizar el contexto de la función de vulnerabilidad, se descubrió que el menú que se pasa a xxxEnableMenuItem() generalmente ya ha sido bloqueado en la función superior. Un análisis adicional revela que el menú devuelto por la función MenuItemState puede ser el menú principal de la ventana, o puede ser un submenú o un sub-submenú.
Para activar la vulnerabilidad, se construyó una estructura de menú especial de cuatro niveles y se establecieron las siguientes características:
Al devolver la capa de usuario en xxxRedrawTitle, elimina la relación de referencia entre los menús C y B y libera el menú C. De esta manera, cuando se regrese al punto de la función xxxEnableMenuItem, el objeto de menú C referenciado ya estará inválido.
Explotación de vulnerabilidades
La explotación de vulnerabilidades considera principalmente dos direcciones:
Ejecutar el código shellcode: refiérase a vulnerabilidades anteriores como CVE-2017-0263, pero en versiones más recientes de Windows puede enfrentar problemas de mecanismos de seguridad como el punto de entrada y SMEP.
Utilizar primitivas de lectura y escritura para modificar la dirección del token: en los últimos años, hay múltiples ejemplos públicos a los que se puede referir, que tienen aplicabilidad general en la disposición de la memoria de la pila de escritorio y en las primitivas de lectura y escritura. La clave es analizar cómo controlar por primera vez cbwndextra para que tenga un valor extremadamente grande al reutilizar la memoria de UAF.
En esta ocasión, se utiliza el segundo plan, dividiendo todo el proceso en dos pasos:
Primera escritura de datos
Después de que se activa la vulnerabilidad, el sistema puede usar incorrectamente los datos del objeto de ventana controlado en MNGetPopupFromMenu() y xxxMNUpdateShownMenu(). Usamos el objeto de nombre de ventana en la clase de ventana WNDClass para ocupar el objeto de menú liberado.
La clave es encontrar una ubicación en la estructura de dirección que podamos construir donde se pueda escribir datos de manera arbitraria, aunque solo sea un byte. Finalmente, se eligió la solución en la función xxxRedrawWindow, controlando los datos de memoria del objeto anterior a través de la memoria de diseño para determinar mediante la bandera del objeto en la función.
disposición de memoria estable
Diseñar al menos tres objetos HWND de 0x250 bytes consecutivos, liberar el del medio y ocuparlo con un objeto HWNDClass. Los datos del final del objeto HWND anterior se utilizan para verificar mediante la bandera en xxxRedrawWindow, el objeto de menú del siguiente objeto HWND y el objeto HWNDClass se utilizan como medio de lectura/escritura final.
A través de la dirección del manejador del núcleo filtrado en la memoria de la pila, se puede determinar con precisión si los objetos de ventana solicitados están organizados en el orden esperado.
Leer y escribir primitivos
Para leer cualquier primitivo, utiliza GetMenuBarInfo(); para escribir cualquier primitivo, utiliza SetClassLongPtr(). A excepción de la escritura de sustitución de TOKEN, las demás escrituras se realizan utilizando un desplazamiento con el objeto de class del primer objeto de ventana.
Resumen
La vulnerabilidad win32k tiene una larga historia, pero Microsoft está intentando reestructurar el código relacionado con Rust, por lo que en los futuros sistemas este tipo de vulnerabilidades podrían ser erradicadas.
El proceso de explotación de esta vulnerabilidad es relativamente simple, siendo el principal desafío cómo controlar la primera escritura. 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 sistemas obsoletos.
El descubrimiento de esta vulnerabilidad puede deberse a una mejor detección de la cobertura del código.
Para la detección de explotación de vulnerabilidades, además de centrarse en los puntos clave de la función de activación, también se debe prestar atención a la disposición anómala de la memoria y a la lectura/escritura de desplazamientos de datos en ventanas.