Análisis del módulo Meterpreter para Android

  • 1 Respuestas
  • 2497 Vistas

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Kodeinfect

  • *
  • Ex-Staff
  • *****
  • Mensajes: 325
  • Actividad:
    0%
  • Reputación 0
    • Ver Perfil
    • Kodeinfect's Blog

Análisis del módulo Meterpreter para Android

  • en: Julio 10, 2013, 11:22:20 am

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.

Fuente: Security By Default
« Última modificación: Octubre 24, 2013, 10:18:46 am por Expermicid »

Desconectado ZanGetsu

  • *
  • Ex-Staff
  • *****
  • Mensajes: 329
  • Actividad:
    0%
  • Country: 00
  • Reputación 0
  • I ZanGetsu
  • Skype: thenicox
  • Twitter: black_zangetsu
    • Ver Perfil

Re:Análisis del módulo Meterpreter para Android

  • en: Julio 10, 2013, 01:11:19 pm
muy bueno gracias :D

 

Exploit para Apache Struts (ejecución remota de comandos) [Tomcat]|CVE2017-5638

Iniciado por Eschiclers

Respuestas: 9
Vistas: 8390
Último mensaje Marzo 23, 2017, 03:57:38 pm
por zoro248
Gcat - Python Backdoor Usando Gmail para Mando y Control

Iniciado por R3v0lve

Respuestas: 2
Vistas: 6566
Último mensaje Noviembre 18, 2015, 08:52:40 pm
por Stuxnet
Routerpwn, un framework para explotar dispositivos embebidos desde tu celular

Iniciado por hkm

Respuestas: 2
Vistas: 3928
Último mensaje Agosto 01, 2011, 11:45:43 pm
por JaAViEr
Nuevo Exploit 0day para Internet Explorer 7, 8, 9 en Windows XP, Vista y 7

Iniciado por CalebBucker

Respuestas: 1
Vistas: 4116
Último mensaje Septiembre 17, 2012, 04:49:25 pm
por Slore
SAPYTO – Framework para realizar Penetration Tests sobre sistemas SAP

Iniciado por ZanGetsu

Respuestas: 1
Vistas: 3093
Último mensaje Mayo 20, 2013, 08:49:26 pm
por StuXn3t