El documento "All About Android Pentesting: A Complete Methodology" fue desarrollador por Xcheater

Android está en todas partes. Miles de millones de dispositivos, millones de aplicaciones y una enorme superficie de ataque que crece día a día. Así que, por supuesto, debemos centrarnos en su seguridad. Hoy voy a hablar sobre mi metodología de pentesting en Android, que sigo desde hace años. Esto será útil tanto para los nuevos usuarios como para algunos con experiencia.

Pero sí, la verdad es que esta lista de verificación o metodología puede ser demasiado larga. Y no siempre se recomienda seguir todos los pasos. Pero sí, tenla en cuenta.

Supongo que ya tienes una configuración para el pentesting en Android. Tienes tu dispositivo rooteado y cumples con otros requisitos básicos. No vamos a cubrirlos. Además, para esta metodología, me centro en un enfoque de dispositivo rooteado, que te dará libertad para múltiples cosas, las cuales utilizaremos en nuestras pruebas de penetración.

Recopilación de información básica

¿Qué archivos incluye el paquete?

Extrae el APK y examina su estructura. Puedes usar APKtool para esto o simplemente renombra test.apk a test.zip y extráelo.

¿Qué biblioteca nativa usa la aplicación?

Aunque podemos obtener esta información más tarde, después de descompilar, puedes revisar la carpeta `lib/` para encontrar las bibliotecas nativas. A veces también se pueden ver algunos archivos `.so` personalizados.

Si estás realizando pruebas de penetración de caja blanca, solicita estos detalles al desarrollador.

Ahora es necesario entender que en las pruebas de penetración de Android tenemos dos partes: análisis estático y análisis dinámico. El análisis estático implica examinar el código de la aplicación sin ejecutarlo. Aquí es donde encontramos secretos codificados, claves API y fallos lógicos.

Primero, profundicemos en el análisis estático. El primer paso es descompilar la aplicación. Puedes usar apktool o la interfaz gráfica de JADX. Prefiero la interfaz gráfica de JADX, que es muy útil y fácil de entender en comparación con apktool. Aunque también puedes encontrar la interfaz gráfica de APKtool UI.

AndroidManifest.xml

Empecemos directamente con AndroidManifest.xml. Piensa en este archivo como el plano de toda la aplicación. Es como un mapa que te muestra todo sobre la estructura, los permisos, los componentes y la configuración de seguridad de la aplicación, todo en un solo lugar. Este único archivo puede revelar una gran superficie de ataque.

Se pueden encontrar muchísimas vulnerabilidades con solo leer este archivo: actividades exportadas sin autenticación, aplicaciones de producción depurables, copias de seguridad habilitadas con datos confidenciales; todo visible en XML simple. Por eso siempre empiezo aquí. Es la forma más rápida de encontrar las oportunidades más fáciles.

Permisos de la aplicación: comprueba qué permisos solicita la aplicación y busca permisos peligrosos que los requieran. ¿Por qué la aplicación necesita esos permisos? ¿Son necesarios?

<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Copia de seguridad habilitada: comprueba si <application android:allowBackup="true"> está habilitado. Si está habilitado, un usuario adversario puede usar la herramienta ADB para acceder a los datos de copia de seguridad de la aplicación, lo que puede exponer preferencias compartidas, bases de datos y archivos internos. Si esta opción no aparece en el manifiesto, se define como "true" por defecto. Por lo tanto, si no ves el atributo "allowBackup", la copia de seguridad sigue habilitada.

Indicador de depuración: comprueba si <application android:debuggable=true> está configurado como verdadero. Un usuario adversario puede adjuntar el depurador, leer la memoria del proceso y modificar variables en tiempo de ejecución. A diferencia de "allowBackup", este indicador NO está habilitado por defecto (su valor predeterminado es `false`). Sin embargo, a veces los desarrolladores lo dejan habilitado accidentalmente en compilaciones de producción o se configura como verdadero durante el desarrollo.

Configuración de seguridad de red: Comprueba si la fijación de certificados está implementada o si se permite el tráfico de texto sin cifrar. Si se permite el tráfico de texto sin cifrar, se trata de una vulnerabilidad.

<network-security-config>
    <base-config cleartexttrafficpermitted="true">
        <trust-anchors>
            <certificates src="system">
        </certificates></trust-anchors>
    </base-config>
</network-security-config>

Si se establece cleartextTrafficPermitted=true, la aplicación permite conexiones HTTP, lo que significa que el tráfico puede ser interceptado y modificado. Esto representa una vulnerabilidad.

Versiones mínima, máxima y de destino del SDK: Las versiones anteriores del SDK tienen una seguridad más débil. Si la aplicación utiliza SDK antiguos, no será compatible con las funciones de seguridad modernas. La aplicación debe usar la versión más reciente del SDK.

Componentes de la aplicación exportados: Busca los componentes exportados. Hay cuatro componentes (actividades, servicios, proveedores y receptores). Si android:exported = true está presente, significa que se puede llamar de forma independiente, lo que puede usarse con fines maliciosos o para eludir algunas funciones de seguridad.

• Actividades (Activities): son básicamente las pantallas de la interfaz de usuario, como la página de inicio, la pantalla de inicio, etc. Si se exportan, otras aplicaciones pueden iniciarlas directamente. Así, puedes omitir la pantalla de inicio e ir directamente a la página de inicio.
• Servicios (Services): se ejecutan en segundo plano, realizando algunas tareas sin mostrar la interfaz de usuario. Si se exportan, otras aplicaciones pueden iniciarlos o detenerlos. Pueden usarse para activar algunas acciones sin que el usuario lo sepa.
• Proveedores de contenido (Content Providers): comparten datos entre aplicaciones. Si se exportan, otras aplicaciones pueden consultarlos y leerlos, como información del usuario, tokens y datos de la base de datos. Aquí es donde se encuentran las fugas de datos.
• Receptores de difusión (Broadcast Receivers): escuchan los mensajes del sistema, como cuando se inicia el teléfono o se reciben SMS, etc. Si se exportan, las aplicaciones maliciosas pueden activarlos. Se puede utilizar para realizar acciones sin interacción del usuario.

Busca cadenas interesantes: busca cadenas interesantes como contraseñas, URL, claves API, claves de cifrado, puertas traseras, tokens y UUID. En ocasiones, puedes obtener secretos codificados e incrustados en la aplicación. Estos secretos pueden utilizarse posteriormente, tal vez aprovechando filtraciones de claves API o algún hallazgo lógico.

Aquí se puede usar automatización, con una herramientas como apkurlgrep o una utilidad como string o regex a través de la interfaz gráfica de usuario de JADX.

Configuración incorrecta de Firebase: al analizar una cadena interesante, podrías obtener una URL de Firebase como https://xyz.firebaseio.com/; generalmente la encontrarás en res/values/strings.xml. Por lo tanto, vale la pena revisar los problemas de configuración incorrecta de Firebase. Simplemente ve al navegador y navega a la URL encontrada: https://xyz.firebaseio.com/.json.

Observarás dos tipos de respuesta:

• Permiso denegado: Esto significa que no puedes acceder a ella, por lo que está bien configurada. Continúa.
• Respuesta nula o un montón de datos JSON: Esto significa que la base de datos es pública y que al menos tienes acceso de lectura.

Si recibiste la segunda respuesta, no te quedes ahí, comprueba si tienes más que acceso de lectura; es decir, si puedes escribir algo allí.

curl -X PUT "https://xyz.firebaseio.com/test.json" -d '{"test":"data"}'
# If successful, check for delete access (be careful!)
curl -X DELETE "https://xyz.firebaseio.com/test.json"

Bien, ya hemos cubierto los fundamentos del análisis estático. Ahora hablemos de dónde almacenan las aplicaciones datos confidenciales. Aquí es donde se encuentran muchas vulnerabilidades.

Continuará...