Clase 262 — Pentest de aplicaciones Android

Parte: 13 — Seguridad móvil, IoT e inalámbrica · Fuente: OWASP MASTG y The Mobile Application Hacker's Handbook (Chell et al.) ⏱️ Duración estimada: 120 min · Nivel: Avanzado


🎯 Objetivo

Ejecutar una evaluación de seguridad completa de una aplicación Android combinando análisis estático (SAST), dinámico (DAST) e instrumentación en tiempo de ejecución. El alumno montará el entorno, interceptará el tráfico HTTPS de la app, evadirá certificate pinning y detección de root en laboratorio, y buscará las vulnerabilidades del top de OWASP MASVS: almacenamiento inseguro, comunicación débil y lógica del lado del cliente evadible.

⚠️ Nota ética: todo el pentest se realiza sobre apps propias, apps deliberadamente vulnerables (DIVA, InsecureBankv2, MASTG apps) o con autorización escrita del titular. Interceptar o modificar apps de terceros sin permiso es ilegal.

📚 Resultados de aprendizaje

Al finalizar, el alumno podrá:

  1. Configurar un laboratorio de pentest móvil con emulador rooteado y proxy interceptor.
  2. Realizar análisis estático de un APK con MobSF y apktool.
  3. Interceptar tráfico TLS instalando un CA propio y evadiendo pinning con Frida.
  4. Instrumentar la app en runtime con Frida para saltar controles del cliente.
  5. Detectar almacenamiento inseguro en SharedPreferences, SQLite y ficheros.
  6. Documentar hallazgos mapeados a OWASP MASVS con evidencia reproducible.

🗺️ Temas

# Tema Por qué importa
1 Montaje del laboratorio y proxy Sin interceptación no hay DAST móvil
2 Análisis estático con MobSF Detecta secretos y malas prácticas rápido
3 Interceptación TLS y CA de usuario El pinning bloquea Burp por defecto
4 Evasión de pinning con Frida Habilita ver el tráfico real de la app
5 Almacenamiento inseguro Es la vulnerabilidad móvil más frecuente
6 Controles del lado del cliente Root/jailbreak detection y su bypass
7 Reporte según MASVS/MASTG Traduce hallazgos a un estándar reconocido

📖 Definiciones y características

🧰 Herramientas y preparación

# Emulador rooteado + Frida server
adb root
adb push frida-server /data/local/tmp/ && adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "/data/local/tmp/frida-server &"
pip install frida-tools objection

# Análisis estático con MobSF (Docker)
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

🧪 Laboratorio guiado

  1. Prepara la app objetivo: instala una app vulnerable propia (p. ej. InsecureBankv2) con adb install app.apk.
  2. Análisis estático: sube el APK a MobSF. Anota secretos hardcodeados, permisos peligrosos y componentes exportados que reporte.
  3. Desensambla: apktool d app.apk -o app_src y jadx app.apk. Busca cadenas sospechosas: grep -ri "http://\|password\|api_key" app_src.
  4. Configura el proxy: define el proxy del AVD hacia Burp e instala el CA de Burp como certificado del sistema (con root: remonta /system y copia el .0).
  5. Evade el pinning: lanza objection -g <paquete> explore y ejecuta android sslpinning disable, o usa un script Frida de bypass. Verifica que el tráfico HTTPS aparece en Burp.
  6. Revisa almacenamiento: navega la app y luego inspecciona /data/data/<paquete>/: shared_prefs/*.xml, bases databases/*.db (ábrelas con sqlite3), y ficheros en claro.
  7. Salta root detection: si la app se cierra al detectar root, usa objection/Frida (android root disable) y documenta el bypass.
  8. Reporta: por cada hallazgo, registra requisito MASVS afectado, evidencia (captura/volcado) y recomendación.

✍️ Ejercicios

  1. Extrae y decompila un APK propio y localiza una URL o clave hardcodeada.
  2. Instala el CA de Burp como certificado de sistema y demuestra interceptación de una petición.
  3. Escribe (o adapta) un script Frida que registre los argumentos de una función de login.
  4. Vuelca una base SQLite de la app y extrae datos almacenados sin cifrar.
  5. Compara los hallazgos automáticos de MobSF con los que encontraste manualmente y explica las diferencias.
  6. Mapea cinco hallazgos a los controles MASVS-STORAGE, MASVS-NETWORK y MASVS-RESILIENCE.

📝 Reto verificable

Realiza un pentest completo de una app deliberadamente vulnerable y entrega un mini-informe con al menos tres hallazgos de categorías distintas (almacenamiento, comunicación, resiliencia), cada uno con evidencia reproducible. Criterio de aceptación: para el hallazgo de comunicación, incluyes una captura del tráfico HTTPS interceptado tras evadir el pinning, demostrando que el bypass funcionó.

⚠️ Errores comunes

Síntoma / mensaje Causa y cómo arreglar
Burp no ve tráfico HTTPS El CA no está en el almacén de sistema o hay pinning; instala CA de sistema y evade pinning
Failed to spawn: unable to find process (Frida) frida-server no corre o versión distinta; empareja versiones cliente/servidor
App se cierra al abrir Root/emulador/pinning detection; usa objection para desactivarlos
apktool falla al recompilar Recursos corruptos; usa -r o trabaja con smali sin recompilar
CA instalado como "usuario" ignorado Desde Android 7 las apps ignoran CA de usuario; instálalo como sistema

❓ Preguntas frecuentes

❓ ¿Por qué Burp no intercepta aunque instalé el certificado? Desde Android 7, las apps por defecto no confían en CA de usuario. Debes instalarlo como CA de sistema (requiere root) y, si hay pinning, evadirlo con Frida/objection.

❓ ¿Necesito el código fuente para hacer el pentest? No. Con el APK basta: se desensambla a smali y se decompila a Java aproximado con jadx; Frida instrumenta el binario en runtime.

❓ ¿Es suficiente MobSF para un informe profesional? No. MobSF acelera el triage, pero genera falsos positivos y no valida explotabilidad. El análisis manual y dinámico es indispensable.

🔗 Referencias

📥 Material descargable

⬅️ Clase anterior

Clase 261 — Seguridad de Android: arquitectura

➡️ Siguiente clase

Clase 263 — Seguridad de iOS: arquitectura