forensic

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

Hard and Soft Links in Windows 7

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

Enlaces duros (Hard Links)

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

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

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

Enlaces simbólicos (Soft Links)

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

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

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

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

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

Created By AccessData® FTK® Imager 3.0.1.1467 110406

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

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

Information for C:tmplinks_w7:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Análisis binarios con Mandiant Redline

Bueno, todos sabemos que hay en el mercado varias aplicaciones de nuestros queridos “Mandiant”, no lo digo con sarcasmos porque hay varias aplicaciones que me gustan.

Y bien, sacaron a la luz una aplicación llamada Redline, lo que hace es analizar la memoria, como si fuera “Volatility” pero con GUI.

El trabajo de Redline consiste en analizar la memoria y valorándola mostrar qué proceso tiene más posibilidad de ser malware y cuál menos, contando puntos MRI (Malware Risk Index), pues nada vamos a ver qué tal funciona.

La prueba fue realizada en una maquina infectada con Banker, según Kaspersky – Trojan-Banker.Win32.Banker.mq.

La maquina es de 2 cores y con 1GB de RAM. En más adelante podéis haceros una idea sobre las necesidades de la aplicación.

Bueno, descargamos y vemos que es un .msi, empezamos bien, por todos los santos, nos pide .NET 4.0, bueno que remedio, descargamos, instalamos.

Se instala en un periquete, algo bueno.

Al instalar nos muestra varias opciones de análisis, muy interesante tiene la opción de análisis sobre un “Saved memory File”, que parece a Volatility, elegí el análisis de la maquina local “Analyzing this Computer“. Pinchando ahí vemos que nos permite analizar muchas cositas interesantes como por ejemplo: Hooks, Drivers con sus Exports e Imports, Procesos con sus actividades, etc.

No vamos a jugar con tonterías y pinchamos en “Full Audit” y OK.

Es muy curioso, pero con las características de mi maquina, Redline acabo el análisis en unos 25-30 minutos, curioso la memoria casi no la toca, pero del procesador tira pero que muy bien. Vamos que con un 8008 vais listos =)

Bueno ya tenemos el análisis acabo, vamos a echar un vistazo. Tenemos una lista de procesos, algunos se marcan en rojo, pasos a seguir para el análisis, interesante, seguiremos los pasos.

Un review de los procesos con su valoración, pinchando en cada uno de ellos nos mostrara info más detallada del veredicto.

Vamos a ver porqué están marcados en rojo, pinchamos en uno y nos muestra los factores positivos y negativos por los que valora los procesos. Cuanto más factores negativos mas posibilidad a que lo marque en rojo como sospechoso, bueno buscamos un malware, nos interesan negativos. No puede ser ¡! nos marca un proceso svchost en rojo, porque, por solo 2 factores (indexación de ficheros index.dat).

Y los demás 3 svchost ni si quiera tienen factores negativos, 100% positivo, sin embargo los marca en rojo.

Según mi análisis, mi Banker abrió un iexplorer bajo svchost pero el svchost ni si quiera ha sido detectado, incluso mi iexplorer tenía una conexión establecida con una IP americana con el puerto 80 y por otro lado escuchaba en el puerto 1308 por UDP, pero solo marcó mi iexplorer en 50% sospechoso. El proceso oswin32.exe es nuestro Banker, y también lo marca en gris, jejejeje.

El siguiente paso del análisis que nos indica Redline es verificar las conexiones, vamos a ver, jejejeje mirad, mi iexplorer con sus conexiones pero esta en 50% de amenaza. También con doble clic sobre la conexión os llevara al proceso.

Podemos elegir alguno de los filtros de las conexiones: puertos en escucha, conexiones establecidas o todos.

Bueno, seguimos, el siguiente paso es un Review de las secciones de memoria y DLLs, un punto bastante interesante, hay varios filtros para ver qué es lo que nos interesa, por ejemplo: Mostrar secciones nombradas que se utilizan por menos de 4 procesos, o las mismas secciones pero las que se marcaron en rojo como desconfiados, otro filtros también bastante interesante es el que muestra las secciones de memoria inyectadas.

También una comodidad de Windows, haciendo doble click nos lleva al proceso, si pulsamos sobre las inyecciones que aparecen me lleva al proceso del propio Mandiant Redline :) Es decir, no confía ni si quiera en las inyecciones suyas, jajajajaja

Otro paso que nos dice a seguir Redline es revisar los handles desconfiados.

Aquí también hay filtros de “solo desconfiados” o todos.

Bueno, el siguiente paso son los Hooks, tenemos varios filtros de diferentes tipos de hooks, parece que confía en todos :)

Nada interesante, seguimos.

Y por fin nuestro último paso de nuestro análisis es “Drivers and Devices”, aquí no tenemos ningún filtro, es decir, todo a mano, es una información bastante interesante que nos proporciona. Pinchando en cada uno de ellos nos muestra la info completa sobre él, hasta las funciones que tiene, que importa y que exporta, strings, certificados, etc.

Bueno, hemos seguido los pasos, y parece que no nos ayudaron en nada, claro que si hubiéramos analizado alguno de los pasos anteriores más a fondo seguramente hubiéramos encontrado algo interesante.

Más cositas interesantes, podemos ver secciones de memoria, strings, puertos utilizados o handles de todo tipo por cada proceso, esto ya me gusta más.

Muy interesante en la parte de Detailed Sections tenemos todas las secciones del proceso, a la derecha podremos hacer búsquedas en cada uno de ellos y ver qué es lo que exporta, importa, etc.

Otra cosita muy interesante, los strings de cada proceso, podemos buscar patrones por ahí, por ejemplo yo encontré una keyword de Banco Popular :)

Otra cosa que vi, la pestaña Host, proporciona la información completa sobre los procesos, punto muy interesante son procesos en jerarquía, conexiones establecidas, drivers, hooks, información detallada del equipo y el SO, vamos lo mismo pero en genérico.

Algunos de los puntos más positivos que encontré son: la aplicacion nos permite crear un Agente portable directamente desde el menú de la aplicación, muy útil para un análisis externo y sin necesidad de instalarlo, permite guardar el análisis y seguir con el mismo en otro momento.

Bueno, resumiendo, la aplicación no está nada mal, pero es como utilizar Volatility con GUI o SysInternals TODO EN 1.

La interfaz gráfica es muy amigable y fácil de manejar. Para un análisis yo no lo aconsejaría para una persona que se basara solo en los veredictos de la aplicación ya que Redline da unos Falsos positivos brutales. Un claro ejemplo con los svchost, aparte marca su proceso también como sospechoso en un 24% :)

Podría mejorar el análisis, si mi Banker hubiera cerrado la conexión antes de que lanzara analizar, las conexiones no hubieran aparecido y mi iexplorer no lo hubiera marcado como 50% de sospechoso, pero bueno por otra parte no olvidemos que es un análisis sobre la memoria.

La veo útil en algunas ocasiones y cómoda para utilizar. Sin embargo la interfaz algunas veces en mi equipo tarda en reaccionar, parece que le faltan cores :)

Estoy seguro que la próxima versión será mucho más currada y arreglaran los cálculos de los factores positivo, negativos y de los veredictos.

A disfrutar.

Cómo ejecutar análisis estático de aplicaciones (apk) en Android

Hoy vamos a tratar un tema que está ganando popularidad en el ámbito del análisis estático de código, se trata de la auditoría de aplicaciones en Android. Como muchos sabéis una aplicación en Android está programada en JAVA por lo que se podría pensar (equivocadamente) que en esencia el análisis de código es un análisis tradicional de JAVA. Esto no es así ya que han de tenerse en cuenta tanto la arquitectura de Android (Intents, Broadcast, Estados, etc) como la API SDK de interacción con los dispositivos (funciones de GPS, SMS, 3G, Escritura en SD, etc). Es decir, cambian dos aspectos fundamentales respecto al análisis tradicional de JAVA: los sinks y el dataflow.

El enfoque en el presente artículo no es hablar del análisis en sí (lo haremos próximamente) sino sobre cómo poder realizarlo sin tener las fuentes originales. Como es bien sabido, muy pocas aplicaciones en el Market oficial son OpenSource, por lo que el código no está disponible. Sin embargo si que podemos acceder a los ficheros apk, ya que son copiados a los dispositivos en la ruta “/data/apk“. En esta ruta se copian todas las aplicaciones que tenga instaladas el dispositivo (también las que se compran, antes del refund como bien sabe @hidark ;) ).

Tenemos por tanto acceso a la aplicación apk, ¿de qué nos sirve? la extensión apk es una variante de jar, por lo que podemos extraerla con la genial herramienta apktool. Para ello seguiremos los siguientes pasos:

1. Obtención del fichero AndroidManifest.xml
Para obtener este fichero a través del apk utilizamos la herramienta apktool con la opción b.
Este fichero contiene información esencial acerca de la aplicación. Para nuestra tarea la parte que nos interesa es la referente a los permisos que requiere, contenidos en el apartado uses-permission. Para una completa comprensión recomiendo leer la amplia documentación oficial al respecto.

2. Adquirir el fichero jar
Para ello nos servimos de la herramienta dex2jar. El funcionamiento de esta herramienta es el siguiente: traduce el fichero .dex (ejecutable de dalvik byetcode) a un fichero jar corriente.

3. Extraer el fichero jar
Es tan sencillo como utilizar un descompresor normal y corriente.

4. Acceso al código fuente
Al seguir el paso tres tendremos un directorio con ficheros .class de JAVA, los cúales pueden traducirse en sus .java correspondientes a través de herramientas como JAD, o incluso visualizarse directamente mediante herramientas como JD-GUI.

Hay que destacar que al hacer la decompilación se pierde mucha información, como nombre de variables, lo que dificulta el análisis manual del código. Normalmente se suele empezar por identificar ciertas funciones susceptibles de mal uso (funciones sink) y seguir el dataflow manualmente a través de entornos de desarrollo (Eclipse, NetBeans, etc).

Como hacer muchas veces lo mismo sin automatizar es pecado he preparado un pequeño script en bash que hace todo el proceso de manera automática, esto es:

1. Se definen en una variable del script las funciones que queremos localizar en el código JAVA resultante.
2. Se ejecuta el script, que recibe dos parámetros: el fichero apk y directorio de salida
3. Decompila el apk, extrae los permisos y ejecuta el grep análisis, dejando la salida en el fichero output.txt. Adicionalmente deja el código decompilado en el directorio de salida para su posterior revisión manual.

El script precisa logicamente tener instalado apktook, dex2jar y jad con los ejecutables en el path.
Está probado en Fedora, si hay algún problema por favor notificármelo a dmedianero@buguroo.com
Podéis descargarlo desde el siguiente enlace:

http://pastebin.com/SBu0bfky

Un saludo !!

pySIM-Reader: Accediendo a una tarjeta SIM

La herramienta de la que vamos a hablar hoy, hace unos años tenía más sentido que ahora, ya que con los nuevos móviles y smartphones la tarjeta SIM ha quedado relegada a un segundo plano, en la actualidad prácticamente solo sirve de interacción con el operador. Ya podréis haceros a la idea de que hablamos de una herramienta que sirve para explorar la tarjeta SIM de un móvil en busca de datos. Para ello utilizaremos el software escrito en Python llamado pySIM.

Para ello necesitamos primero el hardware, en este caso hay dos posibilidades, una de ellas es la que comenta la web y otra encontrada por mí de pura suerte. El software del que hablamos se conecta a la tarjeta a través de un dispositivo por un puerto serial, pues bien, en la ya conocida web de DealExtreme encontramos un lector de tarjetas SIM por menos de 3€ que para funcionar necesita un driver USB-2-Serial (windows Mac OS X) y que funciona correctamente con pySIM-Reader. Y la otra opción más divertida y la que en un principio hice yo es comprarlo y montarlo yo mismo, es más caro, pero la satisfacción de hacerlo y que funcione para algunos es más gratificante.

Por otro lado para hacerlo funcionar depende del sistema operativo, en Windows podemos descargar el ejecutable de aquí, para Linux y Mac OS X necesitamos tener instalado PythonpySerial (librería para interactuar con un puerto serial [COM] y wxPhyton (librerías de Python para generar entornos gráficos), ademas del código del programa. Para que funcione correctamente en Mac OS X os recomiendo MacPort con Python 2.6 y instalar wxPhyton y pySerial desde MacPort también, a mi de otra forma me dio muchos problemas.

Interfaz pySIM

Interfaz pySIM

 

Para hacerlo funcionar puedes conectarlo a través de un conversor USB-Serial y al abrir el pySIM-Reader te pedirá que le digas el dispositivo, en Mac OS X y Linux os puede pasar que el dispositivo creado no sea el que aparece en la ventana del programa, mi solución fué hacer un ln entre el dispositivo real creado en /dev/ y el que te reconoce el programa, si os contáis directamente por cable serie puede que no tengáis este problema.

Creando el link al dispositivo requerido

Creando el link al dispositivo requerido

 El programa tiene un pero muy grande y de cierto modo es lógico, y es que para extraer los datos de la SIM hay que facilitar el código SIM, por lo que solo podemos extraer información de nuestra SIM o en el caso de que tenga deshabitado el PIN, pero evidentemente al ser el software OpenSource podemos acceder al código y entender a un bajo nivel como accede al chip.

Informacion incial del programa (izquierda) y de la SIM (derecha)

Informacion incial del programa (izquierda) y de la SIM (derecha)

 

El software permite entre otras cosas:

- Agenda:

  • Mostrar Agenda
  • Modificar Agenda
  • Mostrar última llamada
  • Hacer/Restaurar backup de Agenda

- SMS:

  • Mostrar SMS
  • Hacer/Restaurar backup de SMS

- SIM:

  • Mostrar información de la SIM (no necesita PIN)
  • Cambiar el PIN
  • Habilitar/Deshabilitar el PIN
Petición de código PIN

Petición de código PIN

 

El programa accede a la SIM de una forma más o menos sencilla de entender, la SIM funciona como una memoria de tamaño fijo (64K por ejemplo) la cual está dividida en sectores o partes y cada parte tiene habilitada varios espacios de memoria fijos en los que se almacena la información. De esta forma el programa, de acuerdo con la RFC de la arquitectura de una tarjeta SIM, sabe que si accede a la posición X,N accede por ejemplo a un registro que guarda un número de teléfono y si accede a X,N+1 accedería a el número de teléfono siguiente almacenado. Podemos decir que está estructurada en una especie de matriz.

pySIM recorriendo la estructura interna de la SIM

pySIM recorriendo la estructura interna de la SIM

Para poder acceder a esta matriz hay que conocer el PIN, ya que entre los datos y la petición del teléfono o el lector existe un microprocesador que es el que se encarga de comunicar ambos lados.
Este programa con sus limitaciones puede ser interesante si por ejemplo lo usamos para hacer un forense a un móvil de empresa del que conocemos el código PIN.

Os enseño una foto del resultado una vez soldado:

SIM-Reader montado (clic para ampliar)

SIM-Reader montado

 

Page 2 of 4«1234»