InjuredAndroid Part I

En esta sección voy a ir subiendo una serie de pentestings a aplicaciones móviles que estoy haciendo como preparación para la eMAPT. La idea es usar esto como mis propios apuntes para documentar el proceso de explotación de cada vulnerabilidad y tener bien claros los vectores de ataque más comunes en Android.

Flag I: LOGIN I

Para la primera flag lo que haremos será directamente inspeccionar la APK para fijarnos en los datos de cada “flag” oculta. Podemos observar que esta es muy sencilla ya que la flag está en el propio código.

Flag II: EXPORTED ACTIVITY

Esta segunda flag nos deja una pista bastante clara: Hay que inspeccionar la APK para descubrir actividades exportadas (accesibles desde fuera) que nos permitirán bypassear la MainActivity.

En otras palabras, detectar actividades no protegidas nos permite ejecutar la aplicación sin tener que pasar por la actividad principal, eso nos puede permitir saltarnos ciertas medidas de seguridad y además android nos permite ejecutarla desde otras apps

Vamos a ello!

Para ello usaremos una herramienta llamada Drozer. esta herramienta nos permitirá analizar la app desde dentro y observar que componentes están expuestos (actividades expuestas).

Primero de todo debemos descargar el agente para poder conectarnos al servidor de Drozer y lo activamos.

Después deberemos redireccionar el puerto de nuestro PC al puerto abierto de drozer del Android (31415) y abriremos una consola en nuestra terminal.

Cuando lo tenemos todo conectado empezaremos a enumerar la información de la app. Con los siguientes comandos podemos enumerar información general de la app (permisos, nombre, path…) y información general de las actividades (exportadas, permisos…) respectivamente.

run app.package.info -a <package>

run app.activity.info -a <package>

Ahora que tenemos las actividades exportadas, probaremos de ejecutarlas para ver cual contiene la flag. Lo haremos con el siguiente comando:

adb shell am start -n <package>/.<activity>

En este caso:

Lo tenemos!

Otra manera de ver las actividades exportadas seria con este comando :

adb shell dumpsys package <package> | grep -i activity

O directamente desde el archivo AndroidManifest.xml:

Aquí métodos no faltan! Pasamos a la siguiente flag.

(Teoria: El fallo es el atributo android:exported="true" en el Manifest sin ningún permiso que lo proteja. Esto permite que cualquiera llame a la actividad desde fuera y se salte el login o cualquier flujo lógico de la app.)

Flag III: RESOURCES

Tenemos pista: Recursos y archivos.xml

Primero reviso los importantes, el AndroidManifest.xml pero no encuentro nada; luego el strings.xml.

Aquí la tenemos. Siguiente

Flag IV: LOGIN II

En el código principal vemos como se crea una instancia de la clase g() llamando a su método a() y luego se compara con el valor introducido por el usuario a través del EditText.

Si entramos a esta clase podemos ver lo siguiente:

Vemos que la flag esta en base 64 asi que acudimos a nuestro amigo cyberChef.

Y lo tenemos!!

PD: se podría hacer dinámicamente usando Frida pero lo dejaremos para otro capítulo

(Teoria : El error es meter secretos (como la clave en base64) a pelo en el código. Por mucho que lo ofusques o lo codifiques, si está en el cliente, el atacante lo va a encontrar tarde o temprano mediante ingeniería inversa.)

Flag V: EXPORTED BROADCAST RECEIVER

Analizando el código de este reto he podido observar que para obtener la flag había que interactuar con el onRecive y viendo las condiciones solo dando 3 clicks en el botón te daba la flag.

easyone :P

(Teoria: El BroadcastReceiver responde a eventos externos sin validar correctamente el origen ni el estado interno. Esto permite que un atacante interactúe con él (en este caso mediante clicks/eventos) hasta cumplir la condición que revela la flag. El fallo es no implementar controles de acceso ni validaciones en componentes expuestos.)

Flag VI: LOGIN III

Viendo el código observamos que la flag esta codeada, si accedemos a la función vemos que se le aplican diferentes métodos para descodificarla. Podríamos seguir el paso a paso , pero como hemos comentado previamente tenemos la oportunidad ( y facilidad ) de usar una herramienta llamada Frida. Frida nos permite interceptar (hooking) llamadas a funciones, clases … en momento de runtime, entonces aquí la idea seria que en vez de rompernos la cabeza descodificando esta cadena, usaremos la propia app para que nos de la flag sin esfuerzo ninguno.

y obtenemos la flag!

Flag VII: SQLITE

En esta ocasión nos pide un usuario y una password, analizando el código podemos observar que el ejercicio crea una database, tenemos los datos en base64 pero prefiero hacerlo bien. Nos conectamos al device y accedemos a las bases de datos de la app y llegamos al hash siguiente:

Lo pasaremos por nuestro otro gran amigo CrackStation y obtenemos la supuesta flag (o nombre de usuario).

En este punto tenemos el nombre de usuario, pero también necesitamos la password (segunda flag).

Gracias a CTF o máquinas anteriores me puedo dar cuenta de que el inicio del supuesto hash de la password:

9EEADi^^

Tiene un aire a:

https://

Entonces con la IA en nuestra bando descubro que esta encriptado con ROT-47:

y obtenemos lo siguiente

Y dentro de la URL:

(Esta flag se puede obtener usando dynamic analysis que lo adjuntare en la segunda parte de los apuntes)

(Teoria: Almacenamiento inseguro. Guardar credenciales o datos sensibles en bases de datos locales (aunque sea en /data/data/) es un riesgo si el móvil está rooteado o si hay una vulnerabilidad de lectura de archivos. El hash ayuda, pero si es débil (como este), se rompe fácil.)

FLAG VIII & IX: AWS & FIREBASE

Viendo el código deberiamos encontrar credenciales para AWS pero después de rato no podemos encontrar nada…

En el código podemos ver una cadena en base64 que si la descodificamos tenemos lo siguiente:

Y tambien en los strings encontramos la URL: https://injuredandroid.firebaseio.com

Si juntamos todo tenemos:

Haciendo este reto, me doy cuenta de que en la flag 8 aparece una función llamada database.child(”aws”) y tiene igual que ver que el reto 9 pero a diferencia que en este el”child” esta codificado en base64 asi que me da por probar y bingo!!

(Teoria: Hardcoding de credenciales de servicios en la nube. Nunca se deben dejar API keys o URLs de bases de datos (Firebase/AWS) expuestas en los strings o el código, porque permiten acceso directo a la infraestructura del servidor desde el lado del cliente.)

Final Parte I

De momento lo dejamos aquí con estas primeras flags. Más adelante seguiré con la segunda parte de los apuntes, donde nos meteremos en cosas más dinámicas y avanzadas que se han quedado en el tintero.