Posts Tagged ‘windows’

Plugin de Ayuda en Línea MSDN para OllyDbg / Immunity Debugger

Hola a todos. En esta ocasión voy a presentar un plugin para el depurador OllyDbg / Immunity Debugger que va a facilitar la tarea de realizar la ingeniería inversa de un binario de Windows.

¿Qué es OllyDbg?

OllyDbg es un clásico depurador de binarios a bajo nivel para el sistema operativo Windows. Según muchos, es la herramienta ideal para hacer ingeniería inversa de programas de los que no disponemos del código fuente (por ejemplo, malware), y también es muy utilizado en el mundo del cracking.

Una de las características más atractivas que tiene es la posibilidad de cargar plugins. La mayoría están orientados a ayudar en el desempacado de binarios protegidos y evitar la detección del depurador por parte del código malicioso que estemos analizando, aunque los hay para muchas otras tareas.

¿Qué es Immunity Debugger?

Luego de varios años sin actualizaciones, y tras múltiples exploits publicados que no han sido corregidos por el autor, la empresa Immunity decidió comprar el código fuente para actualizarlo y mejorarlo. Así nació Immunity Debugger, que parece estar destinado a reemplazar al viejo Olly, especialmente en el terreno del exploiting que es donde se están concentrando más las nuevas características y los nuevos plugins.

¿La pega? Que los viejos plugins de OllyDbg en general ya no funcionan más. Si se dispone del código fuente se pueden actualizar e incluso hacer que funcionen en ambos. Si no, la cosa está más complicada, aunque hay una herramienta que ayuda bastante.

El plugin que presento hoy funciona correctamente en ambos programas. :)

¿Para qué sirve este plugin?

OllyDbg ya tiene sus años, y aunque se sigue usando no siempre ha envejecido con gracia. ;) Uno de sus puntos flacos es el soporte de ayuda de Windows.

Me explico. Al analizar un binario en Windows normalmente veremos código ensamblador y llamadas a funciones de la Win32 API, que es la interfase de programación de bajo nivel en Windows. Las funciones de la API son muchas y es imposible memorizarlas todas, por lo que es imprescindible poder consultar la documentación de Microsoft para saber qué hace cada una, qué parámetros llevan, etc.

Ahora bien. OllyDbg ya permitía desde sus comienzos consultar la documentación de Microsoft gracias a un archivo llamado “WIN32.HLP“, que venía con la SDK de Windows NT, y contenía la documentación más completa y detallada… de aquel entonces. Pero ya pasaron varias versiones de Windows y unos cuantos años, Microsoft dejó de dar soporte a ese manual para dar paso a la documentación online de la MSDN (Microsoft Developer Network), y lo que ocurre ahora es que al consultar la ayuda desde el Olly muchas de las cosas que buscamos no aparecen. :(

Este plugin viene a llenar ese vacío. Al instalarlo, cuando OllyDbg intente acceder a WIN32.HLP para mostrar la documentación, el plugin lo intercepta y lanza el navegador web en la página correspondiente de la documentación online. :)

¿Cómo se instala este plugin?

Es simple, hay que descargar el archivo zip, extraer el plugin (OllyMSDN.dll) y copiarlo a la carpeta de instalación del depurador.

En OllyDbg esta carpeta suele ser “C:Program FilesOllyDbg” (en castellano C:Archivos de ProgramaOllyDbg”).

En Immunity Debugger la carpeta suele ser “C:Program FilesImmunity IncImmunity Debugger” (en castellano nuevamente reemplazar “Program Files” por “Archivos de Programa”).

El siguiente paso es cargar el depurador, y desde el menú “Help” ir a la opción “Select API help file”. Allí hay que, o bien seleccionar el viejo WIN32.HLP (aunque no se vaya a usar), o al menos un archivo cualquiera que se llame exactamente igual (el contenido da lo mismo). El nombre es importante, porque es la manera en que el plugin se da cuenta de que el usuario está intentando consultar la documentación de Microsoft y no, digamos, la ayuda del propio OllyDbg.

Una vez hecho esto, ya está completa la instalación.

¿Cómo se usa este plugin?

Se usa exactamente igual que el viejo archivo WIN32.HLP. Es decir:

Para acceder a la documentación, vamos al menú “Help” y seleccionamos la opción “Open API help file”.

Para ver la ayuda de una llamada API en concreto, hacemos click derecho sobre la línea de código ensamblador y seleccionamos la opción “Help on symbolic name”.

¿Dónde consigo este plugin?

Se puede comprar por el módico precio de… nah, mentira, es completamente gratuito! :)

Se descarga siguiendo este link: OllyMSDN.zip

El archivo zip contiene el binario precompilado para Windows y el código fuente, liberado bajo la licencia GPL v2. El fuente compila bajo Visual Studio 2008, no lo he probado con otros compiladores.

Bueno, eso es todo por hoy. Que les aproveche! :)


Sígueme en Twitter: @Mario_Vilas | Linkedin: http://es.linkedin.com/in/mariovilas

Share via email
Share on Facebook+1Share on Twitter

Hard and Soft Links in Windows 7

Hoy hablaremos de enlaces simbólicos y de enlaces duros. Pero nos centraremos en Windows 7. Efectivamente, aunque su uso no está muy extendido el sistema de Redmond tiene esta capacidad. Para ilustarla, mostraremos cómo crear estos enlaces y después, mediante procedimientos forenses, veremos en qué consiste cada uno de ellos.

Enlaces duros (Hard Links)

Un enlace duro o hard link es una copia total del fichero, entendiendo por total la copia de los metadatos asociados. En el caso de Windows 7 nos estamos refiriendo a la MFT (Master File Table) del fichero.

Imaginemos que tenemos un fichero llamado “fichero.txt” y queremos hacer un hard link, lo ejecutaríamos con el siguiente comando:

Como resultado tenemos un enlace duro en el fichero “hard_link.txt

Enlaces simbólicos (Soft Links)

El enlace simbólico es un enlace al fichero original, no una copia del mismo. Imaginemos que tenemos un fichero llamado “fichero.txt” y queremos hacer un soft link, lo ejecutaríamos con el siguiente comando:

Como podemos apreciar en la imágen, no se ha creado por falta de permisos.Esto es debido a que ciertas aplicaciones no se comportan de manera segura en presencia de enlaces simbólicos, por lo que la creación de estos enlaces requiere el privilegio “SeCreateSymbolicLink”.

Lo ejecutamos desde una consola con privilegios de administración:

Como resultado tenemos un enlace duro en el fichero “hard_link.txt“. Si abrimos la carpeta que contiene los ficheros podemos apreciar algunas diferencias a simple vista:

Pero vamos a ver las implicaciones de manea forense. Es por ello que tomamos evidencia de toda la carpeta (miento, en realidad de una unidad NTFS que contiene dicha carpeta). Para ello utilizé la herramienta FTK Imager y el contenedor forense AFF (Advanced Forensic Format). Mi evidencia forense es el fichero “links_w7.aff“, que tiene la siguiente información:

Created By AccessData® FTK® Imager 3.0.1.1467 110406

Case Information:
Acquired using: ADI3.0.1.1467
Case Number: Ejemplo hard and soft links
Evidence Number: 001
Unique description: links_w7
Examiner: dmedianero
Notes: Ejemplo hard and soft links

————————————————————–

Information for C:tmplinks_w7:

Physical Evidentiary Item (Source) Information:
[Drive Geometry]
Bytes per Sector: 512
Sector Count: 18.432
Source data size: 9 MB
Sector count:    18432
[Computed Hashes]
MD5 checksum:    03d6fb63927ce8df2697a2ece063b13d
SHA1 checksum:   d4717b8960afd3bb7bb07556cf2877a73855c180

Image Information:
Acquisition started:   Thu Jan 05 16:40:53 2012
Acquisition finished:  Thu Jan 05 16:40:56 2012
Segment list:
C:tmplinks_w7.aff

Para analizar la evidencia utilizaremos la conocida suite Sleuthkit. Antes que nada, vamos a fijarnos en la MFT del fichero original, el fichero “fichero.txt”:

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 260  ()
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:27 2012
Accessed:       Thu Jan  5 16:37:16 2012

$FILE_NAME Attribute Values:
Flags: Archive
Name: hard_link.txt, fichero.txt
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:16 2012
Accessed:       Thu Jan  5 16:37:16 2012

Notese que la salida está limitada a los atributos $Standard_Information y $File_Name por claridad. Contrastemos dichos datos con la MFT de nuestro enlace duro o hard link:

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 260  ()
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:27 2012
Accessed:       Thu Jan  5 16:37:16 2012

$FILE_NAME Attribute Values:
Flags: Archive
Name: hard_link.txt, fichero.txt
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:16 2012
Accessed:       Thu Jan  5 16:37:16 2012

Como podemos apreciar es exactamente la misma MFT. A continuación mostramos la MFT del enlace simbólico “soft_link.txt”:

$STANDARD_INFORMATION Attribute Values:
Flags: Archive, Reparse Point
Owner ID: 0
Security ID: 264  ()
Created:        Thu Jan  5 16:38:09 2012
File Modified:  Thu Jan  5 16:38:09 2012
MFT Modified:   Thu Jan  5 16:38:09 2012
Accessed:       Thu Jan  5 16:38:09 2012

$FILE_NAME Attribute Values:
Flags: Archive
Name: soft_link.txt
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:        Thu Jan  5 16:38:09 2012
File Modified:  Thu Jan  5 16:38:09 2012
MFT Modified:   Thu Jan  5 16:38:09 2012
Accessed:       Thu Jan  5 16:38:09 2012

Como podíamos esperar todos los timestamps son posteriores. Un análisis pormenorizado nos llevaría a descubrir que en el soft link el atributo $Data ocupa 0 bytes, esto se debe, logicamente, a que es un enlace, no tiene contenido propio. La manera de “enlazar” se hace a través del atributo $Reparse_point, cuyo contenido muestro a continuación:

00000000:  0C00 00A0 3800 0000 1600 1600 0000 1600    ....8...........
00000010:  0100 0000 6600 6900 6300 6800 6500 7200    ....f.i.c.h.e.r.
00000020:  6F00 2E00 7400 7800 7400 6600 6900 6300    o...t.x.t.f.i.c.
00000030:  6800 6500 7200 6F00 2E00 7400 7800 7400    h.e.r.o...t.x.t.

Asique ya sabéis, los enlaces duros y simbólicos existen en Windows y aunque apenas sean utilizados, no por ello dejan de ser interesantes.

 

Share via email
Share on Facebook+1Share on Twitter

Malware Stepper

Existen muchas estrategias de análisis de malware, en este post voy a reflejar una técnica de análisis dinámico que facilita bastante las cosas, voy a llamarla stepping aunque en realidad se basa más en traces que en steps.

El stepping consiste en ejecutar todo el código del malware paso a paso, hasta identificar las llamadas “peligrosas” a la API de Windows, en principio no puede realizar ninguna actividad malévola sin llamar ninguna api, otra cosa es que llame api´s no documentadas, o utilice técnicas de subir a ring0 mediante desbordamientos de buffer, interrupciones o como sea.

El stepping tiene dos problemas:

1. La velocidad, steppear un binario es muy muy lento, para que os hagáis una idea, hacer un stepping de un malware de pocos Kbytes puede tardar varios días.

2. El segundo problema es que realice hooks, infecciones, salto a ring0 .. de manera que los datos interesantes se descifrarán desde otro proceso.

El segundo punto es una limitación de esta técnica, aunque se puede parar el stepping ante un intento de infección, hookeo etc … y continuar manualmente con análisis estático u otros steppings de otros procesos. Esto es solo una técnica y no una herramienta valida para analizar todos los malwares.

En cuanto al lenguaje a utilizar, me interesa combinar el stepping automático con análisis manual, de manera que debería desarrollarse en un lenguage de scripting para ollydebug, immunity, radare etc.

Lo más rápido que he encontrado es ollyscript, más que el ollypython y immunity python, lógicamente porque es más ligero, de hecho, curiosamente el tracing desde ollyscript, va más rápido que manualmente desde ollydebug, cuando el motor es el mismo incluso el ollyscript tiene alguna capa más.

Para acelerar el stepping realicé una comparación de eip con la dirección a partir de la cual se enlazan las librerías, fuera de librerías procedía con step into y en librerías con step over.
En el caso de encontrar un bucle, realicé una rutina llamada saltaBucles que lo detecta, breakpointea las salidas y ejecuta para pasar el bucle de la forma más rápida.

Salir de los bucles y hacer step over en las librerías aceleraba bastante el stepping, no obstante lo que voy a publicar aquí es una versión basada en trace, trace into en el módulo del malware y trace over en los demás módulos, que también es relativamente rápido, ollyscript realiza los trace y los animate de forma bastante eficiente, sobretodo los trace.

El siguiente punto a tener en cuenta, es hasta que punto dejar fluir la ejecución, que apis consideramos peligrosas.
En mi caso tenía un objetivo concreto que es obtener las urls, que algunos casos van cifradas y en otros no.

Tal como he comentado, existen otras técnicas de intercepción de api como el ring3 hooking, el ring0 SSDT patching etc …
Las api que decidí interceptar mediante stepping son las siguientes, describo muy brevemente la razón:

Para detectar api-loaders, infecciones, cambios de permisos en páginas para desempacar o descifrar código:

kernel32.OpenProcess
kernel32.CreateProcess
kernel32.CreateFileA
kernel32.CreateFileW
kernel32.CreateDirectoryA
kernel32.CreateRemoteThread
kernel32.CreateRemoteThreadEx
kernel32.DeleteFileA
kernel32.DeleteFileW
kernel32.IsDebuggerPresent
kernel32.VirtualProtect

Crear claves de registro:

ADVAPI32.RegCreateKeyExA
ADVAPI32.RegCreateKeyExW
ADVAPI32.RegSetValueEx

Conexiones y aperturas de puertos, posible control remoto, o envio de credenciales:

WS2_32.connect
WS2_32.bind
WS2_32.ntohs
WS2_32.inet_addr
WS2_32.send
WS2_32.sendto

Acceso a webs ftps, posibles envíos de credenciales:

wininet.InternetWriteFile
wininet.InternetReadFile
wininet.InternetReadFileEx
wininet.InternetOpen
wininet.InternetOpenUrl
wininet.InternetFindNextFile
wininet.InternetCrackUrl
wininet.InternetCreateUrl
wininet.InternetConnect
wininet.HttpOpenRequest
wininet.HttpQueryInfo
wininet.HttpSendRequest
wininet.HttpSendRequestEx
wininet.GopherOpenFile
wininet.FtpCommand
wininet.FtpCreateDirectory
wininet.FtpDeleteFile
wininet.FtpFindFirstFile
wininet.FtpGetCurrentDirectory
wininet.FtpGetFile
wininet.FtpOpenFile
wininet.FtpPutFile
wininet.FtpRemoveDirectory
wininet.FtpRenameFile
Winhttp.WinHttpConnect
winhttp.WinHttpCrackUrl
winhttp.WinHttpCreateUrl

Ejecución de comandos o para malwares multi multistaged:

SHELL32.ShellExecuteA
SHELL32.ShellExecuteW
SHELL32.ShellExecute

Posible convert-channel mediante las netapi:

netapi32.NetServerEnum
netapi32.WNetEnumResource
netapi32.NetShareEnum

Se podrían incluir más api interesantes como por ejemplo la cryptoapi, pero tampoco quería cargar mucho el bucle.

En cuanto al motor de traceo condicional, se basa en lo siguiente:


engine:
ticnd "eip >= 10000000"
cmp eip, 0
je theend

// Ha entrado en una api, si es una api sospechosa, se loguea y finaliza la ejecución, si no se loguea y continua el traceo

tocnd "eip < 10000000"
jmp engine

En la ventana de log de ollydebug, se puede ver las api que van siendo llamadas, softwares tipo strace/ltrace para windows hay varios, sin embargo este script puedes pararlo cuando quieras de forma manual o programada.

El stepper detecta una llamada interesante y para su ejecución para que el analista pueda continuar de forma manual.

En este caso el fichero se abre a si mismo, posiblemente en alguna parte del fichero no mapeada por el linker, se encuentran datos cifrados. Abrirse a si mismo es una operación típica en virus tipo overlay, por ejemplo un infector de ficheros elf que hice en el 2006: infR3.s

Podéis descargar el OllyScript aquí: Stepper – OllyScript for Malware Análisis

Conclusiones:

* No es la forma más rápida ni automática de analizar, es un script de ayuda al análisis manual del malware para situaciones puntuales, que ha de ser combinado con análisis manual.
* Un buen complemento es scripts de búsqueda de patrones estáticos, que espero publicar en otro post.
* Esto ejecuta el malware!!, buguroo no se hace responsable del uso inapropiado de este script, recomendamos utilizar máquina independiente o virtual.

Share via email
Share on Facebook+1Share on Twitter