[IMPORTANTE] XIGNCODE3 xhunter1.sys

  • Hola Invitado ¿Quieres conversar con todos los usuarios de GamerzHacking?, No esperes mas y entra al canal de Discord dando clic AQUI
  • Hola Invitado, hemos decidido no subir mas videos de Game Hacking a la mierda de YouTube, mas informacion AQUI. Nuestro nuevo canal de videos ahora es COCOSCOPE.
  • Hola Invitado ¿Quieres formar parte del Staff de GamerzHacking?, No esperes mas y entra al siguiente enlace AQUI
  • Hola Invitado ¿Eres programador y quieres pertenercer GamerzHacking?, No esperes mas y entra a postular aqui AQUI

C0de

Administrador
Miembro del equipo
1 Nov 2015
1.227
251
63
28
Lima
gamerzhacking.com
Desde el proceso filtrado en Mode-Kernel al SISTEMA

XIGNCODE3 es una solución popular de anti-trampas que se proporciona en base a B2B2C, que se encuentra principalmente en los juegos en línea. Esta clase de software es conocida por su naturaleza invasiva, actuando efectivamente como rootkits en modo de usuario en el sistema del usuario que adopta prácticas de escaneo muy agresivas para detectar herramientas de engaño conocidas.

En este caso, el anti-trampa en cuestión también carga un controlador firmado en el sistema del usuario, con el que posteriormente interactúa desde el modo de usuario para realizar ciertas tareas. En esta publicación, exploraremos el mecanismo de comunicación en su lugar y demostraremos una de las vulnerabilidades encontradas en el controlador.

Antes de comenzar, vale la pena señalar que cualquier proceso y cualquier usuario del sistema pueden interactuar con el controlador en cuestión. El controlador solo se descarga del sistema cuando no hay ningún controlador abierto en su dispositivo. De manera similar, el controlador permite que múltiples procesos interactúen con él al mismo tiempo, sin ningún mecanismo de autenticación para detectar un posible uso malicioso.

El principal punto de interés aquí es la función DriverEntry, que como su nombre indica es el punto de entrada para cualquier controlador de Windows dado. Se sabe que el nombre del dispositivo es el nombre del controlador en sí mismo, por lo que la prioridad principal aquí es identificar cualquier función de devolución de llamada del dispositivo, tal como están definidas en DriverObject.

Al examinar la llamada IoCreateDevice dentro de DriverEntry, vemos lo siguiente:

313

En este contexto, el registro RDI contiene un puntero al propio DriverObject del controlador. Mirando la estructura de
Por favor, Acceder o Registrarse para ver el contenido de las URL!
, podemos identificar las siguientes funciones de devolución de llamada:

C++:
Por favor, Acceder o Registrarse para ver el codigo.
Dado esto, podemos deducir que las comunicaciones con el controlador se facilitan a través de las operaciones de escritura de archivos en lugar de a través de IOCTL.

Al pasar al controlador de control del sistema de archivos, vemos lo siguiente:

314

Al leer el desamblado dado y lo que hace con el IRP que se le da, descubrimos lo siguiente: * Se espera que la operación de escritura tenga una longitud de 0x270 bytes * Se espera que la primera DWORD del contenido del paquete sea la constante 0x270 como bien (se presume que es el campo de tamaño del encabezado) * El segundo DWORD del paquete debe ser la constante 0x345821AB (el valor "mágico" del encabezado para las solicitudes).

Si se cumplen estas condiciones, el controlador de código de operación proporcionado en el controlador se invoca con un puntero al búfer de resultados (que apunta a una ubicación de pila en el controlador de IRP) y un puntero al búfer de contenido de la solicitud. Una vez que se ejecuta el controlador, el controlador asigna una MDL que apunta a una ubicación en la memoria virtual del proceso de invocación (como se proporciona en el encabezado del paquete) bytes de 0x2FA de longitud, y copia el resultado de su pila en la ubicación de modo de usuario especificada. Vale la pena señalar que el contenido de la ubicación de la pila en cuestión no se ha eliminado en cero en ningún momento, lo que da como resultado la posible pérdida de los punteros del modo kernel.

Por razones de brevedad, esta publicación no explicará con mayor detalle cómo se descubrió la estructura del paquete o el proceso de envío en sí. El controlador define una lista codificada de manejadores y su respectivo código de operación en una estructura, que la función de envío pasa por alto. Para esta vulnerabilidad de LPE, nos centraremos en el controlador de código de operación para 0x311 (785 en decimal), que se encuentra en sub_140001920 para nuestra muestra.

En resumen, este controlador toma el PID y la máscara de acceso provistos en la estructura de solicitud, y devuelve el identificador respectivo (si lo hay) y el NTSTATUS producido por la función.

Profundizando en la función invocada por el controlador de código de operación, vemos lo siguiente:

315

Es probable que la expectativa del desarrollador aquí sea que el identificador producido solo sería válido desde el contexto del núcleo (de hecho, el propósito del KernelMode KPROCESSOR_MODE aquí es un poco engañoso). Esta suposición se basa en el hecho de que hay varios otros manejadores que esperan que se pase un identificador para su uso con ciertas operaciones, como ZwQueryInformationProcess, y que copien su resultado de nuevo en modo de usuario. Sin embargo, debido a las complejidades de Win32, el identificador producido termina perteneciendo al proceso que invoca la solicitud al controlador. Según la documentación de MSDN para ObOpenObjectByPointer
Por favor, Acceder o Registrarse para ver el contenido de las URL!
, la especificación de OBJ_KERNEL_HANDLE en HandleAttributes hubiera sido suficiente para evitar este escenario.

El proceso de explotación después de adquirir un identificador es bastante sencillo. Como podemos adquirir un identificador de cualquier proceso en el sistema en este punto, podemos asignar memoria en el proceso remoto mediante VirtualAllocEx, copiar nuestro código de shell en el segmento recién asignado mediante WriteProcessMemory y, finalmente, invocar CreateRemoteThread para ejecutar nuestro código de shell en su contexto

Un error que hay que tener en cuenta es la introducción del aislamiento de la sesión 0 después del lanzamiento de Vista y versiones posteriores. Esto nos impide lanzar un shell del SISTEMA directamente en nuestra sesión desde casi cualquier proceso del SISTEMA. Afortunadamente, podemos solucionar esto descubriendo el PID de la sesión winlogon.exe que pertenece a nuestro usuario e insertando nuestro código en ese lugar.

Una prueba de concepto que aprovecha los hallazgos anteriores se puede encontrar
Por favor, Acceder o Registrarse para ver el contenido de las URL!
. Esta prueba de concepto se ha probado en Windows 10 versión 1803 x64, pero debería funcionar en todas las versiones x86 y x64 de Windows después de Vista.

La muestra de xhunter1.sys utilizada para la investigación anterior tiene los siguientes hashes:

MD5: 14af49ee75dd1985a5a8e5cfa05c9666
SHA1: 8b7b82b4c4536694065541abdcdc711e1e9ef1cb
SHA256: daba1eba7f93ae90d88baf6bf165956e3cee3d37d51b1fc141631581e83a4d24

Creditos
Psychotropos
 
  • Like
Reactions: Mavera