Español | English
rss facebook linkedin Twitter

MEBROOT Parte I : Apertura

Desde la primera variante del rootkit mebroot( rootkit de MBR ) que se detectó en 2007 hasta ahora, este rootkit ha traído de cabeza a los investigadores debido a su continua evolución. kimmo kasslin y Elia Florio publicaron un artículo en 2008 sobre la evolución y origen de este rootkit: Your Computer is Now Stoned (...Again!).

El mebroot, desde que apareció en escena hasta hoy, lleva jugando una partida de ajedrez con las herramientas anti-rookits. Cada movimiento que da uno es contrarrestado por el otro. En esta serie de artículos veremos parte de esa partida de ajedrez que aún no ha acabado. En este caso la fase inicial que si seguimos con el símil del ajedrez llamaremos Apertura.

Básicamente el rootkit te cambia el MBR de tu máquina por su código. Este código además de arrancar el sistema operativo, instala y ejecuta el rootkit. La forma en que este rootkit se oculta en el sistema es escondiendo el "MBR infectado", de modo que si alguien intenta leer el MBR del sistema, el rootkit devolverá el "MBR original" y parecerá que todo es correcto.

La forma que tienen los anti-rootkits de detectar que un sistema esta infectado con el Mebroot en mediante una lógica diferencial:

-Se lee el MBR en ring 3, es decir, al mas alto nivel posible.
-Se lee el MBR a bajo nivel, en ring 0.

Al leer el MBR al más alto nivel posible, estamos intentando que el contenido de esta lectura contenga lo que el rootkit quiere que veamos. En este caso veremos el MBR original de la máquina que estamos ejecutando.

Por el contrario, al leer al nivel más bajo posible, las herramientas anti-rootkit tienen que baypasear los hooks que este tiene para ocultarse e intentar leer el contenido real del MBR.

Para ver si estamos infectados, lo que hacemos es comparar las dos lecturas anteriores, comprobando antes de que cada lectura contiene un MBR válido( por ejemplo mediante la firma del MBR 0xAA55 ). Si el contenido de estos buffers es diferente podemos asegurar que estamos infectados.

Las primeras variantes del rootkit hookeaban las dispatch routine de disk.sys y cdrom.sys para esconderse en el sistema. Las dispatch routine de disk.sys originalmente son:
[03] IRP_MJ_READ    f9a8bd9b    CLASSPNP!ClassReadWrite
[04] IRP_MJ_WRITE f9a8bd9b CLASSPNP!ClassReadWrite

Cualquier petición de lectura/escritura en disco acabará en CLASSPNP!ClassReadWrite.

Una vez ejecutado el mebroot vemos como cambia la dirección donde se hace la lectura/escritura.
[03] IRP_MJ_READ    8124e1ac    +0x8124e1ac
[04] IRP_MJ_WRITE 8124e1ac +0x8124e1ac

El mebroot lo que trata de ocultar es el MBR que es donde esta su código de infección. Pone un hook a las dispatch de lectura/escritura con la finalidad de poder examinar todas las peticiones de lectura de disco. Cuando se produce una petición de lectura/escritura esta llega a la dispatch routine de disk.sys que al estar modificada salta al código del rootkit y es evaluada por este. Las lecturas del disco que no sean intentos de leer el mbr( 512 bytes del sector 0 ) llamarán a la dirección de memoria original CLASSPNP!ClassReadWrite que el rootkit guarda antes de poner el hook y se resolverá la operación. Si por el contrario le llega una petición de leer el MBR, el malware devolverá el MBR original( guardado previamente en disco ) y así permanecerá oculto en el sistema. Es decir, los buffers de ring3 y ring0 serán iguales.

La solución por la que optaron la mayoría de las herramientas anti-rootkit fue intentar recuperar la dirección de memoria de CLASSPNP!ClassReadWrite para poder llamar a esta dirección de memoria directamente y baypasear el hook del mebroot.

CLASSPNP!ClassReadWrite no está exportada por classpnp.sys por lo que llamarla directamente estaba descartado. Haciendo un estudio del driver classpnp.sys se pudo ver que la función CLASSPNP!ClassReadWrite se llama desde CLASSPNP!Initialize que si esta exportada. Bien ahí estuvo la solución teórica. Vemos CLASSPNP!Initialize:
xor     edi,edi
mov eax,offset CLASSPNP!ClassCreateClose (f9a91c30)
mov dword ptr [ebx+38h],eax
mov dword ptr [ebx+40h],eax
mov eax,offset CLASSPNP!ClassReadWrite (f9a8bd9b)
mov dword ptr [ebx+44h],eax
mov dword ptr [ebx+48h],eax

CLASSPNP!ClassReadWrite (f9a8bd9b) dirección de memoria que
queremos recuperar
.
Para poder optar por esta solución los anti-rootkit debían añadir a su engine un desensamblador lo cual es bastante engorroso y lleva banstante tiempo hacerlo.

Una vez detectado el mebroot, los desarrolladores del malware responden con una nueva versión en que parchean CLASSPNP!ClassReadWrite en CLASSPNP!Initialize:
xor     edi,edi
mov eax,81252756h-->Modificado
mov dword ptr [ebx+38h],eax
mov dword ptr [ebx+40h],eax
mov eax,8124E1ACh
mov dword ptr [ebx+44h],eax
mov dword ptr [ebx+48h],eax
mov eax,81252768h

En esta nueva versión no solo se modifica el CLASSPNP!Initialize sino que también se hookean mas direcciones de memoria en la dispatch routine de disk.sys y cdrom.sys:
[00] IRP_MJ_CREATE                      81252756    +0x81252756
[02] IRP_MJ_CLOSE 81252756 +0x81252756
[03] IRP_MJ_READ 8124e1ac +0x8124e1ac
[04] IRP_MJ_WRITE 8124e1ac +0x8124e1ac
[09] IRP_MJ_FLUSH_BUFFERS 81252768 +0x81252768
[0e] IRP_MJ_DEVICE_CONTROL 81252762 +0x81252762
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 8125275c +0x8125275c
[10] IRP_MJ_SHUTDOWN 81252768 +0x81252768
[16] IRP_MJ_POWER 81252774 +0x81252774
[17] IRP_MJ_SYSTEM_CONTROL 8125277a +0x8125277a
[1b] IRP_MJ_PNP 8125276e +0x8125276e

Bien la guerra por buscar CLASSPNP!ClassReadWrite ha terminado, esta dirección esta parcheada en todo el sistema y las herramientas anti-rookits
tendrán que buscar otras vías para la detección del nuevo sample.

Alonso Candado Sánchez
S21Sec e-crime


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login