PDFiD, analizando archivos PDF

Es importante tener un buen arsenal de herramientas si queremos hacer un análisis completo y funcional en un caso. Hoy en día que el malware se hace eco en casi cualquier tipo de archivo es importante poder analizar cada uno de ellos. Hoy le toca el paso a los PDF’s. Ya he publicado alguna cosa aquí sobre análisis de PDF, de echo uno de mis colegas es el desarrollador de PeePDF, GRAN herramienta para el análisis de PDF’s maliciosos.
El único inconveniente de PeePDF es la cantidad de dependencias que tiene, así que si no te quieres liar es mejor que los uses desde distribuciones como Remnux. La ventaja de usar la herramienta que veremos hoy es que no necesitarás ninguna dependencia, eso si, no tiene la potencia de análisis de PeePDF, está claro.
La herramienta la descargamos desde la web de Didier Stevens
http://didierstevens.com/files/software/pdfid_v0_1_0.zip
Primero vamos a ver que opciones tiene la herramienta:

darkmac:Downloads marc$ python pdfid.py -h
Usage: pdfid.py [options] [pdf-file|zip-file|url]
Tool to test a PDF file
Options:
–version show program’s version number and exit
-h, –help show this help message and exit
-s, –scan scan the given directory
-a, –all display all the names
-e, –extra display extra data, like dates
-f, –force force the scan of the file, even without proper %PDF header
-d, –disarm disable JavaScript and auto launch

Para tener una vista clara de lo que hay, nos servirá.
Vamos ha hacer un análisis de un documento PDF, para ver que podemos extraer:

darkmac:Downloads marc$ python pdfid.py /Users/marc/Downloads/RESULTS/analysis/52/APT_1104statment.pdf
PDFiD 0.1.0 /Users/marc/Downloads/RESULTS/analysis/52/APT_1104statment.pdf
PDF Header: %PDF-1.7
obj 59
endobj 59
stream 40
endstream 40
xref 1
trailer 1
startxref 5
/Page 3
/Encrypt 0
/ObjStm 9
/JS 0
/JavaScript 0
/AA 0
/OpenAction 0
/AcroForm 1
/JBIG2Decode 0
/RichMedia 0
/Launch 0
/EmbeddedFile 9
/Colors > 2^24 0

Si comprobamos la salida de PDFiD podemos ver que en concreto este archivo tiene varios objetos emmbedded… Cosa sospechosa a priori…
PDFiD también nos permite extraer la fecha de modificación y creación del documento

darkmac:Downloads marc$ python pdfid.py -e /Users/marc/Downloads/RESULTS/analysis/52/APT_1104statment.pdf
PDFiD 0.1.0 /Users/marc/Downloads/RESULTS/analysis/52/APT_1104statment.pdf
PDF Header: %PDF-1.7
obj 59
endobj 59
stream 40
endstream 40
xref 1
trailer 1
startxref 5
/Page 3
/Encrypt 0
/ObjStm 9
/JS 0
/JavaScript 0
/AA 0
/OpenAction 0
/AcroForm 1
/JBIG2Decode 0
/RichMedia 0
/Launch 0
/EmbeddedFile 9
/Colors > 2^24 0
%%EOF 5
After last %%EOF 0
D:20110413150033+08’00 /CreationDate
D:20110704103118+08’00 /LastModified
D:20110920103827+08’00 /ModDate
D:20110920103842+08’00 /CreationDate
D:20110920103851+08’00 /LastModified
Total entropy: 7.350737 ( 91010 bytes)
Entropy inside streams: 7.694377 ( 52732 bytes)
Entropy outside streams: 6.372867 ( 38278 bytes)

Mas información que podemos extraer de los documentos PDF.
Sin duda una herramienta a incorporar en nuestro arsenal.

Hexinject

El estudio del tráfico de red es necesario en varias disciplinas, por ejemplo en un análisis dinámico de malware. Es por eso que existen herramientas como HexInject.
Esta herramienta aunque a priori pueda parecer que es difícil de usar tiene un par de flags que me han parecido interesantes.
Búsqueda de strings en la captura
Uno de los flags que podremos usar a la hora de capturar el tráfico es el uso de strings,

Hexinject

Podemos buscar directamente por los hosts que aparecen en la muestra:

Hosts

Además de buscar haciendo captura del tráfico seremos capaces de inyectar paquetes en la red. Está claro que al verificar estos paquetes se trata de paquetes incorrectos.

Paquete malformado

La herramienta está incluída en la suite de Backtrack y la podéis encontrar en Sourceforge
http://hexinject.sourceforge.net/

Distribuir el malware con un exploit kit

Cuando se prepara una campaña de infección de malware el criminal se puede encontrar en varios momentos.

• Posee una infraestructura para cometer fraude
• Posee un Exploit Kit que ha comprado
• Tiene la muestra con la configuración.

Se pueden dar los tres casos a la vez lo que facilita que alguien con malas intenciones pueda perpetuar fraude.
Pero en algunos casos es posible que un criminal se encuentre que solo ha pagado por la muestra que usará para infectar a los usuarios y necesite de alguna manera distribuir malware. En esos casos y si no quiere pagar por un Blackhole puede tratar de hacerse un kit a medida o buscar algunos de los que puede encontrar por la red.
Por ejemplo existen algunos foros que se encargan de distribuir Exploits kits, no habrá ninguno actualizado, pero puedes encontrarte con muchas sorpresas si buscas bien.
http://bit.ly/14qvyjZ
En esas entradas podremos encontrar exploits para descargar, esto sirve tanto si queremos distribuirla muestra o simplemente queremos saber como funciona.

Exploit para descargar

Aunque tampoco hemos de fiarnos de lo que nos descargamos ya que hemos de pensar que es posible que la muestra de malware contenga otro malware y quedemos infectados.

Envío gratuíto de SPAM

Cuando se realiza un análisis sobre una investigación utilizamos herramientas que desarrolladores cuelgan en los github y los sourceforge correspondientes. Estas herramientas facilitan el día a día de los técnicos. Pero que pasaría si estas herramientas las usaran los cibercriminales?
Por poner un ejemplo, TheHarvester, esta herramienta se usa para la parte de information gathering. ¿Que podemos hacer con esta herramienta?
darkmac:theharvester-read-only marc$ python theHarvester.py
*******************************************************************
* *
* | |_| |__ ___ /\ /\__ _ _ ____ _____ ___| |_ ___ _ __ *
* | __| ‘_ \ / _ \ / /_/ / _` | ‘__\ \ / / _ \/ __| __/ _ \ ‘__| *
* | |_| | | | __/ / __ / (_| | | \ V / __/\__ \ || __/ | *
* \__|_| |_|\___| \/ /_/ \__,_|_| \_/ \___||___/\__\___|_| *
* *
* TheHarvester Ver. 2.2a *
* Coded by Christian Martorella *
* Edge-Security Research *
* cmartorella@edge-security.com *
*******************************************************************
Usage: theharvester options
-d: Domain to search or company name
-b: Data source (google,bing,bingapi,pgp,linkedin,google-profiles,people123,jigsaw,all)
-s: Start in result number X (default 0)
-v: Verify host name via dns resolution and search for virtual hosts
-f: Save the results into an HTML and XML file
-n: Perform a DNS reverse query on all ranges discovered
-c: Perform a DNS brute force for the domain name
-t: Perform a DNS TLD expansion discovery
-e: Use this DNS server
-l: Limit the number of results to work with(bing goes from 50 to 50 results,
-h: use SHODAN database to query discovered hosts
google 100 to 100, and pgp doesn’t use this option)
Examples:./theharvester.py -d microsoft.com -l 500 -b google
./theharvester.py -d microsoft.com -b pgp
./theharvester.py -d microsoft -l 200 -b linkedin
La herramienta posee varios métodos de búsqueda.
Vamos a ponernos en la piel de un spammer, en la que quiere conseguir direcciones de correo de una compañía a la que quiere mandar spam.
Sería tan sencillo con hacer un bucle y usar harvester para conseguir las direcciones de correo.
Esto que comento será tan fácil como hacer un archivo TXT con tantos dominios como los que queramos escanear.

for i in `cat dominios.txt`; do python theHarvester.py .d $i -b google ; done

Una tarea que pueden automatizar en sus campañas de SPAM.

URLQuery, servicio web para el análisis de malware

A día de hoy es complicado saber si no quedaremos infectados al navegar por Internet. Para infectarnos no hace falta que vayamos ha navegar en aquella página que nos puede venir en un correo de SPAM, si no que ahora una de las prácticas habituales de los ciber-criminales es infectar páginas legítimas.
Y esto, ¿porque ocurre?
Bueno es mas fácil poder llegar a infectar a usuarios que vistan webs legítimas que no intentar obligar al usuario a visitar un link que le llegará por correo ¿No?
Para tratar de analizar estas páginas webs existen páginas que nos facilitarán en poco tiempo un reporte de si hay algo peligroso en dicha página web. Uno de esos servicios es URLQuery.
Si vamos hacia la página web encontraremos los análisis que ha ido realizando la gente:

Nos da bastante información como la fecha, si en el IDS saltó una alerta o no, además de la IP e URL/IP.
Vamos a ver primero un ejemplo de una página de dominio .cat de aquí de Cataluña! Veremos un ejemplo de un report de un escaneo.

Podremos ver un resumen del escaneo, en el resumen vemos

• URL
• ASN
• Localización
• Fecha del report
• Status
• Alertas

Además podremos ver un pantallazo de la página web.
En Settings veremos con que parámetros se ha configurado el escaneo. En este caso podemos ver que versiones específicas han saltado.
También podemos ver la parte de alertas que ha saltado en los motores.
Que mas cosas podemos ver en el reporte de URLQuery

Si URLQuery ha encontrado mas alertas en el mismo DOMINIO/IP/ASN nos lo mostrará, para poder ver relación entre infecciones por ejemplo.
Otra de las cosas interesantes es poder ver los Javascripts que se ejecutan en la página para ver si hay alguno malicioso, por ejemplo.
También podremos ver las transacciones HTTP que hay en la web.

En la última parte del report podemos ver los REQUEST que hace la página y los response recibidos.
Vamos a ver en un ejemplo de infección en la web, que indicadores deberíamos de tener en cuenta.

Una de las alertas en las que nos tenemos que fijar en URLQuery es en los Javascript que carga la página, aquí podremos ver funciones EVAL, por ejemplo.
Esta es una de las cosas que podremos tener en cuenta.
Otra de las cosas que podremos ver es las peticiones que se realizan desde la página al cargarla:

URLQuery además nos marcará la petición en amarillo para que la revisemos.
URLQuery es gratis y permite analizar las URL’s que necesites, por otro lado además tienen el apartado de estadísticas en el que podrás consultar que Exploits Packs son los que mas han analizado. También cuando realices un análisis puedes cambiar la versión de Java y Adobe además del navegador.

Problemas en la detección de packers

Es común encontrarse malware que llevan como medida de  protección un packer, esto dificulta tanto la parte de detección por parte de las casas de antivirus como por parte del analista cuando realiza la ingeniería inversa.

Un Packer es  un programa que toma como entrada un fichero ejecutable y devuelve otro fichero ejecutable con la misma funcionalidad pero con ciertas protecciones añadidas que dificultan su análisis.

En el análisis del binario nos podemos encontrar con ciertas dificultades, una de ellas es que al contener el packer existirán diversas partes del binario que estarán cifradas, esto dificulta el análisis del código de manera que tendremos que extraer el packer para poder ver el contenido del binario. Existen multitud de packers, de los mas famosos podemos encontrar UPX, FSG, Themida etc…

El primer paso para poder ver el contenido del binario es averiguar con que Packer ha sido empaquetado. Es en este paso es donde intervienen ciertos programas que se encargan de analizar la cabecera del binario para tratar de analizar con que Packer esta protegido dicho binario.

Este tipo de programas no son 100% fiables y son capaces de darnos falsos positivos y de esto trata la entrada de hoy. 

PEID

PEID es uno de esos programas capaces de dar información de como está empaquetado, estos software se basan en firmas que pueden buscar en bases de datos que se van actualizando, esas firmas se encuentran a lo largo del binario con el binario en si o bien mirando solo el Entry Point.

Ahora haremos la prueba con un binario

PEID nos indica que el binario está empaquetado con UPolyX. ¿Será esto cierto?

El software se puede configurar para que haga los análisis mas profundo del binario 

 Configuramos PEID de esta forma y volvemos a analizar el binario.

El packer detectado es otro, no el encontrado anteriormente, PEID se basa en firmas para la detección del tipo de packer.

RDG Packer Detector

RDG igual que PEID nos ayuda a identificar el packer con el que se haya empaquetado el binario.

También se basa en firmas igual que PEID, pero en este caso también nos da un resultado distinto.

 

RDG detecta el packer por heurística y nos da un resultado distinto a PEID.

¿Fallo en las comprobaciones automáticas?

Una pregunta que nos podemos hacer es porque PEID y RDG han detectado packers distintos, y en el caso de PEID si se configuraba para que la comprobación se hiciera de manera más profunda detectaba un packer distinto, esto es debido a que este tipo de programas se basan en firmas, si miramos el fichero de firmas

Como las firmas se van actualizando, hay firmas que solo están completadas la mitad de la firma, si buscamos en algunos casos de los packers detectados, como Upolyx, Aspack y Extreme Protector, nos encontramos.

 

Este es el caso de Upolyx, detecta la firma porque parte delos Bytes del packer se encuentran en el binario 

Parte de la firma del packer de Aspack también se encuentra en el binario.

 Y por último el packer detectado por RDG que encontraba Xtreme Protector, también es encontrado en el binario.

Además algunos de los packers permiten poner una firma falsa, de manera que dificulta la detección en base a éstas.

Detección del packer manualmente

Otra de las opciones que disponemos es de analizar el binario manualmente con un debugger, no es tan rápido como usar PEID o RDG pero nos aseguramos de tener mas fiabilidad a la hora de detectar el packer.

Para el análisis usaremos OllyDBG, abrimos OllyDBG y empezamos. 

Cargamos el binario a analizar, nos dirigimos al image base + 1000h bytes (es donde se mapea/empieza el código, para este caso), el packer sustituye al programa colocándose él en esta dirección, es por eso que veremos el contenido cifrado.

En la ejecución del programa en primer lugar se ejecuta el código del packer, que se encargará de descifrar y descomprimir el código previamente protegido.

Colocamos un breakpoint y vamos ejecutando el programa en Olly para ver si podemos ver que packer es.

En la ejecución del sample el Olly podemos ver el string “oreans” ; oreans es la empresa que distribuye software comercial como Themida, es posible que se trate de este software así que seguimos buscando entre los distintos productos que distribuye la compañía, hasta encontrar el software. 

Se trata de WinLicense, uno de los productos que distribuye la empresa Oreans para la protección de binarios, que en este caso ha sido utilizado para proteger malware de la detección de antivirus y de un posible análisis del mismo.

El uso de los packers es muy frecuente cuando se trata de malware, muchos aprovechan packers como por ejemplo UPX, los modifican y los usan para volver sus samples modificados indetectables.

Las mafias profesionales ya usan packers privados que son indetectables por los motores antivirus, además en el mundo Underground ya existen servicios que por unos pocos dólares pueden empaquetar un binario con un packer/cripter privado de manera que será difícil detectarlo por los motores antivirus. 

Windows DLL Hijacking

Durante los últimos días, la avalancha de nuevos advisories que se refieren a esta vulnerabilidad está causando bastante revuelo. Ya hay contabilizadas más de 100 aplicaciones vulnerables y la lista parece que continúa creciendo. ¿Realmente es para tanto? Veamos:

La nota detonante ha sido este documento en el cual se reporta una vulnerabilidad que afecta a la aplicación iTunes. Básicamente el problema consiste en la posibilidad de ejecutar código de forma remota, "invitando" a un usuario a abrir con iTunes un archivo inofensivo, ya sea desde una unidad local, una carpeta compartida o una unidad usb. Este archivo se acompaña de una librería específica requerida por la aplicación vulnerable. Cuando la aplicación procede a la apertura del archivo realiza la carga en memoria de esta librería en lugar de la original. ¿Cómo es esto posible?

La explicación técnica es bastante sencilla. Cuando una aplicación de Windows carga de forma dinámica una librería sin especificar la ruta completa, Windows busca esta librería siguiendo un orden específico. Las funciones encargadas de realizar la carga de la librería son LoadLibrary y LoadLibraryEx. Este es el orden de búsqueda del archivo DLL de estas dos funciones:

1. El directorio desde el que se cargó la aplicación
2. El directorio del sistema
3. El directorio del sistema de 16 bits
4. El directorio de Windows
5. El directorio de trabajo actual
6. Los directorios enumerados en la variable de entorno PATH

Si consultamos la documentación oficial de Microsoft vemos que se recomienda no utilizar la función SearchPath para obtener la ruta completa al archivo DLL al utilizarla posteriormente para llamar a LoadLibrary. Esta recomendación se basa en el hecho de que la función SearchPath usa un orden de búsqueda diferente de los archivos, comenzando por el directorio de trabajo. La forma más sencilla de evitar este problema es llamar previamente a la función SetDllDirectory pasándole como parámetro una ruta en blanco, eliminando así el directorio actual del orden de búsqueda por defecto de los archivos DLL.


Verificando la vulnerabilidad.

Unas pruebas rápidas en un entorno controlado son suficientes para comprobar cómo es bastante fácil encontrar aplicaciones vulnerables y cómo explotar esta vulnerabilidad.
Nuestro conejillo de indias será el archivo GRPCONV.EXE incluido en Windows XP, esta aplicación es el conversor de grupos para el Administrador de programas de Windows.

La siguiente es una captura de pantalla de Windbg (debugger) en la cual se aprecia la carga de la librería imm.dll desde el directorio de trabajo en el cual se abre un archivo grp.



La librería imm.dll original que carga la aplicación, se ha sustituido por otra que en realidad es un exploit a medida, el cual proporciona una shell a otro equipo de pruebas con dirección IP 172.17.1.89.



¿Cual ha sido la respuesta de Microsoft?

La siguiente actualización de seguridad proporciona una nueva entrada del registro de Windows CWDIllegalInDllSearch, que permite a los administradores controlar la ruta de búsqueda de las dlls cargadas por las aplicaciones. Mediante esta nueva entrada es posible definir lo siguiente, ya sea para cada aplicación o para todo el sistema:

- Quitar el directorio de trabajo actual de la ruta de búsqueda de la biblioteca.
- Impedir que una aplicación cargue una biblioteca desde una ubicación de WebDAV.
- Impedir que una aplicación cargue una biblioteca desde un WebDAV o desde una ubicación UNC remota.

Es curioso cómo una vulnerabilidad que fue descubierta por Georgi Guninski en el año 2000, y que en su momento (2001) fue activamente explotada por el gusano Nimbda, vuelve a ponerse de actualidad. Pues sí, me temo que no se trata de algo nuevo. Esta era precisamente una de las técnicas que utilizaba Nimbda para propagarse mediante la copia de la supuesta librería riched20.dll en directorios con archivos .doc.