Creando un entorno de análisis de aplicaciones Android

 A estas alturas todos sabemos que la plataforma Android es un auténtico caldo de cultivo para el malware por diversos motivos:

• Escasos controles en el momento de la publicación de aplicaciones en Google Play
• Ventanas de tiempo entre publicación de malware y su eliminación que permiten obtener un beneficio de estas actividades ilícitas
• Facilidad de distribución de aplicaciones a través de métodos alternativos a los canales oficiales
• Necesidad de una mayor granularidad en los permisos
• Un muy largo etcétera...

Pero de esta situación también podemos sacar algo positivo, donde reina el malware nosotros tenemos campo donde investigar, así que vamos a dedicar unas líneas a construir un entorno de análisis para jugar con el malware además de con todo tipo de aplicaciones Android.

Descripción del entorno

Con la idea de tener controlado el comportamiento de la aplicación a analizar vamos a crear un entorno repetible (a través de backups), en un dispositivo sobre el que tengamos pleno control (debe estar rooteado) y enrutando las comunicaciones que genere por una máquina que nos permita su análisis (utilizando iptables, wireshark y burp).

De forma gráfica el escenario que vamos a recrear es el siguiente:


Y para crear este entorno partiremos de los siguiente pre-requisitos:

• Tener un dispositivo rooteado donde hacer las pruebas (tenéis más documentación en los foros xda-developers en inglés y htcmania en español), y aunque estoy seguro de que esto sobra decirlo, si lo vais a utilizar para el análisis de malware no utilicéis vuestros dispositivo de uso diario.
• Instalación del Android SDK (tenéis más documentación en la Web oficial de Android ).
• Red Wifi a la que conectar el dispositivo.
• Disponer de una máquina con iptables, Wireshark y Burp instalados. En el ejemplo usaré una distribución Kali.

Empecemos con la configuración del entorno.

Preparando la distribución Kali

Como vamos a enrutar el tráfico del dispositivo a la máquina Kali, lo primero será configurarla:

• Iniciamos y configuramos Burp
• En Proxy > Options, editamos el Proxy que está escuchando para que atienda a todas las interfaces:

• Actúe de forma invisible:

• Genere un certificado de CA por host:

• Exportamos el certificado de la CA de Burp codificado en DER, para ello podemos configurar el cliente Web de Kali para que pase por el proxy y acceder a una página Web por HTTPS:

• Configuramos las reglas de pre-routing con iptables que nos permitirán analizar el tráfico HTTP/HTTPS en Burp:
• echo 1 > /proc/sys/net/ipv4/ip_forward
• iptables -F
• iptables -t nat -F
• iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
• iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080
• Iniciamos Wireshark y le ponemos a la escucha en la interfaz de red por la que entre el tráfico del dispositivo

En este momento ya tenemos preparado el entorno de la máquina Kali, continuemos con el dispositivo.

Preparando el dispositivo Android

Antes de realizar el backup, vamos a hacer algunos ajustes previos en el dispositivo Android:

• Instalamos la aplicación ProxyDroid para enrutar correctamente el tráfico HTTPS a nuestra máquina de análisis de comunicaciones y la configuramos del siguiente modo:

• Importamos el certificado de la CA que habíamos exportado desde Burp, para ello lo copiamos a la SD (o memoria interna del dispositivo) y accedemos a Ajustes > Seguridad > Almacenamiento de credenciales > Instalar desde la tarjeta SD (o alamcenamiento). Tener en cuenta que estas opciones de menú pueden variar según la versión instalada de Android.
• Configuramos la Wifi en el dispositivo y establecemos como puerta de enlace la dirección IP de la máquina Kali

Con esto ya tenemos el dispositivo listo para su castigo, así que vamos a realizar un backup que poder restaurar finalizados nuestros análisis. Tenemos las siguientes opciones:

• Nandroid, os dejo un enlace a un tutorial.
• Herramienta adb del Android SDK:
• Para hacer backup:   adb backup -apk -shared -all -system -f C:\estado0.ab
• Para hacer restore:    adb restore C:\estado0.ab

Ya tenemos preparada la máquina Kali para capturar el tráfico y el entorno sobre el que vamos a realizar las pruebas, de modo que sólo queda activar la aplicación ProxyDroid en el dispositivo:


Y empezaremos a capturar el tráfico del dispositivo en el Wireshark y Burp de la máquina Kali:


Algunas herramientas útiles

Encontraréis de gran utilidad para la realización del análisis las siguientes herramientas:

• adb (incluida en el Android SDK)
• dex2jar
• jd-gui
• apk toolkit

Virtualizando el laboratorario

Si no disponéis de un dispositivo físico donde probar esta será vuestra mejor opción, pero incluso teniéndolo merece la pena virtualizar el laboratorio ya que os permitirá una mayor agilidad en la restauración del sistema además de facilitaros obtener el root.

Recuerdo los pasos para crear la máquina virtual y os dejo algunas indicaciones adicionales:

• Instalación y configuración de VM Android 4.3 x86 en VirtualBox:

• Rooteo completo de la VM: enlace.
• Instalar una herramienta para la gestión de la ejecución con privilegios de root, por ejemplo SuperSU
• Instalar y configurar ProxyDroid y el certificado de Burp como se describía anteriormente
• Instalar un servidor FTP en la máquina Kali de análisis, por ejemplo vsftpd
• Instalar un cliente FTP en el dispositivo virtual, por ejemplo AndFTP. Configurar un perfil con el servidor de la máquina de análisis
• Crearemos una carpeta para el contenido de nuestros análisis en la SD, para ello accedemos a la terminal presionando ALT+F1 y hacemos un mkdir /sdcard/analisis
• Apagar la VM del dispositivo Android y guardar una instantánea que poder restaurar finalizado el análisis.

Finalmente utilizaremos Kali como máquina de análisis de comunicaciones y de la aplicación en sí.

Os dejo algunos trucos interesantes para manejarnos con el entorno virtualizado:

• Para controlar correctamente el ratón dentro de la VM seleccionar la opción Máquina > Inhabilitar integración del ratón
• Podéis acceder a la terminal con ALT+F1. En este modo echaréis en falta más de un símbolo, aquí tenéis el juego que utiliza.
• Podéis volver a la interfaz gráfica con ALT+F7
• Si analizáis una aplicación que gire la pantalla y cuando volváis a acceder a la HOME no se recupera la vista en horizontal, presionar 2 veces seguidas F9

• Si se queda la pantalla en negro (se ha bloqueado el dispositivo), seleccionar la opción Máquina > Apagado ACPI y se desbloqueará:

Recogiendo información

El primer paso es arrancar en la máquina Kali las aplicaciones Wireshark y Burp para inspeccionar las comunicaciones. También activamos ProxyDroid en el dispositivo virtual.

Lo siguiente que vamos a hacer es crear en el dispositivo un fichero que nos sirva de hito histórico para detectar más adelante variaciones con el comando find, de modo que presionamos ALT+F1 y escribimos touch /sdcard/analisis/instante.

Para continuar con el artículo he escogido la aplicación SMS, whatsapp, LLAMADA - SPY a la cual sólo le falta auto-declararse troyano:


Instalamos e iniciamos la aplicación. Si seguimos el proceso que indica nos pedirá que habilitemos la instalación desde orígenes desconocidos. Vemos que la cosa se anima en cuanto nos refleja todos los permisos que pide el segundo APK que quiere descargar:


Como estamos dentro de la VM podemos aceptar sin miedo, y si continuamos con el proceso que propone llegaremos a un punto en el que nos pide la dirección de correo sobre la que queremos vincular la actividad espía..., proceso que indica siempre que no hay conexión a internet, aunque sí que la haya. Sospechoso, ¿verdad?.

Finalizado el proceso anterior reiniciamos el dispositivo (para que se agarre bien el troyano) y seguimos nuestra tarea de recogida de información lanzando algunos comandos desde la terminal, para ello presionamos ALT+F1 y obtenemos algunos datos:


 En resumen:

• Obtenemos el APK y todos los datos de la aplicación para analizarlos
• Obtenemos todos los ficheros modificados a partir de la fecha de creación del fichero creado antes de iniciar el análisis
• Obtenemos los procesos y conexiones activas del dispositivo

De vuelta al entorno gráfico (ALT+F7) podemos utilizar AndFTP para enviar toda la información recogida en el directorio /sdcard/analisis a la máquina Kali donde podremos analizarla con más detalle.


Además desde Burp podremos ver que la aplicación ha generado dos peticiones al dominio spytomobile.com:


Y desde Wireshark con File > Export objects > HTTP podremos exportar el APK descargado para su posterior análisis:


Analizando la información recuperada

Al final de la entrega anterior recuperamos cierta información que nos puede ser útil durante el resto del análisis, por ejemplo si revisamos el listado de procesos que realizamos al reiniciar el sistema tras instalar la aplicación nos encontraremos con que una nueva aplicación se ha iniciado automáticamente:


Por otro lado y a través de los ficheros modificados podemos ver los APKs instalados y como se ha descargado en la SD un paquete light.apk:


Si generamos un resumen con MD5 a los paquetes de spy2mobile y light veremos que se tratan del mismo fichero:


 Y como vimos en las trazas de las comunicaciones del artículo anterior podemos deducir el proceso que ha seguido el troyano: a través de la aplicación com.supportcaptcha se realizó la descarga en la SD del paquete light.apk, que posteriormente se instaló bajo el nombre com.spy2mobile.light y el cual se inicia con el arranque del dispositivo.

Pero continuemos obteniendo información con otras herramientas.

apktoolkit

Nos sirve para extraer los recursos de la aplicación. Para usarla es necesario copiar el APK que queremos analizar en el directorio /usr/share/apktoolkit/, en nuestro caso vamos a centrarnos en el troyano que se descargó vía Internet una vez instalada la aplicación:


El resultado de esta aplicación nos permitirá inspeccionar el código smali (código ensamblador para el formato dex) sobre el que podremos localizar comportamientos anómalos a través de comandos en el sistema:



Además utilizando el explorador del sistema de ficheros podremos revisar los recursos recuperados del APK donde encontraremos las imágenes, definición de pantallas, textos, ficheros incluidos en la aplicación


Dentro de los recursos que encontraremos cabe destacar el fichero AndroidManifest.xml. donde se definen versiones, permisos, servicios, actividades... información esencial para que Android tenga conocimiento de cuándo y cómo ejecutar los componentes de la aplicación.
En el caso de la aplicación que estamos analizando podemos ver como nos hacen un all-in de permisos:


En ese mismo fichero también se reflejarán los broadcast receivers:


Como podemos ver la aplicación se declara a la escucha de llamadas salientes y del arranque del dispositivo. Cualquiera de estas dos acciones desencadenará que la clase com.source.MainReceiver gestione el evento, dato que en términos del arranque ya habíamos identificar al listar los procesos al inicio del sistema.

Herramientas d2j

Esta herramienta se utiliza de forma habitual para convertir un fichero en formato dex (los APK) en un fichero en formato jar:


Una vez realizado el paso anterior es posible decompilar el contenido del jar con las herramientas jd-gui o jad.
Es interesante comentar también que este conjunto de herramientas dispone de otras utilidades que nos permitirán:

- Modificar el contenido de un APK a través de código Jasmin.
No profundizo en esta opción ya que se escapa del objetivo del artículo, aunque podéis imaginar el uso de esta herramienta para modificar aplicaciones y publicarlas en mercados alternativos.

- Des-ofuscar código bajo un criterio establecido de forma manual.
Vamos a ver esta opción más en detalle. Primero abrimos el fichero jar generado con jd-gui:


Si exploramos las clases encontraremos que el código que nos interesa se encuentra ofuscado:


El siguiente paso será extraer los nombres de paquetes, clases, métodos y atributos para editarlos:


Modificamos su contenido para hacerlo más legible (aunque con sólo extraerlos se generarán nombres aleatorios que serán algo más sencillos de identificar que los ofuscados):



A continuación insertaremos estos nombres dentro del fichero jar y volveremos a abrirlo desde jd-gui:


El resultado que veremos será el siguiente:


sqlitebrowser

Con esta herramienta podremos ver de forma gráfica las bases de datos de tipo SQLite, de modo que lo primero que haremos será instalar el paquete en la máquina de análisis con:

apt-get install sqlitebrowser

Una vez instalada la herramienta la encontraremos en Applications > Programming > SQLite Database Browser.
El siguiente paso es disponer de la base de datos que queremos analizar, de modo que continuando con el ejemplo que teníamos entre manos vamos a intentar localizar su base de datos.

En Android lo habitual es que para gestionar las bases de datos se cree una clase que herede de la clase SQLiteOpenHelper, de modo que vamos a intentar localizar esta cadena en el código:


Tenemos una clase ganadora: com.source.b.f. Esta misma búsqueda la podemos realizar desde jd-gui para ver el código de forma más clara:


Si curioseamos esa clase nos encontraremos el siguiente método:


De modo que todo apunta a que tendremos una base de datos con nombre system.bd, la descargamos desde su directorio por defecto (/data/data/com.spy2mobile.light/databases/) y la abrimos con sqlitebrowser:


Y aunque ya sabíamos desde el principio que estábamos analizando una aplicación para espiar el uso del dispositivo, confirmamos a través de la base de datos las múltiples tablas preparadas para capturar la información del usuario.

Conclusiones

Como veis tenemos a nuestro alcance múltiples herramientas que nos permitirán transformar la aplicación para que la podamos analizar desde distintas perspectivas, haciendo que los resultados del proceso de análisis se reduzcan a una cuestión de habilidad, experiencia y el tiempo que le queramos/podamos dedicar.

Finalmente os dejo una captura de la pinta que tiene el panel de administración Web del software espía que al final he podido configurar desde un dispositivo físico:


Artículo cortesía de Miguel Ángel García
Fuente: securitybydefault

Saludos

Muy buen articulo Expermicid, gracias por aportarlo!