Unintended Data Leakage

DEMO

Este tipo de vulnerabilidad es muy común y ocurre cuando una aplicación guarda información sensible o datos importantes en un lugar accesible para los atacantes, o en aplicaciones dentro del mismo dispositivo.

En este enlace, tenéis explicada la vulnerabilidad mucho más detallada, nosotros vamos a lo que vamos, a por el siguiente reto del Owasp Shepherd.

En algunos casos, los registros proporcionan información útil sobre la aplicación y sus usuarios. Tenemos que usar esta información para encontrar la clave del reto. La aplicación almacena en caché los registros en el dispositivo, actúa como un tablón de anuncios.

Primeramente, nos dirigimos a la carpeta donde se guardan los logs de la aplicación:

/data/data/com.mobshep.udataleakage/files

Observamos que cada vez que escribimos en la aplicación, guarda un registro nuevo:

shell@x86:/data/data/com.mobshep.udataleakage/files # ls

LogFileSat Feb 08 18:31:09 GMT+00:00 2020
LogFileSat Feb 08 18:31:11 GMT+00:00 2020
LogFileSat Feb 08 18:31:12 GMT+00:00 2020
Tue Jul 08 172618 EDT 2014

Imprimimos uno por pantalla para asegurarnos, de que realmente es así:

shell@x86:/data/data/com.mobshep.udataleakage #cat LogFileSat\ Feb\ 08\ 18\:23\:30\ GMT+00\:00\ 2020
holanullSat Feb 08 18:23:30 GMT+00:00 2020null

Ahora nos queda imprimir la flag que por lógica es el log guardado de 2014, fecha que se creó la máquina:

The Key is: «SilentButSteadyRedLed» nullTue Jul 08 17:26:18 EDT 2014null

LEVEL 1 

Log in as the user of this App to get the key for this challenge. Some data has been logged but it is up to the attacker to know what to do with this data.

Conectamos y comprobamos dispositivo conectado:

logan@loganayala:~$ adb connect 192.168.56.102
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.56.102:5555

logan@loganayala:~$ adb devices
List of devices attached
192.168.56.102:5555 device

Abrimos la aplicación vulnerable, escribimos varias veces, con la finalidad de averiguar donde se guarda lo que vamos registrando en la app:

Abrimos shell y escalamos a root para comprobar donde se almacenan los logs, que en esta aplicación son screenshots,  se generan cada vez que introduces un intento de clave secreta:

logan@loganayala:~$ adb shell
shell@x86:/ $ su root
shell@x86:/ # whoami
root
shell@x86:/ #

Empecé por la carpeta /sdcard/ y di con el clavo ya que encontré un log .PNG bastante sospechoso, ya que era el unico que no tenia separación entre el nombre del fichero y la extensión de este:

shell@x86:/ # cd sdcard
shell@x86:/sdcard # ls
Log0b10cb9b9244ce1e1cdc34.PNG
Log167e185347234cbeae4b9ec5d2632fe8 .png
Logb9198032c0024f368ea88df9f8bdbb68 .png
Logda8de29bab71430e9949c8df9857ca9b .png
Logf5ae9d5ef9f64eb987af29ab303e8e5b .png

Para finalizar, pasamos el fichero a nuestro ordenador y comprobamos a ver que contiene:

logan@loganayala:~/MobilePentesting/Retos/UnintendedData$ adb pull /sdcard/Log0b10cb9b9244ce1e1cdc34.PNG
/sdcard/Log0b10cb9b9244ce1e1cdc34.PNG: 1 file pulled. 1.9 MB/s (182313 bytes in 0.093s)

Abrimos el PNG..

LEVEL 2 

This App is leaking logs. The Key is the winning lotto number!

Conectamos con la aplicación y vamos a su carpeta, observando que no contiene nada de su interés.

Como nos dice que la clave es el número de lotería, por lógica tendrá que hacer alguna comparación con un método, en el cual salga el número legible o probablemente obfuscado..

No puse los pasos a seguir,  ya que este tema se explicó en las series de reverse engineering.. Como vemos en la imagen superior obtenemos el número de la lotería, ya que lo que hace el programa es cada vez que clickamos, genera un número y lo compara con el ganador.

Otra manera de realizar este reto, es obteniendo los logs en vivo, mediante logcat y cada vez que pulsamos en generar un número, veremos en pantalla el número que generamos y la comparación que hace con el número ganador:

shell@x86:/sdcard # logcat

Como podemos ver también obtenemos la key del reto 627884736748.