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="http://blog.segu-info.com.ar/2025/12/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á…