Posts Tagged ‘malware’

Phishing, malware y botnets: las amenazas más comunes en internet

El pasado 2 de octubre, en el contexto de la reunión anual de la industria de Bienes de Consumo y Distribución, nuestro CTO Pablo de la Riva explicó los más frecuentes riesgos tecnológicos para empresas contra los que luchamos en buguroo. A estas alturas, seguramente no sorprenderá a nadie que dichas amenazas sean phishing, malware y botnets.

INDUSTRIA

Respecto al phishing, se hizo un rápido repaso a su evolución. Una amenaza que originalmente estaba enfocada casi en su totalidad a atacar webs de entidades bancarias, pero que con el tiempo se ha expandido a otras industrias. El concepto es sencillo: copiar una web para que sea lo más parecida posible a la página legítima, distribuir la réplica por doquier y recopilar las credenciales de los usuarios que caigan en el engaño.

El malware se presentó como un riesgo más peligroso que el phishing, fundamentalmente por su carácter dinámico. Una vez un equipo está infectado, el malware entra en funcionamiento cuando su creador quiere: eso implica un comportamiento sigiloso, imperceptible para un usuario que hace login en una cuenta de email o en su banca online.

Por último, el concepto que quizá sea menos conocido a nivel usuario es el de las botnets: conjuntos de ordenadores infectados que siguen las instrucciones del dueño de la red, recopilando información de manera sistemática y almacenándola ordenadamente. De esta manera, es fácil identificar credenciales y otro tipo de información sensible.

El principal problema es que todas estas amenazas son a nivel global: no hay ninguna empresa que se libre de ella, sin importar si su core es o no tecnológico. ¿Hay un ordenador conectado a internet? ¿Se reciben emails? ¿Se dispone de página web? Ya hay riesgo.

Los ciberdelincuentes son cada vez más rápidos y durante las primeras 24 horas es muy difícil detectar al atacante. Por tanto, si el criminal es capaz de obtener información sensible, hacer negocio con ella y borrar su rastro, será casi imposible de localizar.

La respuesta de buguroo a esta problemática es bugThreats, nuestra herramienta de detección avanzada de amenazas en la red. Con más de 4500 servidores repartidos por todo el mundo, procesamos miles de gigas de información para poder anticiparnos a un ataque y dar la respuesta incluso antes de que este se haya producido.

Si quieres ver el vídeo con la ponencia, pulsa en la siguiente imagen:

pablodelariva

Volatility VS Citadel 1.3.4.5

Como analista forense y de malware siempre he sido un gran fan de Volatility, la ya archiconocida herramienta de análisis de memoria escrita en Python que sigue creciendo día a día. Por ese motivo, desde que hace algo más de un año vi el artículo de Michael Ligh en su blog sobre la extracción de las claves de cifrado de ZeuS siempre había querido probar eso mismo con otras familias de malware.

En este caso he elegido Citadel, que es una de las variantes de ZeuS que más guerra están dando desde la filtración del código fuente del mismo. En concreto la versión 1.3.4.5 que, aún no siendo la última, nos servirá de base para las siguientes versiones (Aunque se rumorea que la 1.3.5.1 podría ser la última que veamos) u otras familias.

Cuando juntamos Volatility con Yara, la potencia disponible para el procesamiento automático de malware se multiplica. En ambas cosas se basa zeusscan2, uno de los plugins resultantes del artículo comentado anteriormente. El mismo hace uso de reglas Yara sobre la memoria de una máquina infectada para detectar y acceder a las zonas de memoria susceptibles de contener la información que nos interesa extraer del binario. Para ello es necesario un exhaustivo análisis previo sobre la familia a “automatizar”, que en este caso, al tratarse de una variante de la familia ZeuS de sobra conocida y documentada, el trabajo se limitará a detectar las diferencias existentes con la misma.

De entrada sabemos que ZeuS 2.X contiene la siguiente información embebida en el binario:

  • URL de descarga inicial del fichero de configuración
  • Clave RC4 usada para descifrar el fichero de configuración
  • Información sobre la localización del binario y la configuración en la máquina infectada

Los dos primeros datos se encuentran en una zona del binario codificada mediante XOR con los bytes contenidos al comienzo de la última sección del fichero PE, mientras que la última es una zona cifrada mediante la clave RC4 con una estructura fija (En adelante nos referiremos a ello como el “objeto mágico”, para seguir la convención usada en el plugin para Volatility de ZeuS).

Nota: En el caso de ZeuS existe una segunda clave RC4 contenida en la última estructura comentada, pero dado que Citadel carece de ella, no es relevante para el objetivo del artículo.

De esta forma el flujo de extracción y procesamiento de los datos que buscamos sería algo como:

  1. Localización de la configuración embebida
  2. Decodificación de la misma mediante un XOR con los bytes situados al comienzo de la última sección del fichero PE
  3. Extracción de la URL de descarga de la configuración y la clave RC4
  4. Localización y decodificación del “objeto mágico”
  5. Extracción de los datos restantes

Ahora que sabemos la base sobre la que se asienta Citadel, podemos estudiar las diferencias para adaptar el plugin a la nueva familia. Las similitudes (a nivel de binario al menos) son más que las diferencias, así que una vez entendido lo anterior, los cambios no revisten demasiada complicación.

La principal diferencia viene marcada por el cifrado usado en los ficheros de configuración descargados, que pasa de RC4 a AES, pero para el “objeto mágico” se mantiene RC4. Dicha clave AES no está contenida en el binario como tal, sino que es calculada en tiempo de ejecución de la siguiente forma:

RC4(md5(BO_LOGIN_KEY))

La BO_LOGIN_KEY o binary key, se trata de una clave de 16 bytes en hexadecimal que sí está contenida en el binario y que además de para el cálculo de la clave AES se usa para la comunicación con su panel de control, por lo que, a la localización de la configuración embebida y el “objeto mágico”, hemos de añadir la de dicha clave “hardcodeada”.

Al flujo anterior habría que añadirle por otro lado:

  1. Localización de la BO_LOGIN_KEY
  2. Cálculo de la clave AES

Con todo esto, elegimos el siguiente código desensamblado para generar las nuevas reglas Yara que nos ayuden a localizar las variables comentadas en memoria:

8BEC                                  MOV EBP,ESP

83EC 0C                             SUB ESP,0C

8A82 00010000                  MOV AL,BYTE PTR DS:[EDX+100]

8845 FE                              MOV BYTE PTR SS:[EBP-2],AL

8A82 01010000                  MOV AL,BYTE PTR DS:[EDX+101]

8845 FD                             MOV BYTE PTR SS:[EBP-3],AL

8A82 02010000                  MOV AL,BYTE PTR DS:[EDX+102]

B9 801A1300                      MOV ECX,131A80                                                   ; BO_LOGIN_KEY

8845 FF                              MOV BYTE PTR SS:[EBP-1],AL

E8 BEF2FFFF                    CALL 0015BC16

———————————————————————————

56                                        PUSH ESI

BA 54050000                      MOV EDX,554                                                          ; Embedded configuration length

52                                        PUSH EDX

68 602A4000                       PUSH pyko.00402A60                                             ; Embedded configuration

50                                        PUSH EAX

E8 47E30100                      CALL pyko.004290C1

8B0D B4394300                 MOV ECX,DWORD PTR DS:[4339B4]

030D 943D4300                 ADD ECX,DWORD PTR DS:[433D94]

8BF2                                   MOV ESI,EDX

2BC8                                  SUB ECX,EAX

———————————————————————————

68 03010000                      PUSH 103

8D85 10FBFFFF               LEA EAX,[LOCAL.316]

50                                       PUSH EAX

8D85 FCFEFFFF              LEA EAX,[LOCAL.65]

50                                       PUSH EAX

E8 B4E20100                     CALL pyko.004290C1

B8 1C010000                     MOV EAX,11C

50                                       PUSH EAX

68 283C4300                     PUSH pyko.00433C28                                               ; Magic object

Una vez que llegamos al punto del flujo de procesamiento en el que se decodifica el “objeto mágico” nos encontramos con una estructura con un aspecto similar al siguiente:

Este objeto, al igual que pasaba con ZeuS 2.X, tiene una longitud fija en la mayoría de los casos y una estructura como la que sigue:

{‘_ZEUS_MAGIC’ : [ 0x11C, {

‘struct_size’ : [ 0x0, [‘unsigned int’]], \

‘guid’ : [ 0x4, [‘array’, 0x30, [‘unsigned short’]]], \

‘guid2′ : [ 0x7C, [‘array’, 0x10, [‘unsigned char’]]], \

‘exefile’ : [ 0x9C, [‘array’, 0x14, [‘unsigned char’]]], \

‘keyname’ : [ 0xEC, [‘array’, 0xA, [‘unsigned char’]]], \

‘value1′ : [ 0xF6, [‘array’, 0xA, [‘unsigned char’]]], \

‘value2′ : [ 0x100, [‘array’, 0xA, [‘unsigned char’]]], \

‘value3′ : [ 0x10A, [‘array’, 0xA, [‘unsigned char’]]], \

‘guid_xor_key’ : [ 0x114, [‘unsigned int’]], \

‘xorkey’ : [ 0x118, [‘unsigned int’]], \

}]}

Por lo tanto ya disponemos de todo lo que buscábamos:

Espero que este ejemplo ayude a ver un poco más claramente las posibilidades que nos ofrecen Yara y Volatility para el análisis y automatización de malware cuando trabajan en conjunto.

El plugin para la versión 1.3.4.5 lo podéis encontrar aquí. Michael Ligh lo ha integrado, además, con las versiones del plugin para ZeuS 1 y 2.X, por lo que en adelante estará disponible también en la rama principal de Volatility, aunque no activado por defecto; para su uso habrá que lanzar Volatility de la siguiente forma:

$ python vol.py –plugins=contrib/plugins/malware citadelscan1345 -f ….

En cuanto a la versión 1.3.5.1, el proceso a seguir sería similar excepto porque habría que localizar una nueva clave “hardcodeada” y tener en cuenta que el tamaño y estructura del “objeto mágico” cambia en cada muestra.

Feliz análisis!

Follow me on Twitter: @smvicente

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

El módulo de ZeuS/Spyeye para Android se hace mayor

En el último post relacionado con el módulo móvil usado por ZeuS y Spyeye para atacar el segundo factor de autenticación, se comentaba la escasa evolución que dicho tipo de muestras había tenido desde su aparición en septiembre de 2010. Pues bien, parecen habernos oído porque hoy se analizará lo que parece ser el primer paso en la evolución de una aplicación maliciosa que simplemente interceptaba y reenviaba SMS’s, hacia un bot con mayores posibilidades.

En primer lugar se puede apreciar, como se ha pasado de una innumerable lista de permisos solicitados a la hora de realizar la instalación, a una mucho más depurada con la clara intención de llamar menos la atención sobre la víctima:

Además añade nuevos permisos para realizar acciones como la instalación de aplicaciones o la lectura de la agenda del teléfono. También se ha pasado de una instalación y afectación genérica, a una específica de una determinada entidad:

La aplicación se hace pasar por un sistema de token bancario de la entidad objetivo. Esto, acompañado de las inyecciones correspondientes en el PC de la víctima, será de ayuda de cara a la ingeniería social necesaria para convencer a dicho usuario de instalarla y además, mantenerla. Y, aunque mantenga la capacidad de captura y reenvío masivo de SMS’s, puede filtrarlos definiéndolo en el fichero XML que usa a modo de configuración:

De cara a la serialización XML se hace uso de “Simple Framework” y, aparte de la nueva capacidad para leer y enviar datos de la agenda, la más interesante es que parece capaz de recibir una serie de comandos, convirtiéndolo en un bot:

En cuanto al panel de control, ha sufrido importantes mejoras y, mantiene la separación respecto de aquellos que controlan la infección del PC, posiblemente porque el módulo móvil se está “comercializando” de forma independiente:

Dentro del mismo dispone además de un builder para generar cada “apk” específica contra una determinada entidad:

Por lo tanto nos encontramos ante los primeros indicios de un desarrollo más serio, y una posible comercialización, detrás del hasta ahora “módulo bancario” de otros troyanos de escritorio; para buscar una cierta independencia a través de la incorporación de nuevas funcionalidades. Desde aquí deseamos que, el hasta ahora mal llamado “ZeuS para móviles”, no llegue a hacerse realidad y acabe convirtiéndose en eso mismo.

Follow me on Twitter: @smvicente

Análisis de malware en Android: Atacando al segundo factor de autenticación

Desde que en Septiembre de 2010 se detectara la primera muestra de ZeuS que realizaba un esquema de fraude de tipo MitMo (Man in the Mobile), se han apuntado al carro también Spyeye y últimamente Ice IX. En las dos primeras, el módulo móvil empleado para capturar las credenciales del segundo factor de autenticación basado en móvil partía de una misma base y, excepto sutiles diferencias, la evolución había sido escasa.

En el caso que nos ocupa, nos hemos hecho con una muestra para Android procedente de una inyección aparecida en la banca online de un usuario después de hacer login en ella, convenciéndolo de que instalara una aplicación de seguridad, usando para ello un mensaje como el siguiente:

#### informa: para la instalación de un programa de criptografía gratis en su teléfono, utilice la siguiente dirección http://#########.net/cripto.apk

Durante el análisis dinámico se observa cómo el mismo se instala haciéndose pasar por una solución de seguridad, y no intenta ocultarse en ningún momento:

La misma, únicamente muestra un código de activación para ser asociada presumiblemente con la cuenta de la entidad del usuario. Dicho código se trata del ID del teléfono (IMEI en GSM y el MEID o ESN para CDMA), como veremos más adelante.

La estructura del paquete APK es la siguiente:

El certificado autofirmado contiene la siguiente firma:

En el fichero XML (AndroidManifest.xml) que define los permisos necesarios por la aplicación para ejecutarse llaman la atención algunos de ellos como los siguientes:

Como se puede apreciar, requiere permiso para recibir y enviar SMS, así como consultar y modificar el estado del teléfono, entre otros.

La estructura de la aplicación Java es la siguiente:

En la clase “MainActivity” puede apreciarse el código empleado para mostrar el mensaje con el supuesto ID de activación:

La funcionalidad principal está reunida en la clase “SmsReceiver”, que es la encargada de interceptar y reenviar los SMS’s entrantes a un servidor controlado por el atacante. A continuación se muestran algunas de las variables usadas para almacenar la información capturada, así como el servidor donde se envía dicha información:

Una de las principales novedades respecto a versiones anteriores, es que la URL está codificada, aunque de una forma muy simple, de tal forma que eliminando los caracteres “q”, “-“ y “=” de la cadena, es posible obtenerla.

Como vemos, en todo este tiempo desde su primera aparición, la complejidad de este tipo de muestras apenas ha aumentado, lo que quiere decir que sigue siendo igual de efectivo y cumpliendo con el objetivo marcado por los defraudadores. Al final, si algo funciona, ¿Porqué cambiarlo?

———-

Follow me on Twitter: @smvicente

Page 1 of 212»