Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Enunciado:
A lo largo de los contenidos se ha hablado de OWASP, análisis estático y análisis dinámico,
vulnerabilidades, desarrollo seguro, etc. Los Smartphones no quedan libres de ataques. OWASP
define un top 10 de riesgos en aplicaciones para dispositivos móviles
(https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10).
Se pide:
A partir de los contenidos estudiados y tras leer el enunciado anterior, analiza al menos tres
aplicaciones (.apk) en busca de vulnerabilidades.
Para el análisis se deben utilizar tanto herramientas stand-alone como online, de manera que
produzcan resultados complementarios y completen un análisis exhaustivo de las aplicaciones.
En cualquier caso, una vez seleccionadas las herramientas, se puede organizar el trabajo de
análisis siguiendo las siguientes tareas:
2. Análisis estático (observar recursos de la app, código fuente, ficheros de configuración, etc.).
Una vez elegidas estas tres .apk vamos a realizar las siguientes técnicas de pentesting:
• Inspección de código
• Análisis de las comunicaciones
• Fugas de información
• Contraseñas expuestas
Primero vamos a preparar los archivos binarios de cada apk. Para esto usaremos la herramienta
apktool.
apktool d fichero. Apk
Una vez extraído los binarios abrimos las cada apk con Android Studio.
Análisis estático
Permisos
En este análisis vamos a verificar los permisos que utiliza la aplicación y donde se utilizan cada uno
de ellos. Para esto nos vamos al manifest de cada aplicación:
Instagram:
Whatsapp:
InsecureBankv2:
Observando los permisos de las aplicaciones vemos que insecurebankv2 tiene permisos mostrados
los cuales no están declarados. Estos son llamadas que realizan las librerías de Google incluidas en
la aplicación, pero nuestra aplicación no tiene que realizarlas.
Vamos a ver con detalle estos permisos que son utilizados por el código de la aplicación:
READ_PHONE_STATE
Utilizado en ChangePassword$RequestChangePasswordTask$1.
Es una clase que pertenece a la actividad ChangePassword.
SEND_SMS
Utilizado en un BroadcastReceiver MyBroadCastReceiver.
READ_log
Utilizado en la actividad PostLogin.
INTERNET
Utilizado en DoLogin y DoTranser.
Aunque es posible que la aplicación utilice permisos definidos de forma indirecta de métodos de
las librerías de Google.
Con toda esta información extraída de los permisos, los componentes de la aplicación y el
manifest. Podemos buscar problemas de configuración en la propia aplicación.
La actividad PostLogin es accesible desde otras aplicaciones y además el permiso Read_log puede
generar una fuga de datos a otras aplicaciones.
MyBroadCastReceiver es accesible por otras aplicaciones y además es capaz de enviar mensajes
SMS. Esta vulnerabilidad podría hacer que se produjesen envíos de mensajes SMS.
Durante el análisis estático podemos identificar las conexiones que realizará la aplicación y
obtener una primera aproximación a la seguridad.
Si observamos el inicio de la clase podemos ver que es http, esto mismo se encuentra en el resto
de las conexiones. Concluimos que se esta enviando información sensible a través de protocolos
sin cifrar y tiene como vulnerabilidad poder ver las contraseñas mediante un ataque man in the
midle.
WhatsApp:
Instagram:
Almacenamiento de credenciales
Vamos a comprobar los tipos de almacenamiento utilizados por la aplicación y ver si son utilizados
para el almacenamiento de credenciales.
Como vemos el usuario está codificado en Base64 pero, sin ningún tipo de seguridad. El password
está guardado cifrado, pero se descifra con una clase que no recibe ningún parámetro. Revisando
la clase CryptoClass se verifica que el passwordestá escrito en el propio código de la aplicación.
En el caso de Instagram tenemos el LoginActivity el cual funciona de forma distinta, Instagram
funciona a través de un servidor Python y siempre manda los datos cifrados.
Dato: Al sacar extraer el código del apk no ha conseguido sacar todos los nombres de las clases.
Análisis dinámico
Vamos a ver el comportamiento de estas apks y veremos de que forma envia la información a su
servidor.
Para esto en insecurebankv2 prepararemos un servidor ficticio el cual nos servirá de ejemplo para
simular el uso de la app de banco.
Para esto dentro de la aplicación nos vamos a preferencias y ponemos nuestra IP como servidor
Después accedemos a la aplicación con uno de los login que nos da la app.
Para ver el tráfico usaremos Wireshark, Para reducir la información que hay que analizar,
aplicamos un filtro para que solo se muestren las conexiones HTTP.
Como vemos los paquetes capturados, además de ser enviados sin cifrar, incluyen información
sensible como el usuario y contraseña.
En las aplicaciones Instagram y WhatsApp no nos aparece el login ya que los datos se mandan
cifrados por https.
Almacenamiento de datos
Vamos a analizar el comportamiento de los datos almacenados en el sistema. Para ello nos vamos
al archivo de preferencias mySharedPreferences.xml
Por lo que vemos no tiene información relevante, por el momento está preparado para almacenar
datos como tarjetas de crédito, todo ello sin cifrar.
En conclusión hemos identificado el usuario y contraseña del servicio, cifrados con una clave
codificada en claro dentro del código de la aplicación y el Fichero de base de datos de
transacciones, en el momento de la revisión, se encuentra vacío, pero por su estructura, parece
almacenar información muy sensible (tarjeta de crédito).
En la aplicación de WhatsApp también podemos ver la base de datos igual que en insecurebankv2
pero en esta lo que vemos es las conversaciones que se han mantenido en la aplicación.
Por otro lado Instagram cifra la información de sesión en el almacenamiento de datos y como base
de datos el cliente ve el contenido de la base de datos de un servidor Python en remoto.