Metodología Integral de Pentesting en Android (Parte I) ~ Segu-Info

El documento «Todo sobre el Pentesting en Android: Una Metodología Completa» fue creado por Xcheater

---

Android está omnipresente. Miles de millones de dispositivos y millones de aplicaciones crean una vasta superficie de ataque que crece a diario. Por lo tanto, es esencial centrar nuestra atención en su seguridad. Hoy quiero compartir mi metodología de pentesting en Android, que he estado utilizando durante varios años. Esto servirá tanto para principiantes como para usuarios más experimentados.

Sin embargo, es importante señalar que esta lista de verificación puede resultar extensa y no siempre es aconsejable seguir todos sus pasos. Aun así, es valioso mantenerla en mente.

Asumo que ya cuentas con un entorno configurado para pentesting en Android. Esto incluye un dispositivo rooteado y el cumplimiento de otros requisitos básicos, los cuales no vamos a abordar aquí. Además, mi enfoque se centra en un dispositivo rooteado, lo que te brinda mayor flexibilidad para llevar a cabo diversas pruebas de penetración.

Recopilación de Información Básica

¿Qué archivos contiene el paquete?

Extrae el APK y analiza su estructura. Puedes utilizar APKtool para hacerlo, o simplemente renombrar test.apk a test.zip y descomprimirlo.

¿Qué bibliotecas nativas utiliza la aplicación?

Aunque esta información puede obtenerse más adelante al descompilar, puedes revisar la carpeta `lib/` para identificar las bibliotecas nativas, que a menudo incluyen archivos `.so` personalizados.

Si estás realizando un pentesting de caja blanca, es conveniente solicitar estos detalles al desarrollador.

Es fundamental comprender que en las pruebas de penetración de Android existen dos elementos: análisis estático y dinámico. El análisis estático se refiere a la evaluación del código de la aplicación sin ejecutarla, donde se pueden descubrir secretos codificados, claves API y fallos lógicos.

Comencemos con el análisis estático. El primer paso es descompilar la aplicación. Puedes usar apktool o la interfaz gráfica de JADX. Personalmente, prefiero la interfaz gráfica de JADX porque es más intuitiva en comparación con apktool. También puedes considerar la interfaz gráfica de APKtool UI.

AndroidManifest.xml

Empecemos con AndroidManifest.xml. Considera este archivo como el plano total de la aplicación. Es una guía que detalla la estructura, permisos, componentes y configuraciones de seguridad todo en un solo lugar. Este archivo puede revelar una amplia superficie de ataque.

A través de la lectura de este archivo, puedes detectar diversas vulnerabilidades: actividades exportadas sin autenticación, aplicaciones en producción que son depurables, y copias de seguridad activadas con datos sensibles, todo visible en un simple formato XML. Por esto, siempre comienzo aquí, ya que es la forma más rápida de identificar oportunidades fáciles.

Permisos de la aplicación: verifica qué permisos solicita la aplicación y busca aquellos considerados peligrosos. ¿Por qué necesita la aplicación dichos permisos? ¿Son realmente necesarios?

Copia de seguridad habilitada: verifica si está activo. Si está habilitado, un atacante podría usar ADB para acceder a los datos de copia de seguridad, exponiendo preferencias compartidas, bases de datos y archivos internos. Si este atributo no aparece en el manifiesto, se define como «true» por defecto, así que si no lo ves, la copia de seguridad está habilitada.

Indicador de depuración: verifica si está configurado. Esto podría permitir a un atacante adjuntar un depurador, leer la memoria del proceso y alterar variables en tiempo de ejecución. A diferencia de «allowBackup», este indicador no se activa por defecto (su valor predeterminado es `false`), sin embargo, a veces los desarrolladores lo dejan habilitado accidentalmente en las versiones de producción o durante el desarrollo.

Configuraciones de seguridad de red: revisa si la fijación de certificados está implementada y si el tráfico sin cifrado está permitido. Si se permite, eso es una vulnerabilidad.

Si cleartextTrafficPermitted=true está establecido, la aplicación permite conexiones HTTP, lo que implica que el tráfico podría ser interceptado y modificado, constituyendo una vulnerabilidad.

Versiones mínima, máxima y de destino del SDK: utiliza las versiones más recientes del SDK, ya que las versiones antiguas tienen seguridad más débil y no son compatibles con las funciones de seguridad más avanzadas.

Componentes de la aplicación exportados: investiga los componentes exportados. Existen cuatro componentes (actividades, servicios, proveedores y receptores). Si android:exported = true está presente, eso significa que se pueden invocar de forma independiente, lo que podría ser utilizado para fines maliciosos o eludir ciertas medidas de seguridad.

• Actividades (Activities): son esencialmente las pantallas de la interfaz de usuario. Si están exportadas, cualquier aplicación puede iniciarlas directamente, permitiendo omitir pantallas de inicio.
• Servicios (Services): operan en segundo plano y pueden realizar tareas sin mostrar una interfaz de usuario. Si se exportan, otras aplicaciones pueden iniciarlos o detenerlos, lo que puede ser utilizado para provocar acciones sin conocimiento del usuario.
• Proveedores de contenido (Content Providers): comparten datos entre aplicaciones. Si se exportan, otras aplicaciones pueden acceder y leer datos, como información del usuario, tokens y datos de bases de datos. Aquí podrían ocurrir filtraciones de datos.
• Receptores de difusión (Broadcast Receivers): escuchan mensajes del sistema. Si están exportados, aplicaciones maliciosas pueden activarlos y ejecutar acciones sin interacción del usuario.

Busca cadenas interesantes: busca elementos como contraseñas, URLs, claves API, claves de cifrado, puertas traseras y tokens. A veces, es posible encontrar secretos codificados dentro de la aplicación que podrían ser utilizados en vulnerabilidades futuras.

En este punto, la automatización puede ser útil, empleando herramientas como apkurlgrep o utilidades como string o regex en la interfaz gráfica de JADX.

Configuración incorrecta de Firebase: al investigar cadenas, podrías encontrar una URL de Firebase, como https://xyz.firebaseio.com/, que generalmente aparece en res/values/strings.xml. Vale la pena revisar posibles problemas de configuración inadecuada. Navega a la URL encontrada: https://xyz.firebaseio.com/.json.

Podrías ver dos tipos de respuesta:

• Denegación de permiso: si recibes esta respuesta, significa que no tienes acceso y está bien configurada. Avanza.
• Respuesta vacía o datos JSON: esto indica que la base de datos es pública y al menos tienes acceso de lectura.

Si obtuviste la segunda respuesta, no te detengas ahí; verifica si puedes escribir en ella.

curl -X PUT "https://xyz.firebaseio.com/test.json" -d '{"test":"data"}'
# Si tiene éxito, verifica si puedes eliminar (ten cuidado!)
curl -X DELETE "https://xyz.firebaseio.com/test.json"

Hemos cubierto los fundamentos del análisis estático. Ahora exploremos dónde las aplicaciones almacenan datos sensibles, que es donde aparecen muchas vulnerabilidades.

Continuará…