Análisis de vulnerabilidades 0day de Microsoft: podría poner en riesgo la seguridad de la infraestructura Web3
El mes pasado, el parche de seguridad de Microsoft incluía una vulnerabilidad de elevación de privilegios en win32k que se estaba explotando en la naturaleza. Esta vulnerabilidad parece existir solo en versiones tempranas del sistema y no se puede desencadenar en Windows 11. La explotación de este tipo de vulnerabilidades ha existido durante mucho tiempo; este artículo analizará cómo los atacantes podrían continuar aprovechando esta vulnerabilidad en el contexto de las medidas de mitigación nuevas y en constante mejora. Completamos todo el proceso de análisis en un entorno de Windows Server 2016.
Una vulnerabilidad 0day se refiere a una vulnerabilidad que no ha sido divulgada ni reparada, y que puede ser explotada maliciosamente por hackers sin ser detectados, a menudo con un gran potencial destructivo. La vulnerabilidad 0day descubierta en esta ocasión se encuentra a nivel del sistema operativo Windows, y los hackers pueden usarla para obtener el control total de Windows. Una vez controlado, esto puede llevar a consecuencias como el robo de información personal, la pérdida de datos por fallos del sistema, pérdidas financieras e implantación de malware. A pequeña escala, puede resultar en el robo de claves privadas y la transferencia de activos digitales; a gran escala, puede amenazar a todo el ecosistema Web3 que opera sobre la infraestructura de Web2.
El análisis del parche muestra que parece ser solo un problema de que el conteo de referencias de un objeto se ha procesado varias veces. Pero al revisar los comentarios del código anterior, se descubre 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ú.
Analizando el contexto de la función de vulnerabilidad, descubrimos que el menú pasado a xxxEnableMenuItem() generalmente ya ha sido bloqueado en la función superior, entonces, ¿qué objeto de menú se debe proteger aquí? Un análisis más profundo revela que hay dos posibilidades para el menú devuelto en xxxEnableMenuItem: el menú principal de la ventana o un submenú del menú (, e incluso un sub-submenú ).
Para construir el POC, diseñamos una estructura de menú especial de cuatro capas y realizamos configuraciones especiales en cada menú para detectar a través de funciones. Cuando xxxRedrawTitle devuelve la capa de usuario, eliminamos la relación de referencia entre el menú C y el menú B, liberando con éxito el menú C. Así, en el punto de retorno de la función xxxEnableMenuItem, el objeto del menú C que iba a ser referenciado ya es inválido.
Para la implementación de EXP, consideramos principalmente dos direcciones: ejecutar código shellcode y utilizar primitivas de lectura/escritura para modificar la dirección del token. Teniendo en cuenta los mecanismos de seguridad de las versiones más recientes de Windows, elegimos la segunda opción. Todo el proceso de explotación se puede dividir en dos partes: cómo aprovechar la vulnerabilidad UAF para controlar el valor de cbwndextra y cómo establecer primitivas de lectura/escritura estables.
A través de un diseño cuidadoso de la disposición de la memoria, utilizamos el objeto de nombre de ventana de la clase de ventana para ocupar y liberar el objeto del menú, y encontramos el momento oportuno para escribir datos en la función xxxRedrawWindow. Para lograr una disposición de memoria estable, diseñamos una estructura de tres objetos HWND consecutivos y utilizamos la dirección del manejador del núcleo filtrado en la memoria heap para juzgar con precisión el orden de disposición de los objetos.
En términos de lectura y escritura de primitivas, utilizamos GetMenuBarInfo() para implementar lecturas arbitrarias y SetClassLongPtr() para implementar escrituras arbitrarias. Aparte de la operación de escritura que reemplaza el TOKEN y que depende del objeto de clase de la segunda ventana, las demás escrituras utilizan el objeto de clase de la primera ventana a través de desplazamientos.
En general, aunque la vulnerabilidad de win32k tiene una larga historia, Microsoft ha intentado reestructurar esa parte del código del núcleo utilizando Rust en la versión preliminar de Windows 11, y en el futuro, este tipo de vulnerabilidades podrían ser eliminadas. El proceso de explotación de esta vulnerabilidad es relativamente simple, siendo el principal desafío cómo controlar la primera escritura. El descubrimiento de esta vulnerabilidad podría depender de una detección más completa de la cobertura del código. Para la detección de vulnerabilidades, además de centrarse en los puntos clave de la función de activación, la detección de disposiciones de memoria anómalas y la lectura/escritura de desplazamientos de datos también podría ser una vía para descubrir vulnerabilidades similares.
Ver originales
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.
16 me gusta
Recompensa
16
5
Compartir
Comentar
0/400
TopBuyerBottomSeller
· 07-21 07:25
¡Otra razón para actualizar a Windows 11!
Ver originalesResponder0
FlatTax
· 07-20 03:35
Escándalo, viejo Microsoft, no hagas trucos.
Ver originalesResponder0
SurvivorshipBias
· 07-20 03:34
¿De quién es este sistema que todavía usa win32k?
Ver originalesResponder0
just_another_wallet
· 07-20 03:33
Casi explota mi vieja moneda, me deja la piel de gallina.
Ver originalesResponder0
MrRightClick
· 07-20 03:14
El único sistema que ni siquiera los perros quieren es Windows 11.
Se revela una vulnerabilidad 0day de Microsoft, la seguridad de la infraestructura Web3 podría estar amenazada.
Análisis de vulnerabilidades 0day de Microsoft: podría poner en riesgo la seguridad de la infraestructura Web3
El mes pasado, el parche de seguridad de Microsoft incluía una vulnerabilidad de elevación de privilegios en win32k que se estaba explotando en la naturaleza. Esta vulnerabilidad parece existir solo en versiones tempranas del sistema y no se puede desencadenar en Windows 11. La explotación de este tipo de vulnerabilidades ha existido durante mucho tiempo; este artículo analizará cómo los atacantes podrían continuar aprovechando esta vulnerabilidad en el contexto de las medidas de mitigación nuevas y en constante mejora. Completamos todo el proceso de análisis en un entorno de Windows Server 2016.
Una vulnerabilidad 0day se refiere a una vulnerabilidad que no ha sido divulgada ni reparada, y que puede ser explotada maliciosamente por hackers sin ser detectados, a menudo con un gran potencial destructivo. La vulnerabilidad 0day descubierta en esta ocasión se encuentra a nivel del sistema operativo Windows, y los hackers pueden usarla para obtener el control total de Windows. Una vez controlado, esto puede llevar a consecuencias como el robo de información personal, la pérdida de datos por fallos del sistema, pérdidas financieras e implantación de malware. A pequeña escala, puede resultar en el robo de claves privadas y la transferencia de activos digitales; a gran escala, puede amenazar a todo el ecosistema Web3 que opera sobre la infraestructura de Web2.
El análisis del parche muestra que parece ser solo un problema de que el conteo de referencias de un objeto se ha procesado varias veces. Pero al revisar los comentarios del código anterior, se descubre 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ú.
Analizando el contexto de la función de vulnerabilidad, descubrimos que el menú pasado a xxxEnableMenuItem() generalmente ya ha sido bloqueado en la función superior, entonces, ¿qué objeto de menú se debe proteger aquí? Un análisis más profundo revela que hay dos posibilidades para el menú devuelto en xxxEnableMenuItem: el menú principal de la ventana o un submenú del menú (, e incluso un sub-submenú ).
Para construir el POC, diseñamos una estructura de menú especial de cuatro capas y realizamos configuraciones especiales en cada menú para detectar a través de funciones. Cuando xxxRedrawTitle devuelve la capa de usuario, eliminamos la relación de referencia entre el menú C y el menú B, liberando con éxito el menú C. Así, en el punto de retorno de la función xxxEnableMenuItem, el objeto del menú C que iba a ser referenciado ya es inválido.
Para la implementación de EXP, consideramos principalmente dos direcciones: ejecutar código shellcode y utilizar primitivas de lectura/escritura para modificar la dirección del token. Teniendo en cuenta los mecanismos de seguridad de las versiones más recientes de Windows, elegimos la segunda opción. Todo el proceso de explotación se puede dividir en dos partes: cómo aprovechar la vulnerabilidad UAF para controlar el valor de cbwndextra y cómo establecer primitivas de lectura/escritura estables.
A través de un diseño cuidadoso de la disposición de la memoria, utilizamos el objeto de nombre de ventana de la clase de ventana para ocupar y liberar el objeto del menú, y encontramos el momento oportuno para escribir datos en la función xxxRedrawWindow. Para lograr una disposición de memoria estable, diseñamos una estructura de tres objetos HWND consecutivos y utilizamos la dirección del manejador del núcleo filtrado en la memoria heap para juzgar con precisión el orden de disposición de los objetos.
En términos de lectura y escritura de primitivas, utilizamos GetMenuBarInfo() para implementar lecturas arbitrarias y SetClassLongPtr() para implementar escrituras arbitrarias. Aparte de la operación de escritura que reemplaza el TOKEN y que depende del objeto de clase de la segunda ventana, las demás escrituras utilizan el objeto de clase de la primera ventana a través de desplazamientos.
En general, aunque la vulnerabilidad de win32k tiene una larga historia, Microsoft ha intentado reestructurar esa parte del código del núcleo utilizando Rust en la versión preliminar de Windows 11, y en el futuro, este tipo de vulnerabilidades podrían ser eliminadas. El proceso de explotación de esta vulnerabilidad es relativamente simple, siendo el principal desafío cómo controlar la primera escritura. El descubrimiento de esta vulnerabilidad podría depender de una detección más completa de la cobertura del código. Para la detección de vulnerabilidades, además de centrarse en los puntos clave de la función de activación, la detección de disposiciones de memoria anómalas y la lectura/escritura de desplazamientos de datos también podría ser una vía para descubrir vulnerabilidades similares.