xchg2pwn

xchg2pwn


Entusiasta del reversing y desarrollo de exploits



Exploit Development

Fundamentals


Antes de iniciar es necesario aprender algunos conceptos más de explotación en modo kernel, además se llevara a cabo la configuración de un entorno que se utilizará en explotaciones posteriores en el kernel de windows, además como demostración para proximas explotaciones donde se omita la instalación de otros drivers se instalara un driver cargandolo como servicio usando sc.exe en lugar de instalar la aplicación.


Drivers & Rings


Sabemos que un driver es un software que actúa como intermediario entre los dispositivos de hardware, en windows operan en diferentes niveles de privilegio o acceso, estos son conocidos cono rings, en Windows existen 4 niveles de rings:

0 (Kernel Mode): Es el privilegio más alto en el sistema, en este modo se tiene acceso total a los recursos y se puede ejecutar cualquier instrucción.

1 y 2 (intermediate): Los rings 1 y 2 son niveles de privilegio intermedios, aunque en su mayoría solo existen teóricamente pero windows no casi no utiliza estos niveles, requieren mas privilegios que el modo usuario pero menos que el modo kernel

3 (User Mode): Corresponde al nivel más bajo, el código tiene acceso limitado a los recursos del sistema y para interactucar con el kernel requiere utilizar syscalls


Integrity Levels


El control de integridad proporciona un mecanismo para controlar el acceso a objetos protegibles que evalua el acceso antes de evaluar las comprobaciones de acceso en la lista DACL de un objeto, a los procesos se les asignan niveles de integridad que determinan sus niveles de protección, Windows define 4 niveles de integridad:

Low: Asignado a procesos que requieren un aislamiento adicional, por ejemplo navegadores web en modo protegido.

Medium: Es el nivel asignado por defecto a los procesos de usuarios estándar.

High: Usado en procesos que requieren privilegios elevados, como aquellos ejecutados por un administrador en modo elevado.

System: Es el nivél más alto, reservado para procesos críticos del sistema operativo.


Configuration


A diferencia de la explotación en modo usuario, para modo kernel ya que una máquina depura el kernel de la otra necesitaremos 2 máquinas virtuales:

Debugger: Esta máquina será un Windows 10 x64 por defecto que se utilizará para depurar el kernel de la máquina depurada y así desarrollar el exploit.

Debuggee: Esta máquina también será un Windows 10 x64 por defecto que se utilizará para depurar y explotar las vulnerabilidades en el driver.

Luego de instalar ambos windows deberiamos tener 2 máquinas, en este caso estan conectadas mediante un adaptador NAT y sus ips son:

• Debugger: 192.168.100.5

• Debuggee: 192.168.100.10

Iniciemos con esta tendra instalado de primeras WinDbgX que se puede instalar desde la Microsoft Store sin problemas, como herramientas adicionales podriamos incluiir IDA Free para reversear el driver y Visual Studio para desarrollar el exploit, sin embargo lo que mas nos interesa es el debugger

En la máquina que se va a depurar habilitaremos el modo debug y en los ajustes haremos que se conecte al debugger por el puerto 50000 con la key 1.1.1.1

C:\Windows\system32> bcdedit /debug on  
La operación se completó correctamente.

C:\Windows\system32> bcdedit /dbgsettings net hostip:192.168.100.5 port:50000 key:1.1.1.1  
Key=1.1.1.1

C:\Windows\system32>

En la máquina debugger ejecutaremos WinDbg y en la pestaña Attach to kernel, añadimos el puerto y la key que especificamos antes en la máquina a depurar

Finalmente solo necesitamos reiniciar la máquina a depurar y automáticamente se conectara al debugger, podemos ejecutar g para dejar que arranque con normalidad

Connected to target 192.168.100.5 on port 50000 on local IP 192.168.100.5.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 19041 x64 target, ptr64 TRUE
Kernel Debugger connection established.

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*c:\symbols*http://msdl.microsoft.com/download/symbols  
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 10 Kernel Version 19041 MP (1 procs) Free x64
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Kernel base = 0xfffff804`32c00000 PsLoadedModuleList = 0xfffff804`3382a3e0
nt!DbgBreakPointWithStatus:
fffff804`330082b0 cc              int     3

kd> g

Para finalizar solo nos queda instalar el driver, para ello usaremos sc que creará un servicio que cargará el driver .sys, indicamos que el tipo es kernel y que queremos que inicie con el sistema, luego de crearlo iniciamos el servicio asi cargándolo

C:\driver> sc create Custom binPath=C:\driver\custom.sys type=kernel start=system  
[SC] CreateService CORRECTO

C:\driver> sc start Custom

NOMBRE_SERVICIO: Custom
        TIPO               : 1  KERNEL_DRIVER
        ESTADO             : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        CÓD_SALIDA_WIN32   : 0  (0x0)
        CÓD_SALIDA_SERVICIO: 0  (0x0)
        PUNTO_COMPROB.     : 0x0
        INDICACIÓN_INICIO  : 0x0
        PID                : 0
        MARCAS         :

C:\driver>

Con esta configuración tendriamos listo el entorno con ambas máquinas para explotar el driver, pero eso será en el siguiente post donde lo analizaremos poco a poco