31 octubre 2012

Detección de entornos virtualizados con pafish

Desde hace bastante tiempo venimos escuchando y leyendo nuevos avances en cuanto a Malware se refiere. Uno de estos grandes avances, es a su vez una pesadilla para cualquier analista. Y es ver cómo un Malware que se intenta analizar en un entorno virtualizado, no realiza ningún tipo de acción.

A día de hoy ya es una realidad que muchas variantes de Malware realicen comprobaciones para conocer en dónde se están ejecutando y en función del entorno o arquitectura, realizar un tipo de acción o no.

Personalmente, mis conocimientos de detección de entornos virtualizados bajo la platorma Windows se circunscriben a comprobar por ejemplo los drivers nativos de los fabricantes y algunas claves de registro. Tengo en casa una cantidad ingente de información esperando a ser devorada y lo más importante, comprendida. 

Bajo esta premisa, me he encontrado con un proyecto de Alberto Ortega que personalmente me ha parecido brillante. Se trata de una herramienta muy sencilla que intenta detectar varias características y entornos virtualizados en base a una serie de peticiones. Estos entornos van desde una SandBox a entornos virtualizados, y a nivel de características si se encuentra algún módulo de depuración (Debugging) activo. 

Al probar la herramienta sobre un entorno virtualizado con VirtualBox, la herramienta detecta el entorno de manera exitosa y rápida, mostrando de manera clara y concisa por qué elementos ha preguntado.

Imagen 1.- Detección de entornos virtualizados con Pafish

Como soy un pirata, intenté hacer “sufrir” un poco a la herramienta de Alberto, probándola con algún tipo de aplicación que ocultase el entorno de virtualización. Por regla general, este tipo de aplicaciones enmascaran las peticiones que se realizan desde la capa de usuario, devolviendo en muchos casos respuestas erróneas o falseadas.

Una de estas aplicaciones se llama VMDetectguard. Esta aplicación entre otras funciones, intenta hacer creer a un Malware que se está ejecutando en otro entorno, mediante enmascaramiento de peticiones. 

Imagen 2.- VMDetectGuard. Soporte a diferentes sistemas

A la hora de ejecutar ambas herramientas, se puede comprobar cómo esta solución logra enmascarar ciertas peticiones, pero por el contrario no llega a engañar a esta gran herramienta.


Imagen 3.- Ejecución de Pafish en un entorno enmascarado

Como podréis comprobar, estamos ante una gran herramienta que a mi personalmente me está valiendo de fuente de información, pudiendo conocer de primera mano qué tipo de comprobaciones puede realizar un malware para la detección de entornos virtualizados y características varias.

Al ser open source, se puede ver todas las comprobaciones que la herramienta realiza. Sin duda algo muy práctico para el que quiera conocer con más detalle este tipo de labores, realizadas mayoritariamente por aplicaciones maliciosas.

El proyecto está alojado en GitHub, y os recomiendo que le echéis un vistazo.

Salu2!!

[+] https://github.com/a0rtega/pafish

------------------------------------------------------------
Contribución por Juan Garrido
Leer más...

30 octubre 2012

Reversing malware tales: Persiguiendo a GetProcAddress()

En la anterior entrada de la saga hablábamos de la función GetProcAddress() y como permite enmascarar llamadas a funciones 'comprometedoras' de forma que, ante un análisis estático, parte de la funcionalidad mas comprometedora quede enmascarada por esa función al usarla como 'proxy'.

Hoy, vamos a ver como lidiar cuando nos encontramos con un ejecutable que, curiosamente, hace uso de esa función en varios puntos.

Partiendo del post anterior, habíamos dejado dos ejecutables 'prueba.exe' y 'pruebaget.exe' con la misma funcionalidad (descargar y ejecutar un fichero) pero con la salvedad de que uno lo hacía directamente y otro a través de GetProcAddress()

Veamos a Olly analizando ambos binarios (click para ver mas grande):

Prueba.exe (usa directamente las funciones)

PruebaGet.exe (usa las funciones a través de GetProcAddress()
Si jugamos al juego de las diferencias, podemos ver que el binario que no emplea GetProcAddress() anuncia que usa URLDownloadToFile() y WinExec(). En el segundo binario esas funciones ya no aparecen anunciadas y sin embargo sabemos que hace uso de ellas.

En este escenario, con el binario prueba.exe podríamos simplemente poner unos breakpoints en las funciones sospechosas y esperar a ver de que forma son empleadas. En el segundo binario no es tan fácil.

Lo primero que vamos a hacer es poner un breakpoint en la función GetProcAddress():

Buscamos la lista de funciones del binario


Ponemos el BP en GetProcAddress()
Una vez hecho esto, tan solo tenemos que pulsar F9 y esperar a que pare en algún punto sospechoso


Sorpresa ! Ya tenemos el primer punto sospechoso, vemos que GetProcAddress() está siendo llamado para obtener la dirección de memoria de URLDownloadToFile() función altamente sospechosa.

En este punto debemos pulsar F8 para que GetProcAddress() termine y nos enseñe en que dirección de memoria está URLDownloadToFile()

Si miramos en la ventana de los registros:



Vemos que en EAX se encuentra la dirección de memoria de la función que está enmascarando GetProcAddress().

En este punto podemos poner directamente un breakpoint en esa dirección y esperar, es muy recomendable tener cargado el plugin para Olly CommandBar para poder poner BPs sin mucha complicación



En mi caso pongo el BP en 444C4868 porque es la dirección que ha devuelto GetProcAddress()

Si volvemos a pulsar F9, vemos que se para justo en esa dirección y si miramos atentamente la ventana del stack:



Encontramos los parámetros de URLDownloadToFile().

Podemos repetir este método tantas veces como sea necesario para seguir la pista a GetProcAddress()

Si queréis descargar los binarios lo podéis hacer desde aquí. Recordad que el código fuente de ambos está en el anterior post

Nota: Algunos antivirus saltan con esos ejecutables.
Leer más...

28 octubre 2012

Enlaces de la SECmana - 146


Leer más...

27 octubre 2012

Crónica del curso Perito Informático Forense en la UPV





Disclaimer: Estimado lector, si has llegado a este artículo buscando ayuda con relación a algún análisis forense, formación relativa al tema o a una asociación existente, yo, Lorenzo Martínez, a título personal, te quiero hacer saber que ya no me encuentro en la ANTPJI. Por ello, si piensas que puede darte ciertas garantías que yo pertenezca a la misma, te ruego que leas el post relacionado con ANCITE, Asociación Nacional de Ciberseguridad y Pericia Tecnológica.

------------------------------------------------------------------------------------------------------------------------------


Hace una semana, tuve el placer de participar como ponente en el curso de Perito Informático Forense, organizado por la Asociación Nacional de Tasadores y Peritos Judiciales Informáticos (ANTPJI), impartido en la Facultad de Informática de la Universidad Politécnica de Valencia.

Tuve el honor de compartir plantel con grandes figuras del mundo de la seguridad, profesionales especializados en análisis forense y Cuerpos y Fuerzas de Seguridad del Estado. Entre otros, fue un placer poder disfrutar de la compañía de nuestro amigo Chema Alonso, que dio una charla muy amena (como siempre) explicando diversas usos de la Forensic Foca sobre escándalos muy conocidos y sonados.


Además, estuvo genial poder volver a ver al gran Pedro Sánchez, escritor del blog de alto contenido forense, Conexión Inversa. Lamentablemente, por el horario que le tocó a Pedro para dar su charla, sumado a mi despiste, me la perdí, pero el feedback de la gente fue genial.



Otra de las charlas que resultó muy bien recibida por parte del público, fue la del capitán del GDTCésar Lorenzana, que además de realizar una gran labor en su unidad, demostró unas excelentes cualidades como ponente y comunicador. 



Fue además el punto de lanzamiento del libro de mi amigo perito Rafael López, titulado "Peritaje Informático y Tecnológico", del que me obsequió con uno de los diez ejemplares de la serie cero de la misma.



Como crónica de este evento, me gustaría resaltar sobre todo la gran acogida del mismo entre los asistentes. De hecho, desde un punto de vista personal, como ponente de unas de las charlas, mi sensación de haber concienciado y enseñado a los 150 asistentes que atestaban la sala, ha sido bastante buena y eso "me llena de orgullo y satisfacción".



Quiero agradecer desde aquí a la Universidad Politécnica de Valencia y a la ANTPJI por haber hecho posible la realización del evento.

Nos vemos en la siguiente edición!
Leer más...

26 octubre 2012

Hola, hola, ¿se escucha bien por ahí?

Luego de un tiempo vuelvo a compartir un punto de vista, que ha surgido a partir de cubrir el primer día del  #6enise y de un comentario posterior de mi amigo Gastón Rivadero (@derlok_epsilon) que decía más o menos algo así: "¿No te queda la sensación de que todo termina en un grupo de gente que se junta a decir más o menos lo mismo, pero nadie lo hace?"

Creo que su lectura es acertada, y es que ¿no les parece que en definitiva terminamos todos los profesionales de seguridad diciendo lo mismo? voy a destacar algunos puntos para intentar mostrarlo:

|- El ser humano es el eslabón más débil


Nada más cierto, los ataques lo demuestran, desde campañas de phishing bien absurdas hasta la más compleja de las APTs, todo termina en un usuario que sin mucho cuidado hace click en algo que aprovecha una vulnerabilidad y listo, ya estamos adentro.
Hay que concientizar (o como diría un amigo, "acojonar"), esa generalmente es la conclusión, incluso requerido por más de una ley o regulación, pero entonces, ¿por qué no se hace?



|- No se parchea

Otra gran verdad, se suele ver aún en la más crítica de las infraestructuras ausencia de parches de seguridad, así como también en los puestos de los usuarios, esto último quizás potenciado por la falta de un catálogo de software aprobado, limitación de privilegios en los usuarios, etc, etc. ¿por qué no se hace?






|- El perímetro es el usuario (sus aplicaciones y dispositivos)
Coincidimos en esto hace un tiempo, pero fue necesario que el usuario lo demuestre llevando su dispositivo al trabajo, dando lugar a una sigla bien simpática "BYOD". Ahora que justo habíamos terminado de configurar el firewall e inventariar las desktops, se les ocurre comenzar a utilizar sus propios dispositivos :S
¿por qué vamos tan atrás?


|- Es necesario un inventario

Pues que cierto que es esto, necesitamos saber qué tenemos!!
¿Por qué salimos a implementar medidas sin contar con un inventario? ¿Por qué nos preocupamos por el ROI, si antes no conocemos los riesgos, a qué activos impactan y qué valor tienen?
Debemos relevar los activos, catalogarlos, y realizar análisis de riesgos, las regulaciones lo exigen, así como varios estándares de seguridad y ahora las estrategias nacionales de ciberseguridad. ¿por qué no se hace?

NOTA: es bueno saber que ahora las telcos saben que tienen redes industriales ;)


|- Hay que gestionar los incidentes de seguridad



Otra gran verdad, sin embargo en muy pocos lugares se nota alguna preocupación por la conformación de grupos de respuesta a incidentes. En verdad, en muchos lugares todavía están definiendo cuestiones más elementales. Ya habrá tiempo para este tema, o esperaremos que nos pase. Creo que la gente de Diginotar pensaba algo así. ¿por qué no se hace?



La lista de temas sigue, y seguro coincidimos en muchos, aunque en otros tengamos alguna diferencia. Ahora bien, creo que habría que comenzar a debatir el "¿por qué no se hace?", y digo esto luego de ponerle como título al post "Hola, hola, ¿se escucha bien por ahí?", ¿acaso es un problema auditivo? creo que en realidad todos los que estamos de acuerdo en estas premisas y tantas otras, deberíamos comenzar a replantearnos las estrategias de comunicación. 

Claramente el resultado demuestra que hemos fallado, y digo esto, sin obviar que en muchos lugares las decisiones están en manos de gente irresponsable (incluyendo a nuestros políticos), pero en muchos otros lugares, seguimos preocupados por convencer a Jefe de Sistemas, Desarrollo o a nuestro propio Jefe de Seguridad, cuando en realidad nuestro público debería estar a otro nivel. En definitiva, quizás deberíamos aprender a jugar al golf :)

Contribución gracias a Mariano M. del Río
Leer más...

25 octubre 2012

Hackeos Memorables: SpotBros a WhatsApp

Hace tiempo hablamos sobre SpotBros, una aplicación de mensajería instantánea que compite en el mismo segmento que WhatsApp.

SpotBros es notáblemente mas segura en su diseño. De entrada, cuando te registras en la red, el password lo eliges tu, no es tu IMEI, no es la MAC de tu tarjeta Wifi. Personalmente opino que el mero hecho de tener que alabar algo tan básico como este punto, deja en un pésimo lugar a WhatsApp.

No solo en materia de seguridad se distancia de whatsapp, también en funcionalidad. En SpotBross existen dos cosas que a mi me parecen sumamente interesantes. los 'Shouts' y los 'Spots'.

Los Shouts son una forma de comunicarse con gente cercana a ti. Lanzas un mensaje y ese mensaje es leído por la gente que se encuentre a un radio -aproximadamente- de 1,5km a la redonda. Viene muy bien para estar al tanto de lo que se mueve por tu zona, cortes de calles, dudas sobre 'donde comprar X' etc etc.

Los Spots son grupos con un interés común, vagamente podrían ser análogas a las salas de chat, para localizarlas tienes que estar cerca de donde se creó dicho grupo.

He visto, por ejemplo, que en mi urbanización han creado un 'grupo de padel' ahí la gente se ofrece para organizar partidos entre vecinos. Cualquier vecino con SpotBros que viva por la zona verá ese grupo y se puede unir si así lo desea.

Hace poco hubo un lanzamiento masivo de SpotBros, coincidiendo con la puesta a disposición de la versión para IOS.

Y aquí viene la polémica. Junto con la instalación, se ofrecía la posibilidad de enviar a tus contactos de WhatsApp un mensaje hablando de SpotBros.

A raíz de eso hubo cierta polémica bastante artificial sobre si eso era o no SPAM. Cualquier red tipo Facebook o similares, en el proceso de darte de alta, ofrece la posibilidad de 'invitar' a tus contactos del MSN, Gtalk, etc. Por tanto, rasgarse las vestiduras y acusar a SpotBros de SPAM me resulta bastante chocante (y aun más hacerlo desde una red que hace exactamente lo mismo ...). Máxime cuando estaba la opción de no enviar dicho mensaje.

Al calor de dicha polémica, nadie se ha parado a reflexionar en el detalle técnico. Y eso, creo, es lo más 'bonito' de este asunto.

De entrada, WhatsApp no ofrece ninguna forma de enviar mensajes sin intervención del usuario. No existe API, tampoco forma oficial de hacer eso. Por tanto, ¿Cómo lo hicieron?

Los tiros -sospecho- tienen que ir hacia WhatsAPI, la implementación no oficial y tristemente coaccionada de WhatsApp.

Yo apuesto porque durante el proceso de instalación de SpotBros, éste se hacía con la información necesaria para hacer login en la red WhatsApp (IMEI en Android, MAC de la Wifi en IOS) y luego enviaba dicha información a los servidores de SpotBros, donde había un proceso que, usando WhatsAPI, enviase dichos mensajes.

Sin duda, un 'OWNED' en toda regla. Aprovechándose de las debilidades de WhatsApp y su deficiente sistema de registro, consiguen emplear la plataforma de su competidor en beneficio propio.

UPDATE: Tal y como explica Alejandro Lopez en uno de los comentarios, en realidad lo que ha hecho SpotBros es crear un minicliente WhatsApp en Java e integrarlo dentro de la aplicación. Con lo que no intervienen los servidores de SpotBros


Leer más...

24 octubre 2012

InfoSec Reactions: Humor y seguridad

Desde hace tiempo twitter está revolucionado con una web que ha causado furor. Su nombre: Infosec Reactions.

En esta web, a través de divertidos gif animados, ilustran ciertas situaciones relacionadas con el mundo de la seguridad.

Podéis visitar la web aquí y seguir en twitter la cuenta oficial.

Algunos hilarantes ejemplos:


Cuando un amigo me envía un fichero PDF

Cuando les digo a mis amigos que hago 'penetration testing'

Evadiendo un IDS



Cuando alguien dice que su firewall no se puede traspasar
La creadora de este proyecto es aloria y podéis enviar vuestros propios gifs a la web para que sean publicados.
Leer más...

23 octubre 2012

Sandbox en Adobe Reader X


Teniendo en cuenta el amplio historial de vulnerabilidades que han surgido en los productos Adobe, y especialmente Reader, finalmente se decidieron a incorporar a finales del 2010 más medidas de protección. En este artículo se va a hablar del Protected Mode de Adobe X, en el que implementa una sandbox para mitigar la explotación de las vulnerabilidades del conocido lector de PDFs. Este es realmente necesario y más teniendo en cuenta las formas de infección automáticas que pueden producirse.

Descripción de Protected Mode

El Protected Mode tiene como objetivo proteger al usuario aunque Adobe Reader sea vulnerable. Esto no sucedía en las versiones anteriores, donde la explotación exitosa de cualquier bug de seguridad tenía un impacto directo. La sandbox es un mecanismo de seguridad para ejecutar una aplicación en un entorno restringido donde ciertas acciones están prohibidas. Al fin y al cabo es una capa adicional de seguridad.

Con Protected Mode todas las operaciones necesarias para renderizar un PDF se ejecutan en un entorno restringido; la sandbox. Todas las acciones que no se permiten realizar en la sandbox, como la escritura en el directorio temporal o apertura de un adjunto incrustado en el PDF mediante una aplicación externa, se envían al broker. Éste mediante un listado de políticas determina si se puede realizar o no para evitar acciones maliciosas.

Ventajas / Inconvenientes

Sus puntos fuertes son:
  • Utilizar el sistema de seguridad implementado a nivel de SO: la sandbox de Adobe Reader recae en las características de seguridad de Windows (niveles de integridad bajos, job objects y tokens restringidos).
     
  • La sandbox se basa en Google Chrome y Microsoft Office 2010 (Protected Viewwing Mode) los cuales toma en consideración.
     
  • Principio de menor privilegio: un proceso sólo puede acceder a lo necesario para realizar su función; nada más.
  • Asumir que todas las acciones que se quieren realizar fuera de la sandbox son maliciosas hasta que se valide y se demuestre lo contrario. Para realizar estas acciones se hace uso de broker para comunicarse con el exterior.
     
  • Entorno limitado para la ejecución del render.
     
  • Se hace diferencia entre dos entornos: PDF principal / user principal.
Tiene una serie de limitaciones:
  • Está basada en la seguridad de Windows, y por lo tanto si se encuentra algún fallo en la misma, la seguridad de la sandbox se ve comprometida.
  • Existen funcionalidades no implementadas. Pero los ataques derivados de no separar escritorios se pueden mitigar con otras técnicas.

Funcionamiento

En Adobe Reader se utilizan los mecanismo del SO para ejecutar los procesos usando el principio de mínimo privilegio posible. En este escenario cada proceso tiene el privilegio necesario para realizar sus acciones habituales y ninguno más. Esto tiene tres consecuencias directas:
  • El procesado de un PDF sucede dentro de la sandbox (parseo del PDF e imágenes, ejecución de JavaScript, renderizado de fuentes y 3D)
     
  • Cuando algún proceso necesita ejecutar una acción fuera del sandox se realiza a través del broker que funciona como una especie de proxy.
     
  • Existencia de dos entornos separados: user principal que es el contexto en el que se ejecuta la sesión de usuario, y PDF principal el cual es un proceso aislado que parsea y renderiza el PDF. El límite entre la sandbox y la sesión de usuario/SO viene determinado por el proceso broker.
El objetivo que se persigue es ejecutar el renderizado del fichero PDF, el cual puede contener datos maliciosos, en un contexto restringido (PDF principal) y no privilegiado (user principal). Es el broker en el que realiza las acciones como user principal cuando se requiere hacer una llamada al sistema o conseguir acceso de escritura a un fichero.

Artículo cortesía de David Montero
Leer más...

22 octubre 2012

Cuckoo Sandbox Open Source malware analysis

Muchos de vosotros habréis tenido ganas de poder realizar algún análisis de malware para saber que hacía algunas de las muestras que os han llegado, bien por correo electrónico, bien os lo habéis encontrado en aquel pen drive que algún familiar os dice "Toma copia estas fotos" y en el USB hay mas malware que fotos para copiar.

Si no habéis lidiado realizando un análisis dinámico de la muestra o bien, no tenéis práctica ni tiempo, al final acabas subiendo la muestra aquellos servicios que ya conocemos, Virus Total Jottis, Threat Expert o similares.

Pero, y si por un momento ¿No queremos subir la muestra a este tipo de servicios? Por ejemplo os encontráis en un caso en el que no podéis distribuir la muestra ya que estáis investigando un caso y la muestra no puedes subirla a cualquier sitio. En ese caso y otros, para hacerte con una idea general de lo que hace la muestra y poder realizar perfectamente un análisis dinámico tenemos entre otros proyectos Cuckoo.
El proyecto se encuentra MUY vivo y se va actualizando añadiendo nuevos módulos al sandbox y nuevas versiones cada cierto tiempo. Además las últimas versiones se instalan en no mas de 10 minutos, no como las primeras, que tenías que lidiar realizando mas pasos.

¿Como funciona Cuckoo?

El sandbox se apoya en el sistema de virtualbox o vmware con un sistema windows instalado como cliente para poder realizar los análisis.
La estructura de Cuckoo es así:



Desde tu máquina enviarás tus muestras a los diferentes clientes que tengas configurados con Cuckoo para poder hacer los análisis pertinentes.

Requerimientos de Cuckoo en el HOST

La instalación mas sencilla es en Ubuntu, por lo tanto yo haré la instalación en este sistema.
Si miramos la documentación de Cuckoo, necesitaremos:

  • Python
  • Magic (Highly Recommended): for identifying files’ formats (otherwise use “file” command line utility)
  • Dpkt (Highly Recommended): for extracting relevant information from PCAP files.
  • Mako (Highly Recommended): for rendering the HTML reports and the web interface.
  • Pydeep (Optional): for calculating ssdeep fuzzy hash of files.
  • Pymongo (Optional): for storing the results in a MongoDB database.
  • Yara and Yara Python (Optional): for matching Yara signatures.
  • Libvirt (Optional): for using the KVM module.
Algunos de los módulos se pueden instalar mediante:


sudo apt-get install python-magic python-dpkt python-mako python-pymongo



Máquina virtual para las pruebas


No me voy a parar a explicar como configurar una máquina en VirtualBox. Tan solo que en la máquina Windows instalada deberemos de configurar ciertas cosas:



Pondremos en OFF, el cortafuegos de windows y también las actualizaciones. Esto nos evitará en el caso del análisis de las trazas de red que no nos molesten las actualizaciones de red. Y el firewall lo desactivamos para que el malware se pueda conectar libremente a donde quiera.


Requerimientos de Cuckoo en la máquina virtual


Python, para poder ejecutar el agente en la máquina virtual. Además necesitaremos software vulnerable, es por eso que instalaremos el software que necesitemos.

Para versiones viejas de software, oldapps ;)

Configurando y poniendo en marcha Cuckoo

Solo configuraremos opciones básicas de cuckoo para hacerlo funcionar. Recomiendo recorrerse los archivos de configuración y adaptarlo a vuestras necesidades.

Bajamos Cuckoo :

seifreed@darkmac:~/tools/malware:git clone git://github.com/cuckoobox/cuckoo.git
Cloning into 'cuckoo'...
remote: Counting objects: 6324, done.
remote: Compressing objects: 100% (2048/2048), done.
remote: Total 6324 (delta 4101), reused 6214 (delta 4017)
Receiving objects: 100% (6324/6324), 4.88 MiB | 124 KiB/s, done.
Resolving deltas: 100% (4101/4101), done.


Ahora configuraremos varias cosas de Cuckoo para hacerlo funcionar:

Editamos el archivo cuckoo.conf:

seifreed@darkmac:~/tools/malware/cuckoo:nano conf/cuckoo.conf

De aquí lo que tendremos que cambiar es:


# Specify the name of the machine manager module to use, this module will
# define the interaction between Cuckoo and your virtualization software
# of choice.
machine_manager = virtualbox


# Enable or disable the use of an external sniffer (tcpdump) [yes/no].

use_sniffer = yes


# Specify the network interface name on which tcpdump should monitor the

# traffic. Make sure the interface is active.
interface = en0


Si usamos otro sistema que no sea Virtualbox, lo cambiamos. En mi caso dejo Virtualbox.
Si recordáis como requisito instalamos tcpdump, si queremos que se capture el tráfico de red con tcpdump, dejamos marcado yes.

En cuanto a la interfaz de red, esto es muy importante y ha dado varios problemas de que no haya funcionado la última versión de cuckoo.

En la documentación oficial de Cuckoo, aconsejan usar vboxnet0. La máquina virtual configurada con esta extensión NO tendrá acceso a internet por lo tanto si estamos estudiando algún tipo de troyano bancario, o un dropper no podrá hacerse el análisis dinámico correcto al no contar con el tráfico de red.
Si queremos poner la red en modo vboxnet0, lo configuramos en Virtualbox




En la máquina virtual especificamos que usaremos esa interfaz en concreto:


El poner la red en vboxnet0 nos sirve para poder controlar las conexiones que realice la máquina virtual. En mi caso me da igual por lo tanto, dejo la máquina en brigde y asigno la interfaz de la máquina. En el caso del mac, en0.

Ahora configuramos otro archivo:

seifreed@darkmac:~/tools/malware/cuckoo:nano conf/virtualbox.conf

[cuckoo1]
# Specify the label name of the current machine as specified in your
# VirtualBox configuration.
label = sandbox


# Specify the operating system platform used by current machine

# [windows/darwin/linux].
platform = windows


# Specify the IP address of the current machine. Make sure that the IP address

# is valid and that the host machine is able to reach it. If not, the analysis
# will fail.
ip = 192.168.1.113


Aquí especificamos el nombre que le hemos dado a la máquina virtual, la plataforma que usaremos y la dirección IP que tendrá la máquina virtual.

Comunicación de la máquina virtual y Cuckoo

Con la última versión de Cuckoo, lo que se necesita es un agente en python:


seifreed@darkmac:~/tools/malware/cuckoo:ls agent/
agent.py


El agente deberemos de colocarlo para que se inicie al arrancar Windows, o bien con una entrada del registro, o en la carpeta startup.

En este momento pausamos la máquina. Hacemos una instantánea y apagamos la máquina.
Restauramos la máquina al snapshot con la máquina virtual parada.
Arrancamos Cuckoo:


seifreed@darkmac:~/tools/malware/cuckoo:python cuckoo.py 


  eeee e   e eeee e   e  eeeee eeeee 

  8  8 8   8 8  8 8   8  8  88 8  88 
  8e   8e  8 8e   8eee8e 8   8 8   8 
  88   88  8 88   88   8 8   8 8   8 
  88e8 88ee8 88e8 88   8 8eee8 8eee8


 Cuckoo Sandbox 0.4.2

 www.cuckoosandbox.org
 Copyright (c) 2010-2012


2012-10-08 22:57:59,479 [lib.cuckoo.core.scheduler] INFO: Using "virtualbox" machine manager

2012-10-08 22:57:59,658 [lib.cuckoo.core.scheduler] INFO: Loaded 1 machine/s
2012-10-08 22:57:59,659 [lib.cuckoo.core.scheduler] INFO: Waiting for analysis tasks...


Cuckoo estará a la espera de que hagamos submit de una muestra:


seifreed@darkmac:~/tools/malware/cuckoo/utils:python submit.py /Users/seifreed/Dropbox/malware/zeus/AZz.exe 
SUCCESS: File "/Users/seifreed/Dropbox/malware/zeus/AZz.exe" added as task with id 1


Cuckoo empezará el análisis de la máquina virtual:


2012-10-08 22:58:22,694 [lib.cuckoo.core.scheduler] INFO: Starting analysis of file "/Users/seifreed/Dropbox/malware/zeus/AZz.exe" (task=1)
2012-10-08 22:58:22,785 [lib.cuckoo.core.scheduler] INFO: Task #1: acquired machine cuckoo1 (label=sandbox)
2012-10-08 22:58:22,823 [lib.cuckoo.core.sniffer] INFO: Started sniffer (interface=en0, host=192.168.1.113, dump path=/Users/seifreed/tools/malware/cuckoo/storage/analyses/1/dump.pcap)
2012-10-08 22:58:25,876 [lib.cuckoo.core.guest] INFO: Starting analysis on guest (id=cuckoo1, ip=192.168.1.113)
2012-10-08 22:59:14,744 [lib.cuckoo.core.guest] INFO: cuckoo1: analysis completed successfully
2012-10-08 22:59:20,010 [lib.cuckoo.core.processor] WARNING: The processing module "VirusTotal" returned the following error: VirusTotal API key not configured, skip
2012-10-08 22:59:22,147 [lib.cuckoo.core.scheduler] INFO: Task #1: reports generation completed (path=/Users/seifreed/tools/malware/cuckoo/storage/analyses/1)


Una vez acabado podremos ver el resultado en la parte web de Cuckoo, arrancamos la parte web:



seifreed@darkmac:~/tools/malware/cuckoo/utils:python web.py 
Bottle v0.11.dev server starting up (using WSGIRefServer())...
Listening on http://0.0.0.0:8080/
Hit Ctrl-C to quit.


Desde la parte web podremos hacer un submit nuevo de una muestra, además de indicarle la prioridad.




En el apartado Browse, encontraremos las muestras que ya hayamos subido.
Clicando en el MD5, encontraremos un report de la muestra:



Información que nos arroja Cuckoo




Podremos ver también la parte de red, y cambios a nivel de directorios.

Aquí tenéis una introducción al pedazo de proyecto que se está gestando, os animo a colaborar además de usar la herramienta.

Artículo cortesía de Marc Rivero López

Leer más...

21 octubre 2012

Enlaces de la SECmana - 145


Leer más...

19 octubre 2012

Microsoft Message Analyzer (beta)

Microsoft Message Analyzer (beta), se presenta como el sucesor del sniffer Network Monitor de la misma compañía.

Pese a que esperaba una mejora importante, la gente de Redmond parece que no ha dado con la tecla en este nuevo producto.

La pantalla principal mantiene una estructura clásica de cualquier otro sniffer, donde los paquetes y flujos se muestran en una parte superior y el contenido y su decodificación en la parte inferior.

Sobre el tráfico, denominado "operaciones", se puede profundizar para ganar visibilidad mediante una estructura de tipo árbol  El volcado de datos es demasiado moderno. Ha convertido una salida tradicional en hexadecimal en una sopa de letras y números. Eso si, es capaz de renderizar imágenes y otros ficheros si los detecta.

La verdad es que me encararía contar características increíbles de la utilidad, pero no he conseguido comprender la filosofía "Message" de la herramienta. Me quedo con la sensación de que ha sido creada por un especialista en diseño gráfico siguiendo un manual de como evitar la usabilidad.



















Desde luego que lo más destacable son los escenarios de los que se adquieren datos, o mejor dicho, como se guardan y representan. Desde una LAN, hasta un dispositivo USB, Bluetooth o únicamente peticiones web.


La conclusión que saco es básica: ahorraros tiempo y no la probéis. Bastante con haber leído esta entrada.
Leer más...

18 octubre 2012

Infecciones automáticas mediante PDFs

La gente consciente de la seguridad/inseguridad informática sabe que un PDF puede contener malware y al abrirlo con una versión vulnerable del lector, la máquina del usuario puede ser infectada. De hecho es una de las formas más extendidas de distribuir software malicioso. Pero aunque hace años que se habló de otras formas de conseguir el mismo objetivo sin necesidad de abrir el fichero, mucha gente sigue no siendo consciente. Ya en el 2009 Didier Stevens mostró en su blog varias maneras, concretamente tres, de infectar una máquina sin necesidad de abrir un PDF. Incluso también existe una cuarta forma en la que no es necesario ni interacción por parte del usuario.


En los ejemplos mostrados se hace uso de las Shell Extensions para infectar la máquina del usuario, así que lo primero es comprender en qué consisten. Es un software añadido al explorador de Windows, de forma que éste incorpora una nueva funcionalidad gracias a la integración de software de terceros.  Un ejemplo sería la posibilidad de analizar un fichero/directorio con un AV mediante el menú contextual, o realizar una compresión con Winzip/Winrar/etc. Pero no sólo se trata de añadidos en el menú contextual, sino que también puede consistir en pestañas extras que se muestran al ver las propiedades de un fichero, previsualización de thumbnails, etc.

Como he comentado anteriormente, Didier Stevens en el 2009 utilizando como plataforma un Windows XP SP2 totalmente parcheado y corriendo un Adobe Reader 9 demostró éstas vías de infección. La versión 9 de Reader implementaba DEP, ASLR y MIC de nivel medio. Pero en la versión X, como medidas de seguridad se hace uso de una sandbox para mitigar futuras vulnerabilidades, y se ha rediseñado Adobe Reader para poder ejecutarse con un MIC de nivel bajo. Actualmente con Adobe Reader X las Shell Extensions (thumbnails, properties, preview) corren dentro de la sandbox y no se instala iFilter. Aquí lo explican.

NOTA: en Windows 7 de 64 bits he tenido problemas para utilizar las Shell Extensions. La cuestión es que la Shell Extension pdfshell.dll situada en C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX es de 32 bits y por lo tanto no es cargada por Windows Explorer de 64 bits. Como en Windows 7 de 64 bits ya no se puede lanzar un explorador de 32 bits de C:\Windows\SysWOW64, una forma de poder utilizar las extensions de 32 bits en Windows de 64 bits es mediante Half Shell. Pero todo apunta a que tampoco funciona correctamente debido a las modificaciones hechas por Microsoft en Windows 7.


Ahora que ya sabemos en qué consisten las Shells Extensions, es hora de ver las formas de explotar vulnerabilidades en un lector de PDF sin necesidad de abrir el fichero. Adobe Reader instala software extra que permite leer ficheros PDF a los componentes de Windows. Hay que tener en cuenta que éstas formas de infección son relativamente antiguas, hace tres años ya, pero sirven como base para conocer que no siempre abrir un fichero es la única forma de infectarnos. Por lo tanto una infección mediante alguno de éstos métodos o similares sería posible en software actual si no existen mitigaciones a otros niveles:


1) Column Handler Shell Extension: es un objeto COM que le proporciona a Windows Explorer datos adicionales sobre un determinado tipo de fichero. Windows Explorer muestra estos datos en columnas extra. En el caso de un PDF éstos serían el título, autor, etc.

Cuando Windows Explorer tiene que mostrar un PDF, invoca al Column Handler para que lea los datos del PDF y se los pase a él. Por lo tanto, haciendo click sobre un fichero malicioso se ejecutaría el shellcode incluido en el mismo quedando infectada la máquina.

Si quisiéramos desinstalar las Shell Extensions relacionadas con PDFs, lo podemos hacer mediante el Shell Extension Manager de Nirsoft o la utilidad Autoruns de Sysinternals


2) Cuando en Windows Explorer se utiliza la vista Thumbnail se muestra la primera página del PDF en formato mini-imagen. Esto implica la lectura del PDF, por lo tanto también podemos aprovecharnos de un Adobe Reader vulnerable para realizar la infección.


3) Al situar el cursor sobre un fichero PDF se muestran las propiedades y los metadatos del mismo. Si se incrusta un stream object malformado en los metadatos que se aproveche de una vulnerabilidad, se puede ejecutar código con sólo situar el cursor sobre el fichero. Esto se debe a que Windows para mostrar el tooltip lee los metadatos mediante una aplicación (como Adobe Reader).


Debido a que, como hemos visto, no es necesario hace doble click para ejecutar el malware, Didier Stevens recomienda cambiar la extensión del mismo: malware.pdf.mal. Con esto evitaremos infecciones automáticas indeseadas como las previamente comentadas.


Antes había hablado de iFilter, y es hora de que sepamos en qué consiste. El indexador de contenido Windows Indexing Service (llamado Windows Desktop Search en Windows XP y Windows Server 2003), fue reemplazado por Windows Search en Windows Vista y 7. El IFilter AcroRdIF.dll extiende la funcionalidad de Windows Indexing Service para indexar el contenido de los PDFs. Windows puede leer y por lo tanto indexar el contenido de ciertos ficheros, como sería cualquier txt, pero para formatos más específicos hace uso de aplicaciones de terceros. Es ahí donde entre en juego iFilter, ya que sin él el contenido de un fichero PDF no puede ser parseado ni indexado por Windows Search.

Dicho de otra manera, cuando Windows Search indexa contenido, al no entender el formato de ciertos ficheros busca en el registro el IFilter correspondiente. El demonio de indexado de contenido (cidaemon.exe) llama a Acrobat IFilter (AcroRdIF.dll), el cual carga el parser (AcroRD32.dll). Es éste el que se encarga de parsear el contenido y pasarle a Windows Search el texto extraído del documento para que lo indexe.

Como reseña histórica indicar que en Windows XP SP3, Windows Indexing Service se ejecutaba como System, y por lo tanto la DLL AcroRdIF también. El servicio no se iniciaba automáticamente, sólo si lo activábamos expresamente después de realizar una búsqueda como administrador.

En Windows Desktop Search 4.0 se ejecutaba también como system, pero AcroDrIF.dll corría en un proceso a parte bajo la cuenta local service. Por tanto hubo una mejora en el diseño de seguridad del mismo.

Para evitar la explotación de una vulnerabilidad en Adobe Reader mediante IFilters, procedemos a eliminar la correspondiente entrada del registro:

regsvr32 /u AcroRdIf.dll

aunque, como se ha dicho antes, en la versión X actual ya no se incluye.

Aunque existen estas dos posibilidades para ejecutar el payload de un fichero de forma automática (sin abrir el PDF y sin interacción), los autores de malware sigue prefiriendo el uso de ingeniería social para que los usuarios de forma manual abran el PDF.

El shellcode incrustado en el fichero PDF podría ejecutar cualquier instrucción, pero la shellcode clásica descarga un troyano. Primero busca el system directory (system32), descarga un troyano de Internet y lo guarda en el system directory ejecutándolo finalmente. Aunque también existen ficheros que contienen de forma embebida el troyano. En este caso la shellcode extrae el ejecutable, lo guarda en disco y lo ejecuta.


Artículo cortesía de David Montero
Leer más...