viernes, 9 de febrero de 2018

Recientemente, empezamos a recibir eventos sospechosos de nuestro Sandbox interno Exploit Checker plugin.

Recientemente, empezamos a recibir eventos sospechosos de nuestro Sandbox interno Exploit Checker plugin. Nuestra heurística para la ejecución de código de modo supervisor en el espacio de direcciones de usuario se estaba activando constantemente, y un archivo ejecutable se estaba marcando para su posterior análisis. Al principio, parecía que habíamos encontrado una vulnerabilidad de escalamiento de privilegios locales de día cero para Windows, pero la muestra que estaba activando los eventos Exploit Checker resultó ser el ejecutable ejecutable GundamOnline. exe firmado limpio, parte del juego online multijugador Mobile Suit Gundam Online de BANDAI NAMCO Online Inc.

La muestra inicial se empaca utilizando un empaquetador personalizado y contiene técnicas de anti-análisis que complican el análisis estático. Por ejemplo, intenta detectar si se está lanzando dentro de una máquina virtual realizando una conocida rutina de detección de hipervisor de VMware. Primero carga el registro EAX con el valor mágico del hipervisor VMXh, y el registro ECX con el valor 0x0A, que es un comando especial para recibir la versión del hipervisor. A continuación, ejecuta un comando "in" en el hipervisor VMware I\O del puerto 0x5658. Si el registro EBX se sobrescribe con VMXh como resultado de esa operación, significa que el archivo ejecutable se está ejecutando en la máquina VMware.

Nuestros registros de ejecución del arenero mostraron que la página de memoria del espacio de usuario es llamada desde el controlador bandainamcoonline. sys inmediatamente después de la petición IOCTL 0xAA012044 al objeto dispositivo \\. \\ Htsysm7838 que es creado por el controlador. El controlador en sí mismo se instala justo antes de eso. Primero se coloca en el directorio C: \Windows\SysWOW64\ por un ejecutable GundamOnline, se carga usando NtLoadDriver () y se elimina inmediatamente después.

Normalmente, este tipo de comportamiento no debe permitirse debido a SMEP (Supervisor Mode Execution Prevention). Esta es una característica de seguridad presente en los procesadores Intel más recientes que restringe la ejecución en modo supervisor en las páginas de memoria del usuario. El tipo de página se determina utilizando el indicador Usuario/Supervisor en la entrada de la tabla de páginas. Si se llama a una página de memoria de usuario mientras está en el modo de ejecución del supervisor, SMEP genera una excepción por violación de acceso y, como resultado, el sistema activará una comprobación de fallo y se detendrá. Esto se conoce comúnmente como un BSOD.


El conductor caído en sí mismo es un conductor legítimo, firmado con un certificado expedido a NAMCO BANDAI Online Inc.

El período de validez del certificado nos dice dos cosas. En primer lugar, este certificado ha sido válido desde 2012, lo que podría significar que la primera versión vulnerable del controlador se liberó más o menos al mismo tiempo. Sin embargo, no pudimos encontrar una; la primera muestra de bandainamcoonline. sys que encontramos data de noviembre de 2015. En segundo lugar, debido a que expiró hace más de tres años, usted podría ser perdonado por pensar que es imposible instalar un controlador firmado con este certificado en un sistema. En realidad, no hay nada que le impida instalar y cargar un controlador con un período de validez de certificado caducado.

Para encontrar la causa del desencadenante heurístico, necesitamos hacer un análisis estático del conductor mismo. En la función DriverEntry, primero decodifica la cadena de nombres del objeto del dispositivo en la memoria y, a continuación, crea el dispositivo. Las otras dos cadenas codificadas - bandainamcoonline y bandainamcoonline. sys - no se utilizan en el driver.

El conductor en sí mismo es muy pequeño y contiene sólo tres funciones principales registradas. La función IRP_MJ_DEVICE_CONTROL, que gestiona las solicitudes, sólo acepta dos IOCTL: 0xAA012044 y 0xAA013044. Cuando se llama, comprueba el tamaño de los buffers de entrada y salida y eventualmente llama a la función ExecuteUserspaceCode, transmitiendo el contenido del buffer de entrada.

La función ExecuteUserspaceCode ejecuta una sola comprobación en el búfer de entrada, que contiene un puntero a una función de espacio de usuario o un código shell, y desactiva SMEP mientras guarda los valores de registro CR4 antiguos. Luego llama a esa función, pasándole un puntero a la función MmGetSystemRutineAddress como argumento. Después restaura el estado original del registro, habilitando de nuevo SMEP.

Para poder llamar directamente la función de usuario desde el controlador de puntero suministrado es necesario quitar primero un bit específico en el registro CR4 para detener temporalmente SMEP, que es lo que hace la función DisableSMEP. A continuación, la función EnableSMEP restablece los valores originales del CR4.

La vulnerabilidad en este caso es que, aparte de las comprobaciones básicas sobre el formato del búfer de entrada, no se realizan comprobaciones adicionales. Por lo tanto, cualquier usuario del sistema puede utilizar este controlador para elevar sus privilegios y ejecutar código arbitrario en el anillo 0 del sistema operativo. Incluso si el controlador no está presente en el sistema, un atacante puede registrarlo con las funciones de la API de Windows y explotar el fallo.

Nos dimos cuenta de que esta vulnerabilidad es exactamente igual a la encontrada en el driver de Capcom el año pasado.

La diferenciación binaria de bandainamcoonline. sys y capcom. sys demuestra exactamente eso, mostrando que casi no hay diferencias entre los dos drivers. Las únicas variaciones leves son las cadenas codificadas y digi

No hay comentarios.:

Publicar un comentario