06 junio 2013

Análisis del módulo Meterpreter para Android

El otro día Jose Selvi publicaba en su blog un post sobre el nuevo módulo de Meterpreter para Android. Me pareció interesante echar una ojeada al fichero APK  para indagar un poco en su funcionamiento y saber como se ha generado.

Me puse manos a la obra con la distribución MobiSec (de la cual hablamos en este post) que incorpora herramientas para hacer ingeniería  inversa y análisis de código. Lo primero que hice fue extraer el AndroidManifest.xml, mediante el comando 'apktool -d meter.apk meter ', con el fin de analizar  los permisos que el APK requiere.
Los permisos, que se muestran en la captura abajo, son muy sospechosos y si estuviéramos analizando malware ya tendríamos una idea del potencial alcance e impacto del espécimen.



El siguiente paso es analizar el código fuente y para obtenerlo convertimos el código objeto DEX a código Java mediante el comando 'dex2jar'.

Luego, al abrir el fichero JAR con el decompilador 'jd-gui' incluido en MobiSec, vemos que solamente hay cuatro clases de las cuales sólo dos métodos contienen código relevante. La primera es el el método reverseTCP() dentro de la clase MainActivity que se encarga de crear el Socket para establecer la conexión.



Una vez la conexión está establecida se llama al segundo método relevante que está dentro de la clase LoadStage.



En el código fuente se puede ver que se generan una serie de ficheros JAR con nombre aleatorios para luego más tarde ejecutarlos mediante el método 'DexClassLoader'.

El código por si es simple y sencillo por lo que no es sospechoso en el sentido de que no hace ninguna llamada a métodos para acceder a la cámara, al registro de llamadas, a los contactos, etc. Con esto quiero decir que un análisis de código estático no es suficiente ya que estamos limitados en la visibilidad por lo que se debe complementar con un análisis de comportamiento para tener una idea global.

Sin entrar al detalle del código podemos ver que los ficheros JAR se generan usando los streams de datos de la conexión. Esto es importante porque si al ejecutar el código no se establece una conexión (ej: desactivamos el listener de Metasploit) no hay ningún fichero adicional a analizar, lo que sin duda abre muchas puertas a crear código que solo se ejecute en ciertas condiciones.

El siguiente paso es ejecutar el malware y ver qué ficheros se crean para poder descargarlo y analizarlos.  Para ello, hacemos uso de la herramienta androidAuditTools que aunque no está instalada en MobiSec su instalación es trivial ya que se trata de scripts in Ruby.  androidAuditTools permite hacer una análisis diferencial del sistema de ficheros del dispositivo Android antes y después de la ejecución, lo que pemite ver que ficheros/directorios se han creado o modificado.


Claramente podemos ver que cuando ejecutamos y se realiza la conexión mediante la 'reverse shell' dos nuevos ficheros JAR (gkgpchuxlidmovddtsnf.jar y  lucptaepfivadtgsiqyz.jar)  se han creado junto con sus correspondientes DEX files.

De esta manera tan sencilla sabemos exactamente los ficheros sobre los que tenemos que continuar el análisis. Los ficheros los podemos descargar a MobiSec mediante 'adb pull'.
El fichero importante es el segundo (lucptaepfivadtgsiqyz.jar) y éste contiene todo el código core del módulo. Por ejemplo, podemos ver la clase y método que se encarga de inicializar la cámara para tomar fotos.



No voy a entrar a analizar el código ya que a groso modo las funcionalidades del módulo las podemos intuir.

Este módulo para meterpreter me parece muy interesante por la manera que funciona desde un punto de vista de sencillez ya que el código del APK original no contiene nada que lo delate a priori. Sería muy fácil incluir éste código a modo de 'backdoor' sin levantar muchas sospechas y solamente generar los ficheros .JAR bajo ciertas condiciones, lo que haría su análisis mucho más complicado al no tener todas las piezas del puzzle. Si a esto le unimos el limitar los permisos en AndroidManifest.xml (por ejemplo reducirlo a los permisos de INTERNET)  podríamos tener el cóctel perfecto.

Artículo cortesía de Angel Alonso Parrizas

5 comments :

juan vazquez dijo...

Bun articulo Angel! Solo comentar que si estais interesados en revisar/modificar el codigo fuente, la forma mas sencilla es acudir al directorio external/source/javapayload/androidpayload :)

todb dijo...

Broken link, you want this instead: http://www.pentester.es/2013/05/nuevo-meterpreter-para-android.html


-todb

Angel Alonso Parrizas dijo...

Gracias Juan.

Le echare una ojeada al codigo para ver que se puede trastear :)

Angel.

ravasquezgt dijo...

Interesante lo que sacas al analizar aplicaciones, que por su "fin" no deberian tener acceso a permisos tal como lo expones, si haces un analisis estadistico estoy muy seguro que un 75% de personas no revisan los permisos que las aplicaciones solicitan al ser instaladas, excelente articulo.

raul dijo...

Ya actualize mi metasploit pero no me sale la opcion de android , alguien sabe que se deba.