Auditoría DIVA: Vulnerabilidades Android

DIVA (Damn Insecure and Vulnerable App) es una aplicación Android diseñada intencionalmente con fallos críticos de seguridad. Esta auditoría práctica aborda el análisis estático (SAST) y dinámico (DAST) demostrando cómo los errores de desarrollo comprometen los datos del usuario, y cómo mitigarlos.

Concepto Clave: El Sandboxing en Android

En Android, cada aplicación se ejecuta en su propia "caja de arena" (Sandbox) con un identificador de usuario único (UID). Por defecto, una app no puede leer los archivos de otra app. Sin embargo, si el dispositivo está rooteado (o si usamos ADB en un emulador), podemos escalar a root y eludir el Sandbox, accediendo al directorio /data/data/ donde las apps guardan su información privada.

1. Insecure Logging (Fugas de Información en Registros)

Los desarrolladores usan la clase Log de Android para depurar errores. Si estos logs no se eliminan en Producción, cualquier aplicación con el permiso READ_LOGS (o un atacante con acceso físico/ADB) puede leer información crítica.

# Acceder a la terminal del dispositivo Android:
adb shell

# DIVA procesa tarjetas de crédito y las imprime en el logcat. 
# Filtramos la salida en tiempo real buscando la etiqueta "diva-log":
logcat | grep "diva-log"

Mitigación: Utilizar herramientas como ProGuard o R8 para eliminar automáticamente las llamadas a Log.d() y Log.i() al compilar la versión Release de la APK.

2. Hardcoding Issues (Secretos en el Código Fuente)

Nunca confíes en el cliente. Una APK puede ser descompilada fácilmente. DIVA esconde una "Vendor Key" directamente en el código Java.

# 1. Extraer la APK del dispositivo o descargarla.
# 2. Abrir la APK con JADX (Decompilador de Dalvik a Java):
jadx-gui diva.apk

# 3. Navegar a: jakhar.aseem.diva -> HardcodeActivity
# La clave aparecerá en texto plano: String vendorKey = "vendorsecretkey";

Mitigación: Las claves de API críticas no deben estar en la APK. Deben ser solicitadas dinámicamente a un servidor backend seguro tras autenticar al usuario, o usar ofuscación avanzada (NDK / C++ JNI) para dificultar (no impedir) su extracción.

3. Insecure Data Storage: SharedPreferences

SharedPreferences es un mecanismo de Android para guardar pequeñas configuraciones (como el modo oscuro). DIVA comete el error de usarlo para guardar el usuario y la contraseña.

# Explorar el directorio privado de la aplicación usando ADB (requiere root):
adb shell
su
cd /data/data/jakhar.aseem.diva/shared_prefs/

# Ver el archivo XML en texto plano:
cat jakhar.aseem.diva_preferences.xml

Mitigación: Utilizar EncryptedSharedPreferences (de la librería AndroidX Security), que cifra automáticamente las claves y valores utilizando el Android Keystore System.

4. Insecure Data Storage: SQLite Databases

Para datos más complejos, las apps usan bases de datos locales SQLite. Si el teléfono cae en malas manos o es infectado por un troyano con root, la base de datos entera queda expuesta.

# Navegar a la carpeta de bases de datos de la app:
adb shell
su
cd /data/data/jakhar.aseem.diva/databases/

# Interactuar con la base de datos usando la CLI de sqlite3:
sqlite3 ids2
sqlite> .tables
sqlite> .headers on
sqlite> SELECT * FROM myuser;
# ¡Contraseñas expuestas sin cifrar (ni siquiera hasheadas)!

Mitigación: Utilizar SQLCipher, una extensión open-source de SQLite que provee cifrado AES-256 transparente para los archivos de la base de datos completa.

5. Insecure Data Storage: Almacenamiento Externo (SD Card)

Almacenar archivos en /sdcard/ o en el almacenamiento externo público significa que CUALQUIER aplicación en el teléfono con el permiso READ_EXTERNAL_STORAGE puede leer ese archivo. DIVA guarda un archivo temporal de credenciales allí.

# Buscar archivos en el almacenamiento externo:
adb shell
cd /sdcard/
ls -la | grep uinfo
cat .uinfo.txt

Mitigación: Almacenar siempre la información sensible en el Almacenamiento Interno (Internal Storage), que está protegido por el Sandbox de la aplicación.

6. Input Validation: SQL Injection en Android

Las inyecciones SQL no solo ocurren en servidores web; las bases de datos locales (SQLite) de Android también son vulnerables si se concatenan strings de entrada del usuario de forma insegura.

En el formulario de DIVA, si el usuario introduce ' OR '1'='1, la consulta interna se convierte en: SELECT * FROM users WHERE username='' OR '1'='1', devolviendo todos los usuarios registrados en el dispositivo.

Mitigación: Utilizar siempre Prepared Statements (Consultas Preparadas) mediante la API de Android (db.rawQuery("SELECT * FROM users WHERE user=?", new String[]{userInput});).