<h1>
notas DIVA mobil
</h1>

Pasa cuando los desarolladores registran datos confidenciales (credenciales, detalles financieros, ...)

El directorio <b>res/layout</b> contiene las pantallas de la interfaz del usuario que vamos a ver cuando ejecutemos la aplicación.

El directorio <b>res/drawable</b> contiene las imagenes que se utilizan en la aplicación.

Todos los recursos que se compilan están en <b>resources.arsc</b>

Los que no se compilan estan en <b>res/</b>

En <b>META-INF/</b> hay archivos como el manifest.xml

Para conectarte a un dispositivo movil remoto (pero en local):

adb connect ip


Para instalar de forma remota un apk

adb install file.apk


Ahora la app ya está instalada:


<h2>
Insecure logging
</h2>

El código fuente de la app está en el archivo classes.dex, para hacer el reversing, se utiliza la tool <b>d2j-dex2jar</b>.


En este caso no sabemos lo que está pasando. Vamos a copiar el archivo.apk a un archivo archivo.zip, y vamos a hacer:

unzip file.zip

Esto nos dará el classes.dex (que contiene el código fuente del programa). Para abrirlo, lo podemos abrir con <b>jd-gui</b>


En este caso, hay una función "checkout", esta funcion se ejecuta cada vez que pulsamos el botón checkout. También sale el error que aparece cuando da el

El desarrollador utiliza la función <b>Log.e</b> para registrar en los logs el valor introducido en la tarjeta de crédito. En este caso, la idea es buscar el número exacto del proceso que está utilizando la aplicación y vamos a monitorizarlo.

adb shell ps |grep diva


Nos dá un número, el segundo argumento es el valor del proceso. Lo cojemos y vamos a ejecutar:

adb logcat | grep 2354

En este caso, 2353 corresponde al número del proceso visto anteriormente.


Se ha registrado. Esta es una vulnerabilidad.

<h2>
Almacenamiento inseguro de datos (en el sistema de archivos)
</h2>

Esta vulnerabilidad es bastante común, ocurre cuando los equipos de desarrollo asumen que los no tendrán acceso al sistema de archivos de un dispositivo. Los sistemas de archivos son de fácil acceso.

Viendo el código java, se puede ver que está utilizando una función:


Visitando el siguiente url (buscando en google por "sharedpreferences path" se puede encontrar): https://guides.codepath.com/android/Storing-and-Accessing-SharedPreferences

El path vemos que es:


Ahora, vamos a coger la shell al terminal:

adb shell

Ahora, sabiendo que el path está en data/data, podemos listar el contenido de esa carpeta:

ls data/data |grep diva

Con esto, podemos ver que la carpeta se llama:


Ahora, si accedemos a ese directorio:


Haciendo: <b>cat nombre_archivo</b> se puede ver el contenido:

<h2>
Almacenamiento inseguro de datos (en la base de datos)
</h2>

En este caso el desarollador está almacenando las credenciales en sqlite



Dado que lo está almacenando en una nueva base de datos en el sistema de archivos, podemos intentar verlo:


<h2>
Almacenamiento inseguro de datos (dentro de archivos temporales)
</h2>

En este caso, el desarollador está almacenando credenciales en archivos temporales, cada vez que se utiliza una credencial, se crea un archivo temporal llamado uinfo en <b>data/data/jakhar.aseem.diva</b>




<h2>
Hardcoding issues - Part 1
</h2>

En este caso, simplemente el desarollador ha puesto que, en caso que al programa se le pase una string, haga una cosa, en caso que haga otra, responda de otra manera. En este programa, el desarollador ha puesto en texto claro lo que se necesita para completar el laboratorio.


Pues simplemente, poniendo la string "vendorsecretkey", da el siguiente resultado.


<h2>
Input Validation Issues - part 2
</h2>

En este caso, la aplicación lo que hace es, esperar a que el usuario introduzca un URL válido, como por ejemplo https://google.com/.

Para realizar esto, se está realizando a través de webview, con <b>esquemas URi</b> se puede conseguir LFI.

https://es.wikipedia.org/wiki/Esquema_de_URI

Conociendo la ruta de un archivo local, podemos acceder a dicho archivo y mostrar el contenido por pantalla: