Este documento describe cómo troyanizar una aplicación Android legítima insertando código malicioso. Se generó una aplicación maliciosa usando msfvenom y luego se descompiló la aplicación legítima y la maliciosa usando apktool. El código malicioso se copió a la aplicación legítima y se modificó el manifiesto y el código fuente para ejecutarlo. Finalmente, se recompiló la aplicación legítima ahora troyanizada y se probó infectando un dispositivo Android virtual.
7. Los archivos dex son los que contienen el código Java compilado y preparado para su ejecución en
dispositivos Android. Podemos referirnos a ellos como los Ejecutables Dalvik ya que pueden ser
interpretados por la máquina virtual Dalvik
8.
9. Herramientas utilizadas
MSFVENOM
Herramienta que combina las herramientas de
Metasploit msfpayload y msfencode en una única
instancia del Framework. Con ella crearemos la
apk maliciosa que vamos a inyectar a la app
legítima.
Mas información: https://www.offensive-
security.com/metasploit-
unleashed/msfvenom/
APKTOOL
Herramienta de ingeniería inversa para
aplicaciones Android de código fuente abierto.
Con ella podemos decompilar apps y volver a
compilarlas con las modificaciones que
realicemos.
Podemos descargar esta herramienta desde
aquí: https://ibotpeaches.github.io/Apktool/
Utlizaremos las distribuciones Kali y AndroL4b
11. Podríamos utilizar esta Apk directamente para
infectar un Smartphone Android, pero resulta muy
poco “invisible” de cara a la víctima.
Con apktool y una serie de modificaciones
conseguiremos inyectar el código malicioso de
esta apk en otra legítima.
13. Vamos a descargar la que será la app en la que
inyectaremos el código malicioso.
En este caso vamos a descargarla utilizando la
web https://apkpure.com/
Podemos descargarnos cualquier aplicación
15. Por otro lado, vamos a mover la apk maliciosa
generada con msfvenom en Kali a la distribución de
Androl4b.
En esta distribución tenemos muchas herramientas
de análisis de apps Android, entre ellas apktool que
es la que usaremos para decompilar ambas apks.
18. El próximo paso es copiar esos archivos generados por
apktool, los cuales contienen el código del payload
generado por msfvenom, a las carpetas generadas de la
apk de CCleaner.
Esos archivos contenedores del payload se encuentran en
la carpeta /payload/smali/com/metasploit/stage
19. Antes de copiar los .smali con el código malicioso
debemos crear la misma estructura de carpetas dentro de
la app legítima.
Una vez creada la ruta /com/metasploit/stage/ ya
podremos copiar los archivos smali
20. “
Los archivos smali son los
intermediarios entre los
dex y el código fuente Java
22. Tenemos el código malicioso dentro de la APK legitima, pero esto no significa que si
generamos el APK el payload va a ejecutarse. De hecho, vamos a hacer que esto sea así
inyectando un hook dentro de la actividad original de inicio, la MainActivity, ¿y que es un
hook?
En este caso nos referimos a hook a la inyección que vamos a hacer para que cuando se inicie
la app original llame a nuestro código payload, y lo ejecute por nosotros de una manera
totalmente invisible para el usuario final.
Para ello, vamos a revisar el archivo AndroidManifest.xml de la apk original, tal y como
vamos a mostrar a continuación.
23. Ya tenemos localizada la actividad principal de esta app, se llama MainActivity.
La hemos podido localizar por el intent.action.MAIN
Esta sería la actividad que inicia la aplicación en una primera instancia, por lo que
tendríamos que buscar el MainActivity.smali dentro de los archivos generados por
apktool para modificarlo, la ruta nos la da el valor del atributo que acabamos de
revisar.
26. Con nuestro editor favorito, abrimos el .smali e intentamos localizar el siguiente valor
.method public onCreate(Landroid/os/Bundle;)V
Una vez localizado, debajo del invoke-super añadimos la siguiente línea:
invoke-static {p0}, Lcom/metasploit/stage/Payload;->start(Landroid/content/Context;)V
28. El siguiente paso es añadir los permisos adicionales necesarios para que el payload
realice correctamente su trabajo, esos permisos los debemos añadir en el fichero que
visitamos antes, el AndroidManifest.xml
Por defecto, nuestra aplicación legítima elegida ya tendrá ciertos permisos establecidos
en la siguiente parte del manifiesto.
29. Vamos a coger los permisos de la app maliciosa y vamos a pegarlos en el manifest de la
app legítima, eliminando los permisos duplicados
30. Para conocer más sobre los permisos de Android en las aplicaciones podéis visitar el siguiente enlace
https://developer.android.com/guide/topics/manifest/manifest-intro.html?hl=es-419#perms
32. Llegados a este punto, el siguiente paso es generar nuestro APK legítimo con el payload
inyectado. Para ello acudimos de nuevo a nuestra herramienta apktool.
Tendremos disponible el apk en la carpeta dist
34. Una vez generado vamos a firmar el APK ya que Android requiere que todas las apps
estén firmadas digitalmente para identificar al autor de la aplicación, igualmente no es
necesario que sea firmada por una autoridad certificadora, podemos utilizar certificados
autofirmados.
Para ello usaremos herramientas como keytool y jarsigner.
36. Con la APK maliciosa en
nuestro poder, ya podemos
pasar a la acción, en mi caso
voy a infectar un Android
virtual para comprobar la
eficacia de nuestro CCleaner
personalizado
Para ello, utilizaremos una
máquina virtual de Android y
pondremos un handler a la
escucha en nuestra consola
de Metasploit a través del
puerto que configuramos al
comienzo en msfvenom.
37.
38. En cuanto abrimos la app legitima, nos damos cuenta de que se nos abre una sesión de meterpreter
sobre nuestro handler que estaba escuchando, ya tenemos nuestro acceso al Smartphone Android.
40. La sesión de Meterpreter nos brinda el acceso a utilidades muy interesantes, desde mandar sms, hacer
capturas de la cámara, escuchar el micrófono, subirle archivos, descargárnoslos…
41.
42. Podemos llevar mucho mas allá nuestro proceso y para intentar indetectabilizar nuestra
APK realizar procesos de ofuscación, podemos modificar los nombres de los ficheros y
carpetas…todo lo que podamos imaginar.
Existe una herramienta que automatiza todo este proceso llamada backdoor-apk que
podéis encontrarla en este repositorio: https://github.com/dana-at-cp/backdoor-apk
Esta herramienta utiliza herramientas de ofuscación como ProGuard y dx, es interesante
que reviséis el código para ver como hace todo esto, ya que ahora conocemos el proceso.
43. PWNED! 😉¿Que cosas se os ocurren con una sesión de
meterpreter sobre un terminal Android?
45. Herramientas utilizadas
DROZER
Herramienta desarrollada por MWR LABS la
cual se trata de un Framework que nos ayudará
a realizar auditorias de seguridad y a realizar
ataques sobre aplicaciones Android.
Contiene, además, algunos exploits para explotar
vulnerabilidades conocidas.
Mas info:
https://labs.mwrinfosecurity.com/tools/drozer/
Guia de usuario:
https://labs.mwrinfosecurity.com/assets/BlogFiles
/mwri-drozer-user-guide-2015-03-23.pdf
Utlizaremos la distribucion AndroL4b
46. APLICACIÓN DE
PRUEBA
Para nuestra PoC vamos a auditar una app de prueba que
viene con nuestra distribución AndroL4b llamada Sieve.
Es un gestor de contraseñas para Android con algunos
fallos.
47. INSTALACIÓN DE
AGENTE DROZER
El agente Drozer será el que interactúe directamente con
la app a auditar y el que ejecutará todas las órdenes que
le daremos desde la consola
48.
49. Debemos ejecutar este comando para poder conectarnos al puerto que habilita el agente
drozer en el Smartphone, el puerto utilizado es el 31415
50. INICIALIZACIÓN DE LA
CONSOLA DROZER
Una vez iniciado el agente podremos conectarnos a
través de la consola a él para empezar a interactuar con
el Framework.
54. Localizamos el nombre del paquete de la aplicación
Obtenemos la información del paquete
55. Gracias a este comando app.package.attacksurface obtenemos los posibles vectores de
ataque de los elementos de la app a los que podemos acceder desde el exterior.
Nos indica que la app Sieve tiene 3 actividades accesibles, 2 proveedores de contenido y
dos servicios, además de que estos últimos son depurables y podríamos vincular un
debugger al proceso.
Nos centraremos en los proveedores de contenido para poder acceder a la base de datos
de la app.
57. Podemos ver que efectivamente no requerimos permisos para acceder a los providers, a
excepción del path /Keys
58. Ya tenemos las URIs de los proveedores de contenido a las que podemos acceder, lo
siguiente será realizar una consulta sobre estas URIs para ver si nos devuelven datos
relevantes de la base de datos.
59. Como veis, los proveedores de contenido no están bien protegidos y podemos hacerles
consultas para visualizar el contenido de la base de datos, obteniendo así las contraseñas
almacenadas en ella.
61. Android promueve el uso de las bases de datos SQLite para almacenar los datos, estas
bases utilizan SQL por lo que no nos debe sorprender que sean vulnerables a SQLi.
Lo vamos a comprobar con el siguiente comando.
62. Vamos a realizar una consulta con nuestra quería coma simple, veamos el resultado
Totalmente vulnerable, vamos a recuperar el listado de tablas de la base de datos
Recuperemos el contenido de la tabla Key, que contiene los datos de login de la app sin cifrar.
63. EJECUCIÓN DE
ACTIVIDADES DE LA
APP
Otra de las capacidades de Drozer es la ejecución de
actividades de una app en concreto.
64. Una vez obtenidas todas las Actividades de la aplicación podemos hacer una
llamada a estas
Como vemos, si llamamos directamente a la actividad
podemos iniciarla sin necesidad de pasar por la primera
actividad que nos pedía una contraseña que desconocíamos.
65. Cosas que podemos hacer con Drozer
Hemos podido ver una pequeña parte de este Framework, queda en vuestra mano
interesaros por el y probar sus opciones. Entre ellas podemos destacar las siguientes:
• Recopilar información de la aplicación
• Encontrar vectores de ataque
• Publicar exploits
• Ejecutar código en el Smartphone de forma dinámica, en vez de tener que instalar apps
• Simular los resultados de los sensores
• Realizar ataques del tipo SQL Injection, Path Traversal, …
• Interactuar con broadcast
• Lanzar actividades
Os invito a probar todo su potencial, que no es poco.
68. Síguenos en nuestras
redes sociales si te ha
gustado el taller!
@TSSentinel
@mmorenodev
thesecuritysentinel.es
Momento de hablar y de
exponer vuestras dudas
e ideas!