Me parece que se me había pasado comentaros pero…

Realizar un análisis dinámico a una muestra de malware es algo rápido que puede aportar gran cantidad de datos útiles a la hora de abordar un análisis más completo. Previamente hemos comentado como desempaquetar un malware protegido, pero en este caso concreto no es necesario realizar este paso dado que la muestra se desempaqueta y ejecuta de forma normal en una máquina virtual (VM).

En la actualidad existe un gran número de sandboxes (ambientes controlados) que permiten analizar un binario para saber qué es lo que hace exactamente en el sistema cuando se está ejecutando. El mayor problema que se suele tener cuando se analizan múltiples archivos encontrados in the wild, es la dificultad de realizar una clasificación rápida sobre los mismos.

Para esos casos concretos tenemos Malheur, una herramienta desarrollada por Konrad Rieck (al que he tenido el placer de conocer personalmente) en la University of Göttingen. Malheur permite realizar esa preciada clasificación/categorización usando algoritmos de machine learning  teniendo como entrada los reportes generados de diferentes sandbox de malware populares como pueden ser: CWSandbox, Anubis, Norman Sandbox, Joebox o Cuckoo. La versión general de Cuckoo no es directamente compatible, pero si se hace uso de una versión modificada se puede realizar sin problema alguno. Las características más relevantes de la herramienta son las siguientes:

• Extracción de prototipos: Partiendo de todos los reportes, se identifica un subconjunto de prototipos que sean representativos de todo el dataset. Estos prototipos muestran una visión general rápida del comportamiento de los datos obtenidos, lo que puede ser usado para una primera aproximación.

• Agrupación de comportamientos: Se identifican grupos (clusters) de reportes que muestran un comportamiento similar. Esta técnica permite descubrir clases nuevas de malware y proporciona un apoyo para la elaboración de defensas, como pueden ser las firmas.

• Clasificación de comportamientos: Basándose en los grupos previamente encontrados, se puede asignar ese comportamiento desconocido a familias de malware conocidas. La clasificación puede ayudar a identificar variantes que no han sido previamente encontradas.

• Análisis incremental: En caso de necesitar realizar los análisis con grandes conjuntos de datos, mediante el procesamiento por partes se logra que los requisitos de tiempo y memoria se vean altamente mermados. Si fuese necesario realizar este tipo de análisis de forma diaria con todo el malware entrante en una honeypot, esta solución sería la más adecuada.

Hay que tener en cuenta que el malware suele tener métodos de anti-debugging o anti-VM para detectar que pueden estar siendo analizados. Varias muestras suelen tener módulos concretos para detectar una determinada sandbox, por lo que es recomendable lanzar los análisis en el mayor número de plataformas diferentes para cerciorarnos que los resultados obtenidos son correctos. Esta detección por parte del malware se suele denominar red pill ya que, como en la película Matrix, la píldora roja te muestra la verdadera realidad.

Aunque los resultados indiquen algo claramente, tampoco deberíais creerlos ciegamente. Una recomendación sería coger unas muestras representativas de los grupos que consideres interesantes y echarles un ojo manualmente con IDA Pro/Immunity Debugger para asegurar que es cada cosa y no tener sustos innecesarios.

El que avisa no es traidor.

The post Detectando y clasificando malware dinámicamente appeared first on S3lab.

A lo largo del tiempo vuelan muchas muestras de malware por nuestras manos, que analizamos para lograr comprender su funcionamiento (ingeniería inversa). Este proceso es un arduo trabajo que puede llevar bastante tiempo dependiendo de la complejidad del propio malware y del packer o packers utilizados para protegerlo. Existen varios tipos, pero como ejemplo explicaremos como desempaquetar un packer sencillo que únicamente tenga una fase, como puede ser UPX (algunos implementan varias rutinas de empaquetado y desempaquetado).

El primer paso es saber si el binario esta empaquetado o no, para ello existen un gran número de herramientas que pueden ayudarnos, algunas de las más conocidas son RDG Packer Detector y PEiD (basadas en detección de firmas y calculo de entropía principalmente). Las imágenes que se muestran en la galería inferior son de un malware, pero para hacer las pruebas os proporcionamos un binario inofensivo de ejemplo («Hola Mundo» empaquetado con NsPack). El siguiente paso es abrir la muestra con un debugger, en este caso utilizaremos el clásico Immunity Debugger.

ImmunityDebugger_0

ImmunityDebugger_1

ImmunityDebugger_2

ImmunityDebugger_3

ImmunityDebugger_4

ImmunityDebugger_5

ImmunityDebugger_6

ImmunityDebugger_7

ImmunityDebugger_8

Una vez abierto, nos indicara que el entry point esta fuera del código (como se especifica en la cabecera PE). A continuación buscaremos el comando “PUSHAD” ya que realiza el push del contenido de los registros de propósito general en la pila. Bastará con hacer click derecho y acceder a “Search for” y dentro a “Command”.

Una vez se ha localizado dicha instrucción, pulsamos F2 para poner un breakpoint. Seguido, pulsamos F9 para que se ejecute el programa hasta la instrucción marcada. Tras pulsar F8 para llegar al “PUSHAD”, vamos a la sección de registros, marcamos ESP (Extended Stack Pointer) y haciendo click derecho en él, elegimos “Follow in Dump” para poder ver lo que se encuentra allí en el HEX Dump.

Ahora se visualizará, en el DUMP, el contenido en hexadecimal de la dirección correspondiente. Para controlar cuándo se vuelve a tener acceso a estos datos (presumiblemente accederá a ellos justo antes de ejecutar el código original o lo que es lo mismo, al final del desempaquetado de los datos) se debe poner un breakpoint hardware de acceso de tipo «Dword» en los primeros bits. Para ello, marcamos los primero 32 bits, hacemos click derecho y elegimos la opción que se ha comentado previamente. Luego, pulsamos F9 para llegar al momento en el que se vuelve a acceder a esos datos. Nos encontremos en un JMP”, pulsaremos F7 para entrar (nos llevará al código original de la muestra). Automáticamente Immunity no interpreta los datos como código, por lo que será necesario indicárselo. Click derecho, elegimos «Analysis» y finalmente «Analyse code».

Con estos pasos hemos logrado conseguir el código real del malware, el cual podremos analizar más en profundidad para entender su funcionalidad. En caso de querer crear el binario sin empaquetar, podremos utilizar el plugin OllyDumpEx para hacer el dump a través de la opción “Dump proccess”. Finalmente solo haría faltaría reconstruir las imports del ejecutable con ImpREC para que funcione correctamente.

Se utilizan varias técnicas anti-debugging para impedir este tipo de análisis, como puede ser utilizar la función KERNEL32.IsDebuggerPresent de winAPI. También suelen comprobar si la ejecución se está realizando en una máquina virtual utilizando el TSC (Time Stamp Counter) entre otros. En caso de que alguno de esos “triggers” salte, la ejecución cambiará y ocultará su funcionalidad real realizando algo inocuo. En otra ocasión explicaremos como intentar evadir esas técnicas de protección contra ingeniería inversa.

Recordad que estos análisis se tienen que realizar en entornos controlados para impedir cualquier infección en caso de que algo no salga como debería.

El que avisa no es traidor.

The post Ingeniería inversa de malware protegido appeared first on S3lab.

«I analyse, break and code stuff in no specific order.”

1. Es la pregunta típica, pero siempre es interesante saber la respuesta, ¿cuándo empezaste a ver que esto de la seguridad era lo tuyo?

Hacia el 2004, aproximadamente. Siempre me había interesado la seguridad informática en general pero nunca me había metido mucho en ella hasta que un día vi un aviso de seguridad de un escoces, David Litchfield, acerca de múltiples vulnerabilidades que había descubierto en el software de bases de datos Oracle e intenté reproducir algunas de las vulnerabilidades: en 1 hora tenía las vulnerabilidades que comentaba más algún 0day y me descubrí haciéndome mis propias herramientas automáticas para descubrir aún más. Debido a mi puesto laboral por aquel entonces, tenía acceso a todo el software Oracle, con parches, que quisiera para jugar y seguí mirando más: encontré decenas de 0days en escasos meses. Me pareció que no se me daba del todo mal para encontrar tanto tan rápido o que la calidad del software era tan triste que las posibilidades a encontrar vulnerabilidades no me superaban. Comencé por hacer todo lo que encontraba público hasta que un amigo argentino me dijo un día: “Ey! ¿Sabes que por esto pagan?”. Y hasta hoy.

2. Sin haber estudiado una carrera de ingeniería o ciencias de la computación, te has convertido en uno de los investigadores/auditores de seguridad más relevantes del panorama nacional. Cuéntanos por favor cuál ha sido tu trayectoria, cómo te has ido formando.

Mi principal formadora ha sido la curiosidad: “esto porque funciona así”, “qué pasaría si”, “esto porqué pasa si no debería” o, mi favorita, escuchar a alguien decir “eso es imposible”/”eso no se puede” sin dar un argumento convincente (o incluso dándolo, por aquello de ser un mayor reto). Respecto de mi trayectoria, cada 1,5 o 2 años aproximadamente, he cambiado radicalmente de herramientas y entorno (tanto laboral como profesional) y, mientras, he estado siempre estudiando todo lo que podía de tal o cuál ámbito relacionado con la seguridad informática que me interesaba en cada momento: desde el modelo OSI y kernels basados en Unix a ensamblador x86, teoría de grafos, matemáticas discretas o análisis de software (teoría de compiladores). Con ello he conseguido tener conocimientos de muchos campos completamente diferentes que, a la hora de dedicarme a la ingeniería inversa y la búsqueda de vulnerabilidades, me han venido de perlas. Sin embargo, me gustaría remarcar una cosa: el hecho de no haber estudiado una carrera no es algo que haya jugado precisamente a mí favor y es la peor recomendación que le podría hacer a alguien que tuviera la oportunidad de ir a la universidad. De hecho, me planteo ir algún día a la universidad (probablemente a distancia) y sacar la carrera de matemáticas, aunque ya con un hijo se hace mucho más difícil sacar tiempo. Aunque, por otra parte, no tengo prisa y me daría igual sacarla en 10 que en 20 años. Es más por gusto que por otra cosa.

3. Últimamente andas dando bastante guerra a las firmas de antivirus, ¿Cuándo decidiste poner tu punto de mira en ese colectivo?

Fue de casualidad. Para una conferencia de seguridad informática privada que organizamos unos amigos, alguien me preguntó si podría dar una charla acerca de cómo hacer fuzzing. Para esa charla hice una suite de fuzzing y, como no sabía que fuzzear, me dio por mirar antivirus que tuvieran una versión de línea de comandos para Linux. Así fue como empecé. Después, al ver lo “divertidos” (eufemismo para decir horriblemente mal hechos en general) que eran la mayoría de antivirus que había probado, decidí continuar investigando este tipo de software más en profundidad.

4. ¿Cuál es tu próximo objetivo para ayudar al mundo a protegerse un poco más?

De momento, seguir presionando a las casas antivirus para que hagan software de seguridad seguro, no bonitas interfaces gráficas con una etiqueta fosforita que ponga “SAFE”. Después, pues no tengo ni idea. Seguir buscando vulnerabilidades en software muy utilizado.

5. En tu día a día, ¿cuáles son tus herramientas de seguridad base?

IDA Pro, IDA Pro e IDA Pro. También Python, Pyew, Linux y software de virtualización (VirtualBox principalmente).

6. Sabemos que has reverseado todo lo que hay por reversear, pero ¿que ha sido lo que más batalla te ha dado?

El malware y el software muy mal hecho. El malware tiende a estar ofuscado y a protegerse para evitar que un analista descubra qué hace y cómo dicha pieza de software funciona. El software muy mal hecho… no sabes discernir si tiene ofuscación, trucos anti-lógica o es que simplemente son unos gañanes quienes lo programaron. Te puedes encontrar código que no se usa y se distribuye desde hace años pero cómo nadie sabe cómo funciona tal o cuál componente por si acaso no lo tocan, partes de un producto de la que perdieron el código fuente y lo “mantienen” en binario, parcheando el ensamblador y cargando una librería externa para continuar agregando más código cuando ya no tenían espacio en el binario original y… en fin, multitud de cosas similares que hacen la vida del “reverse engineer” un infierno.

7. Dentro del ámbito de la seguridad, ¿nos podrías decir algún otro compañero al que tengamos que seguir la pista?

Si bien hay mucha gente muy-muy buena, a nivel estatal mi favorito es Rubén Santamarta (Reverse Mode). Esta es mi opinión personal, pero hay pocos investigadores tan buenos como él en todo el mundo. Menos todavía tan humildes como él.

8. Fuera del mundo de la tecnología, ¿qué te gusta hacer? ¿Cuáles son tus hobbies?

Me gusta la música metal (principalmente Death, Doom y Black Metal), tocar el sintetizador (soy un aficionado, aprendí de oído un poco), la naturaleza en estado cuanto más puro mejor (hacer safaris, ver selvas o bosques, subir a montañas, ir a desiertos, etc…) y comer y beber bien, algo que se me empieza a notar en la figura…

9. Con el calendario en la mano, ¿por dónde te podemos encontrar en los próximos meses?

Pues en Octubre estaré en la conferencia T2 en Helsinki, Finlandia, y entre Noviembre y Diciembre, en la conferencia KiwiCon en Wellington, Nueva Zelanda. Y ya por suerte, salvo imprevistos, hasta Marzo del año que viene no vuelvo a viajar.

10. Para acabar con una sonrisa, ¿alguna anécdota graciosa que nos puedas contar?

Pues por ejemplo, una batalla de una empresa antivirus comentada por una amiga… Hace algún tiempo tenían un PC normal y corriente que generaba con un .BAT las firmas de dicho antivirus que se publicaban diariamente. Por algún motivo raro, a veces llegaban por la mañana y se encontraban el PC apagado y las firmas que no se habían publicado. Un día descubrieron que el problema era que el PC estaba en el suelo y que la persona de la limpieza, sin querer, a veces le daba con la fregona al botón de apagar (dejando sin la protección actualizada a todos sus clientes hasta que por la mañana llegaban las personas encargadas y lo publicaban a mano). La solución: pusieron el PC encima de una mesa. Batallas como estas, en cualquier empresa de software, puedo contar mil.

The post Entrevista a Joxean Koret (@matalaz) appeared first on S3lab.