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.
Analizar el código fuente
Al descompilar un APK, se obtiene el código fuente y se puede analizar. Sin embargo, hoy en día, la mayoría de las aplicaciones lo protegen mediante ofuscación, lo que impide que un atacante comprenda la lógica.
Tal y como se explica en el post anterior, En general se puede revisar algunos archivos para obtener ideas sobre la lógica escrita, como la detección de root, SSL Pinning, la comprobación del depurador, la comprobación del lado del cliente, etc. Analizar el código fuente te dará ideas para comprender cómo realizar un buen análisis dinámico, incluyendo ataques como vistas web o enlaces profundos, e inyecciones.
Se puede analizar el código directamente con semgrep o MobSF. Esto te dará una idea rápida del estado de seguridad. A continuación, se encuentra el repositorio semgrep-rules-android-security, que puede ser útil.
Qué buscar manualmente en el código fuente:
- Lógica de detección de root: verificar las comprobaciones binarias `su` y las comprobaciones de integridad de SafetyNet/Play.
- Implementación de SSL Pinning: busca `CertificatePinner`, `TrustManager` y validación SSL personalizada.
- Comprobaciones del depurador: buscar `isDebuggerConnected()` y comprobaciones de indicadores de depuración.
- Validación del lado del cliente: buscar comprobaciones de autenticación/autorización que se puedan omitir.
- Uso de WebView: Comprrobar `loadUrl()` y `evaluateJavascript()` (son posible fuente de XSS).
- Gestión de intenciones: comprobar cómo se procesan las intenciones (posible inyección de intenciones).
- Gestión de enlaces profundos: comprobar la validación de URL en los controladores de enlaces profundos.
Firma APK - Vulnerabilidad Janus
La verificación de la firma APK es importante para la integridad de la aplicación. Sin embargo, existe una vulnerabilidad llamada Janus (CVE-2017–13156) que permite a los atacantes modificar los archivos APK sin invalidar la firma.
Comprobación de integridad (anti-tampering): descompila el APK con APKtool y modifica algunos archivos, como el manifest.xml y cambia la cadena de "true" a "false". Recompila el APK con APKtool, fírmalo con tu propia clave e instala y ejecuta la aplicación.
Si la aplicación detecta una manipulación, debería rechazar su ejecución o mostrar un error. Si se ejecuta con normalidad, la aplicación no cuenta con la detección de manipulaciones adecuada. Esto constituye una vulnerabilidad.
Comprobación de integridad: descompila el APK y modifica algunos archivos, como el archivo manifest.xml o la cadena "true" (verdadero) a "false". Recompila el APK con apktool, fírmalo con tu propia clave e instala y ejecuta la aplicación.
Ahora hablemos de una de las medidas de seguridad más importantes: la detección de root y SSL Pinning.
Generalmente, las aplicaciones modernas cuentan con todas estas medidas de seguridad, por lo que para realizar la evaluación dinámica y otras comprobaciones de seguridad, es necesario omitirlas. Echemos un vistazo rápido a ellas; no profundizaremos en ellas, solo les daré una descripción general.
¡Detección de root!
Si la aplicación detecta que su dispositivo está rooteado, podría negarse a ejecutarse, mostrar algún error o restringir ciertas funciones.
Las aplicaciones utilizan diversas técnicas para detectar el root. Veamos las más comunes que encontrará durante la evaluación:
- Uso de bibliotecas de detección de root: muchos desarrolladores no escriben código personalizado para la detección de root. Simplemente utilizan bibliotecas predefinidas que realizan todas las comprobaciones de detección de root, como RootBeer, RootCloak y RootInspector.
- Comprobación del binario "su": la aplicación busca el binario "su" en rutas comunes como /system/bin/su, /system/xbin/su o /sbin/su. Si lo encuentra, sabe que el dispositivo está rooteado.
- Buscando aplicaciones de administración de root: las aplicaciones comprueban si Magisk, SuperSU u otras aplicaciones de administración de root están instaladas en el dispositivo. Buscan nombres de paquetes como com.topjohnwu.magisk o eu.chainfire.supersu.
- Comprobación de las propiedades del sistema: las aplicaciones leen propiedades como ro.debuggable, ro.secure o ro.build.tags para detectar el root o las compilaciones de prueba.
- Google SafetyNet / API de Integridad de Play: la solución oficial de Google para la comprobación de la integridad de los dispositivos. Está basada en la nube y comprueba si hay root, un gestor de arranque desbloqueado y manipulación del sistema. Esto es más difícil de eludir que las comprobaciones de root personalizadas.
- Comprobación de particiones del sistema con permisos de escritura: los dispositivos rooteados suelen tener /system montado como lectura y escritura, lo cual las aplicaciones pueden detectar.
- Detección de Magisk o Zygisk: algunas aplicaciones buscan específicamente archivos, procesos o puntos de montaje relacionados con Magisk, como /sbin/.magisk/, /data/adb/magisk, etc.
¿Cómo eludir la detección de root?
Hay varias maneras de eludir la detección de root. Estos son los métodos más comunes:
- Magisk Hide / Zygisk DenyList: habilita DenyList en la configuración de Magisk y añade la aplicación de destino.
- Scripts de Frida: usa la aplicación Frida para enlazar funciones de detección de root y hacer que devuelvan falso. Puedes explorar más scripts personalizados de Frida en GitHub o escribir los tuyos propios si entiendes la lógica de detección.
- Objection: Basado en Frida, proporciona una interfaz de línea de comandos sencilla para desactivar las comprobaciones de root.
- Parchear el APK: descompilar, encontrar la lógica de detección de root, parchearlo, recompilar y firmar.
- Módulos Magisk/LSposed: usar módulos como Hide My Applist, Shamiko, LSPosed con RootCloak o Zygisk-Assistant para ocultar el root de las aplicaciones. Estos funcionan a nivel de sistema.
Recuerda que la omisión es más fácil una vez que comprendes cómo la aplicación detecta el root. Lee el código, identifica las comprobaciones y elige el método de omisión según corresponda.
SSL Pinning
La fijación SSL (también conocida como fijación de certificados) es un mecanismo de seguridad mediante el cual la aplicación valida el certificado SSL del servidor con un certificado predefinido o una clave pública integrada en la aplicación. Esto evita ataques de intermediario (MitM), incluso si instalas un certificado de CA personalizado en el dispositivo.
Al implementar la fijación SSL, no puedes interceptar el tráfico de la aplicación con Burp Suite ni con ningún otro proxy, ya que la aplicación rechazará el certificado de tu proxy.
¿Implementación de la fijación SSL?
Los desarrolladores pueden implementar la fijación SSL de diversas maneras. Veamos las más comunes que observarás durante la evaluación:
- Configuración de seguridad de red (basada en XML): la aplicación define certificados de confianza en un archivo XML, generalmente en res/xml/network_security_config.xml.
- TrustManager personalizado: algunos desarrolladores crean su propio TrustManager para validar certificados manualmente.
- Bibliotecas de terceros: Bibliotecas como OkHttp y TrustKit ofrecen implementaciones de anclaje SSL listas para usar que los desarrolladores pueden integrar fácilmente.
¿Cómo evitarlo?
Necesitamos evitar esta comprobación de anclaje SSL, ya que ya sabe que no se puede interceptar la solicitud ni la respuesta. Sin embargo, para completar la evaluación, también debe analizar estas áreas. Generalmente, se puede solicitar al desarrollador que elimine estas comprobaciones de seguridad, como la detección de root y el anclaje SSL, pero en un escenario de caja negra, este acceso no es posible.
Veamos algunas soluciones comunes para eludir la fijación de SSL:
- Objection: desactiva la fijación de SSL con un solo comando.
- Scripts de Frida: usa scripts universales para eludir la fijación de SSL. Puedes encontrar scripts ya preparados en GitHub, escribir los tuyos propios si entiendes la implementación o usar IA para generarlos.
- HTTP Toolkit: una herramienta GUI que gestiona automáticamente la instalación de certificados y la elusión de la fijación de SSL.
- Aplicación manual de parches: descompilar la aplicación, encontrar la implementación de fijación (buscar CertificatePinner, TrustManager, etc.), modificarla o eliminarla, volver a compilarla y firmarla. Es un proceso lento, pero funciona siempre.
Conclusión
Bien, hemos cubierto mucho en este artículo, desde los fundamentos del análisis estático. Esto debería darte una base sólida para comenzar tu experiencia con las pruebas de penetración en Android. Pero sí, las pruebas de penetración en Android son mucho más que eso. Aún hay muchas áreas que no hemos profundizado aquí. Por ejemplo, WebView, enlaces profundos, problemas relacionados con la memoria y problemas de criptografía, etc.
Abordaré estos temas en detalle en futuros artículos, ¡así que queda atento!
El documento "All About Android Pentesting: A Complete Methodology" fue desarrollador por Xcheater
Fuentes:
http://blog.segu-info.com.ar/2025/12/pentesting-en-android-metodologia-II.html
Fuentes:
http://blog.segu-info.com.ar/2025/12/pentesting-en-android-metodologia-I.html
Este comentario ha sido eliminado por un administrador del blog.
ResponderEliminar