CONOCIMIENTO pertenece al mundo
El privilegio del núcleo de la vulnerabilidad CVE-2016-7255 escalada Windows ha recibido mucha atención de los medios. El mes de noviembre martes de parches, Microsoft lanzó un parche para esta vulnerabilidad como parte de MS16-135 boletín. CVE-2016-7255 se utilizó para llevar a cabo un ataque dirigido y una muestra fue encontrado en la naturaleza, de acuerdo con Microsoft. Google y Microsoft ya han confirmado el grupo hacker ruso APT28 utiliza una vulnerabilidad de Flash (CVE-2.016 a 7.855) junto con este kernel falla de elevación de privilegios para llevar a cabo un ataque dirigido. Google también ha discutido esta vulnerabilidad.
- https://security.googleblog.com/2016/10/disclosing-vulnerabilities-to-protect.html
- https://threatpost.com/microsoft-says-russian-apt-group-behind-zero-day-attacks/121722/
- http://securityaffairs.co/wordpress/53242/hacking/cve-2016-7255-zero-day.html
El equipo de investigación de la vulnerabilidad a McAfee Labs ha pasado una cantidad significativa de tiempo a analizar esta vulnerabilidad. En este post vamos a discutir brevemente algunos de nuestros hallazgos.
Comenzamos nuestro análisis con el parche de MS16-135, y muy pronto nos dimos cuenta de que MS16-135 win32k.sys actualizados sobre el sistema de destino. Nuestra investigación continuó con la comparación (a través de diffing binario) de los dos archivos WIN32K.SYS (antes y después de instalar el parche). Nuestro sistema de prueba se ejecutó Windows 7 Versión 6.1.7601.23584.
En cuanto a los resultados binarios Diferenciando, nos dimos cuenta de las siguientes funciones se modificaron.
Figura 1: El cambio de función en xxxNextWindow win32k.sys.
Después de algunas investigaciones preliminares concluimos el parche para CVE-2016-7255 se aplicó únicamente en el xxxNextWindow función en win32k.sys.
La siguiente captura de pantalla muestra una visión general muy alto nivel de los cambios realizados en xxxNextWindow (x, x):
Figura 2: Resultados diffing de alto nivel en el xxxNextWindow función.
Podemos ver algunos nueva lógica se ha añadido (resaltado en rojo) a la mitad de la función de patched. Zoom en el primer bloque básico recién insertado, podemos ver que el código introducido recientemente compara el valor de EAX + 0x23.
Figura 3: El bloque básico de primeros insertada en xxxNextWindow.
Vemos una lógica similar en el siguiente bloque básico recién insertado.
Figura 4: El segundo bloque básico insertada en xxxNextWindow.
Google ha declarado la vulnerabilidad "puede ser activado a través del sistema win32k.sys llamar NtSetWindowLongPtr () para el índice GWLP_ID en un identificador de ventana con GWL_STYLE establece en WS_CHILD."
De hecho, NtSetWindowLongPtr sólo ayuda a desencadenar esta vulnerabilidad, mientras que la causa fundamental radica en xxxNextWindow. Más específicamente, los parámetros establecidos por NtSetWindowLongPtr inapropiadas pueden desencadenar un escenario de "arbitraria dirección de escritura" en xxxNextWindow.
Ahora vamos a echar un vistazo a la versión de la descompilada xxxNextWindow sin parches (x, x ...).
Figura 5: La versión de la decompilados xxxNextWindow sin parchear.
Después de aplicar el parche, xxxNextWindow (x, x ...) se ve así:
Figura 6: La versión de la descompilada xxxNextWindow parcheado.
El código después de que el parche ha mejorado la verificación de parámetros con la instrucción condicional rama "(* (_ BYTE *) (v8 + 0x23) y 0xC0)! = 0x40".
En esta nueva declaración, v8 variable (en EAX) es el valor de retorno de una llamada GetNextQueueWindow anterior. (Véase la figura siguiente.)
Figura 7: v8 variable proviene de una llamada a GetNextQueueWindow: "v8 = _GetNextQueueWindow (V7, V31, 1);"
Un rápido vistazo a la aplicación de _GetNextQueueWindow (x, x, x, ...) revela que en realidad la función devuelve un puntero a la estructura tagWND.
La siguiente pantalla muestra la estructura tagWND en windbg:
Figura 8: La estructura de tagWND.
Analizando este código, sabemos que el campo en el offset 0x78 en la estructura tagWND es relevante para la vulnerabilidad. Las siguientes líneas de código decompilados de la función sin parchear ilustran que el campo en el offset 0x78 es relevante para la vulnerabilidad:
Figura 9: código problemático en el xxxNextWindow sin parchear.
Ahora el problema se convierte en simple: Si podemos controlar el valor en el v8 + 0x78, podremos escribir en una dirección arbitraria en la tierra del núcleo, y esto podría permitir la elevación de privilegios. Por suerte, una API de modo de usuario (NtSetWindowLongPtr) está disponible para establecer un valor arbitrario en esa posición.
La siguiente captura de pantalla muestra que el valor (0x41414141) pasamos a NtSetWindowLongPtr se refleja en la estructura tagWND, por lo que es fácil de obtener una escritura de memoria arbitraria a través de esta vulnerabilidad.
Figura 10: Un valor arbitrario se encuentra en la estructura tagWnd.
Para desencadenar la vulnerabilidad, la WS_CHILD atributo de la ventana recién creado debe ser asignado, y la GWLP_ID atributo debe establecerse con la ayuda de la API NtSetWindowLongPtr (). Por otra parte, el último obstáculo es poner en funcionamiento xxxNextWindow. Después de algunas investigaciones, hemos encontrado que podemos activar pulsando una combinación de teclas Alt + Tab o simular la pulsación de tecla con la API keybd_event.
Ahora que entendemos la causa de esta vulnerabilidad del alto nivel, vamos a tratar de reproducir la vulnerabilidad. Vamos a crear una ventana simple y rellenar algunos valores en su estructura tagWND.
HWND hwnd = CreateWindowEx (0, L "TestWnd", 0, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, 5, 5, 1, 1, hWndPrincipal, 0 / * hMenu * /, h, 0);
SetWindowLongPtr (hwnd, GWLP_ID, / * = 0xfffffff4 GWLP_ID * / 0x41414141);
Figura 11: Depuración del xxxNextWindow función vulnerable.
La captura de pantalla anterior muestra la salida de depuración en directo. Aquí el registro EBX está llevando a cabo el puntero a la estructura tagWND, y una violación de escritura ocurrirá muy pronto. Como se puede ver en la siguiente figura, el destino de la instrucción infractor es sólo la dirección (0x14 adición) que anteriormente hemos pasado en medio de la API NtSetWindowLongPtr, y esto ilustra perfectamente un ataque dirección de escritura arbitraria.
Figura 12: Escenario para un ataque dirección de escritura arbitraria.
Volvamos al parche de Microsoft, que comienza comprobando el valor 0x23 en el desplazamiento de la estructura tagWND. En el código parcheado, podemos ver la declaración recién introducido
(* (_ BYTE *) (v8 + 0x23) y 0xC0)! = 0x40
Cuando se trata de la versión revisada de la función, EBX apunta a la tagWND de la estructura ebx + 0x23 = 0x54;
0x54 y 0x40 = 0xc0; (1), 0x40 = 0x40 (2)!;
Ahora bien, esta afirmación se convierte en falsa. Por lo tanto, el programa salta las siguientes líneas de código que intentan modificar la memoria y evita la caída del programa (el acceso a escritura violación).
* (DWORD _ *) (* (* _ DWORD) (v30 + 0x78) + 0x14) & = 0xfffffffb;
* (DWORD _ *) (* (* _ DWORD) (v8 + 0x78) + 0x14) | = 4u;
¿Cómo puede aprovecharse esta vulnerabilidad para lograr una escalada de privilegios? En lugar de permitir la escritura de un valor arbitrario a una dirección arbitraria, esta vulnerabilidad puede cambiar sólo un bit; es decir, el valor en la dirección será lógicamente O-ed con 0x04 (o sus múltiplos) como se muestra a continuación:
Valor = Valor | 0x04;
Valor = Valor | 0x0400;
Valor = Valor | 0x040000
Valor = Valor | 0x04000000
En este caso, si el atacante puede encontrar una cierta variedad de objetos en la tierra del núcleo y aumentar el índice de la matriz de objetos (como tagWnd-> cbWndExtra) con esta lógica OR primitiva para causar un acceso fuera de límite, el atacante será capaz de obtener la dirección arbitraria leer habilidad / escritura desde el modo usuario (mediante el uso de algunas API de modo de usuario). Actualmente sabemos algunas habilidades de explotación de este tipo, tales como GetBitmapBits / SetBitmapBits (descubiertos por primera KeenTeam) o SetWindowText / GetWindowText.
Hoy en día, la escalada de privilegios utilizando una vulnerabilidad de modo de núcleo sigue siendo el principal vector para romper las cajas de arena de aplicación (EPM de Internet Explorer o AppContainer de Edge). Este camino ha sido bien demostrado por los más exitosos hazañas en estado salvaje dirigidos Internet Explorer / Edge / Adobe Reader y Flash que hemos visto. Contra las versiones actuales de Windows, con defensas multicapa, escapando de la caja de arena con una escalada de privilegios de kernel sigue siendo la primera opción del atacante. KeUsermodeCallback solía ser un tipo muy popular de la vulnerabilidad modo kernel de Windows que puede provocar la ejecución de código en modo kernel, como vimos en CVE-2.014 hasta 4.113 y CVE-2015-0057. El trabajo de Microsoft en hacer frente a las vulnerabilidades del kernel y la adición de más características de seguridad de mitigación ha llevado a una disminución en este tipo de ataque. En respuesta, los atacantes han comenzado a mirar en la fuente del kernel y vulnerabilidades de GDI. Windows 10 ya se ha restringido win32k llama en el borde, lo que reduce significativamente la superficie de ataque. Y Microsoft también ha solucionado el problema de divulgación de información de la memoria del núcleo que aprovecha la tabla de identificador compartido-GDI. Sin lugar a dudas, de almendra de explotación se hará más y más difícil. Sin embargo, prevemos que los atacantes usarán win32k la principal superficie de ataque para explotar el núcleo para lograr la ejecución de código o la elevación de privilegios. La batalla continuará en torno a este punto caliente para los atacantes y defensores.
Fuente: https: //securingtomorrow.mcafee.com
CONOCIMIENTO pertenece al mundo
No hay comentarios:
Publicar un comentario