DIVA Avanzado: IPC, NDK y Buffer Overflow

Profundización en la auditoría de DIVA (Damn Insecure and Vulnerable App). En esta segunda parte (Ejercicios 9 al 13), abandonamos los errores de almacenamiento básico y entramos en el núcleo de la arquitectura Android: vulnerabilidades de Comunicación Inter-Procesos (IPC) y la explotación de código nativo (C/C++) mediante el NDK.

Ejercicio 9: Acceso a Credenciales (Broken Access Control)

En Android, las "Activities" (pantallas) deben ser privadas a menos que estén diseñadas explícitamente para ser llamadas desde fuera (ej. la pantalla de compartir un archivo). Si el desarrollador olvida protegerlas, cualquier app puede invocarlas.

# 1. Identificamos el nombre del componente exportado analizando el Manifest:
# <activity android:name=".APICreds1Activity" android:exported="true" />

# 2. Invocamos la actividad directamente desde ADB, saltándonos el flujo lógico:
am start -n jakhar.aseem.diva/.APICreds1Activity

Resultado y Mitigación: La pantalla se abre y muestra las claves API en texto claro. Para mitigarlo, simplemente hay que definir android:exported="false" en el Manifest.

Ejercicio 10: Bypass de Lógica mediante Intent Extras

A veces, los desarrolladores intentan proteger una actividad pasando parámetros (Extras) en el Intent (el mensaje de invocación). APICreds2Activity requiere un PIN, pero decide si verificarlo o no basándose en un parámetro booleano llamado check_pin.

# Al invocar la actividad, inyectamos nuestro propio parámetro para engañar a la app:
am start -n jakhar.aseem.diva/.APICreds2Activity --ez check_pin false

# Glosario de Inyección de Intents en ADB:
# --ez (Extra Boolean): false / true
# --es (Extra String): "texto"
# --ei (Extra Integer): 1234

Ejercicio 11: Fuga Masiva en Content Provider

Los Content Providers son la forma oficial en que las apps comparten bases de datos con otras apps (ej. WhatsApp leyendo tus Contactos). Si un Content Provider de datos sensibles se exporta sin permisos de firma, es un desastre.

# Consultar el Content Provider exportado como si fuéramos una app de terceros:
content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes

# Resultado: Vuelca toda la base de datos de notas confidenciales en la consola.

Ejercicio 12: Secretos en Código Nativo JNI (C/C++)

Muchos desarrolladores creen que si compilan su lógica de negocio o claves criptográficas en una librería compartida de C/C++ (archivos .so a través de JNI), los atacantes no podrán leerlo porque ya no es Java. Falso.

# Extraer la librería nativa de la APK:
unzip diva.apk -d diva_unzipped/
cd diva_unzipped/lib/x86/

# Extraer todas las cadenas de texto imprimibles del archivo binario compilado:
strings libdivajni.so | grep -i "secret"
# Alternativamente, usar Ghidra o IDA Pro para desensamblar la librería.

Ejercicio 13: Buffer Overflow en Android (ARM/x86)

Las aplicaciones Java (Dalvik/ART) son inmunes a los desbordamientos de buffer clásicos porque la Máquina Virtual lanza una excepción IndexOutOfBounds. Sin embargo, si la app usa JNI para ejecutar código C/C++ mal programado (usando funciones inseguras como strcpy), la aplicación hereda las vulnerabilidades nativas.

// El código nativo en divajni.c define un buffer fijo:
#define CODESIZEMAX 20
char input_buffer[CODESIZEMAX];
strcpy(input_buffer, user_input); // <- VULNERABILIDAD CRÍTICA

Explotación: Al introducir más de 20 caracteres en el campo de texto de la aplicación, el buffer se desborda, sobrescribiendo el puntero de instrucción (EIP/RIP) en la pila de memoria. La aplicación colapsa inmediatamente (SEGFAULT / DoS). Un atacante avanzado podría inyectar una shellcode (ROP Chain) en ese desbordamiento para ejecutar código arbitrario con los permisos de la aplicación.