Checklist de pentest de aplicaciones móviles: OWASP MASVS en la práctica

Dame un APK y cinco minutos y normalmente te devolveré algo que los desarrolladores no querían que llegara a producción. Lo descomprimes, lo pasas por jadx, haces grep del código fuente decompilado buscando password, secret o api_key y ves desfilar los resultados. Un token incrustado en el código aquí. Un nombre de host de staging que todavía responde allá. Un TODO de un sprint que nadie recuerda haber escrito.

Ahí es donde arranca buena parte del pentesting de aplicaciones móviles y, más a menudo de lo que debería, también de ahí sale el primer hallazgo real. El cliente corre sobre hardware que no te pertenece. Un atacante puede desmontar el binario en su propio banco de trabajo, a su propio ritmo, sin límite de peticiones y sin que nadie lo observe. Los instintos del mundo web no sobreviven al contacto con esa realidad.

Anclamos cada proyecto al OWASP Mobile Application Security Verification Standard, MASVS, y lo convertimos en una checklist que ejecutamos contra builds reales de Android e iOS. Así funciona en la práctica.

Puntos clave

• El pentesting de aplicaciones móviles combina el análisis estático del binario decompilado con el análisis dinámico de la aplicación en ejecución e instrumentada, porque el cliente está por completo en manos del atacante.
• OWASP MASVS agrupa los controles en almacenamiento, criptografía, autenticación, red, interacción con la plataforma, calidad del código y resiliencia; el OWASP MASTG te da casos de prueba concretos para cada uno.
• Los hallazgos serios que más reportamos son el almacenamiento local de datos inseguro, la criptografía mal empleada y los fallos de autorización en el backend que salen a la luz una vez que se vence el certificate pinning.
• El certificate pinning frena a un tester. No hace que una aplicación sea segura. Si el servidor confía en el cliente, saltarse el pin solo revela los fallos reales que hay debajo.
• MASVS define niveles de verificación (L1 base, L2 defensa en profundidad, R resiliencia), así que ajusta el alcance de la prueba a lo que realmente exige el riesgo de la aplicación en lugar de probarlo todo con la misma profundidad.

¿Qué es MASVS y por qué basar un pentest móvil en él?

MASVS es la respuesta de OWASP a una pregunta sencilla: ¿qué debería hacer realmente una aplicación móvil segura? Es la columna vertebral de cualquier proyecto serio de pentesting de aplicaciones móviles. Los requisitos se reparten en grupos de controles – almacenamiento (MASVS-STORAGE), criptografía (MASVS-CRYPTO), autenticación y gestión de sesiones (MASVS-AUTH), comunicación de red (MASVS-NETWORK), interacción con la plataforma (MASVS-PLATFORM), calidad del código (MASVS-CODE) y resiliencia frente a la ingeniería inversa (MASVS-RESILIENCE).

Su complemento, el OWASP Mobile Application Security Testing Guide (MASTG), es donde el estándar demuestra su valía. MASVS dice que la aplicación “no debería almacenar datos sensibles sin cifrar”. MASTG te dice qué archivos extraer, qué API filtran datos y cómo demostrarlo. Usamos MASVS como mapa de cobertura para que no se salte nada y MASTG como manual práctico para cada control.

Conviene decir algo con claridad: una checklist es un suelo, no un techo. Recorremos las categorías de MASVS para garantizar la cobertura y luego dedicamos el resto del proyecto a perseguir la lógica propia de la aplicación que ningún estándar podría prever. Los bugs interesantes casi siempre viven en la lógica de negocio y en el backend, no en si la aplicación marca una casilla genérica.

¿Cómo se prueba una aplicación móvil? Estático más dinámico

Cada trabajo son dos pasadas sobre el mismo objetivo: la aplicación en reposo y la aplicación mientras se ejecuta. Sáltate cualquiera de las dos y te pierdes la mitad del cuadro.

Análisis estático: leer el binario

En Android decompilamos primero. apktool te da el manifiesto y los recursos; jadx convierte el DEX de vuelta en Java legible. En iOS trabajas con un IPA descifrado, class dumps y el Info.plist. El objetivo de la pasada estática es entender la aplicación antes de ejecutarla y detectar cosas que nunca aparecen en el tráfico.

Un movimiento de apertura típico en Android:

apktool d target.apk -o target_src
jadx -d target_out target.apk

# hunt for obvious secrets and dangerous config
grep -rniE "api[_-]?key|secret|password|token|BEGIN RSA" target_out/
grep -rn "usesCleartextTraffic" target_src/AndroidManifest.xml

Luego leemos el AndroidManifest en busca de componentes exportados: activities, services, broadcast receivers y content providers marcados con android:exported="true" sin ninguna protección de permisos. Una activity exportada que recibe un intent y carga una URL en una WebView es un camino clásico hacia el task hijacking o la inyección en WebView. En iOS la búsqueda equivalente son los esquemas de URL personalizados y los Universal Links declarados en el plist, porque también son puntos de entrada alcanzables por un atacante.

La configuración de red también importa aquí. usesCleartextTraffic="true", o un network_security_config.xml permisivo que confía en las CA añadidas por el usuario, te indica que el tráfico en claro o la interceptación están sobre la mesa antes incluso de abrir un proxy.

Análisis dinámico: ejecutarla y observar

El análisis dinámico requiere un dispositivo Android rooteado o un iPhone con jailbreak, o sus equivalentes en emulador. Nuestra instrumentación de referencia es Frida con Objection por encima. Frida engancha métodos en tiempo de ejecución, vuelca argumentos y reescribe valores de retorno. Objection nos da victorias rápidas – listar entradas del keychain, volcar las SharedPreferences, desactivar las comprobaciones de pin habituales – sin escribir a mano un hook para cada una.

Hacemos pasar todo el tráfico por Burp Suite. En cuanto la aplicación habla con su backend, el trabajo específico de móvil termina en gran medida y empieza el testing de API clásico: comprobaciones de autorización, IDOR sobre identificadores de objeto, mass assignment, reenviar las peticiones de otro usuario. Conseguir una vista limpia de ese tráfico es la prioridad número uno, y por eso precisamente el certificate pinning importa tanto en el flujo de trabajo.

¿Cuáles son los hallazgos más frecuentes en un pentest de aplicación móvil?

El mismo puñado de problemas se repite de un proyecto a otro. Encajan limpiamente en las categorías de MASVS, lo que es una buena pista de que el estándar se construyó sobre dolor real y no sobre teoría.

Almacenamiento de datos inseguro (MASVS-STORAGE)

Este es el hallazgo que más reportamos. Las aplicaciones cachean mucho más de lo que los desarrolladores creen. En Android extraemos el sandbox y revisamos los XML de SharedPreferences, las bases de datos SQLite y los archivos del directorio de datos interno:

adb shell run-as com.example.app ls -la /data/data/com.example.app/
adb shell run-as com.example.app cat shared_prefs/*.xml

Tokens de sesión. Credenciales completas. Datos personales (PII). En ocasiones datos de pago, en texto plano dentro de las SharedPreferences o en una tabla SQLite sin cifrar. En iOS la misma clase de bug aparece en NSUserDefaults, archivos plist, almacenes de Core Data y elementos del Keychain guardados con una clase de accesibilidad débil como kSecAttrAccessibleAlways. Cualquier cosa legible en un dispositivo perdido o infectado con malware es una exposición real, y se corresponde con CWE-312, almacenamiento en claro de información sensible.

Criptografía débil o mal empleada (MASVS-CRYPTO)

La categoría de criptografía rara vez trata de matemáticas rotas. Trata de mal uso. Claves incrustadas en el código sacadas directamente del fuente decompilado. Modo ECB, donde los bloques de texto plano repetidos filtran la estructura en el texto cifrado – esa elección de algoritmo roto es CWE-327. IV estáticos o nulos. “Cifrado” casero que resulta ser Base64 con unos pasos extra, y Base64 es codificación, no protección.

Frida es perfecto para confirmarlo en vivo. Engancha la configuración del cifrador e imprime la clave y el IV mientras la aplicación se ejecuta:

Java.perform(function () {
  var Cipher = Java.use("javax.crypto.Cipher");
  Cipher.init.overload("int", "java.security.Key").implementation = function (mode, key) {
    console.log("[cipher] alg=" + this.getAlgorithm() +
                " key=" + Java.use("android.util.Base64").encodeToString(key.getEncoded(), 0));
    return this.init(mode, key);
  };
});

Cuando la clave que “protege” tus datos se imprime en la consola al arrancar la aplicación, el debate sobre la solidez teórica se acabó.

Fallos de autorización y de sesión en el backend (MASVS-AUTH)

Una vez que el tráfico es visible, es el servidor el que soporta la confianza, y ahí es donde se esconden los bugs de alta severidad. Tokens que nunca caducan. Identificadores de sesión predecibles. Decisiones de autorización tomadas en el lado del cliente en lugar del servidor. Si la aplicación oculta un botón de administrador pero la API responde tan tranquila a la llamada de administrador desde una cuenta normal, eso es un crítico, y ningún hardening del cliente lo arregla.

¿Cómo se hace el bypass del certificate pinning?

El pinning se elude enganchando el código que realiza la comprobación del pin y forzándolo a pasar – normalmente con Frida u Objection – para que tu CA de proxy vuelva a ser de confianza. Objection trae una orden de una sola línea:

objection -g com.example.app explore
# then, in the Objection prompt:
android sslpinning disable

En aplicaciones con una implementación de pinning propia o comprobaciones en código nativo, el bypass genérico falla y pasas a un script de Frida dirigido que engancha el TrustManager concreto, el CertificatePinner de OkHttp o la ruta nativa SSL_CTX_set_custom_verify. En iOS normalmente enganchas TrustKit o la propia lógica de evaluación de confianza de la aplicación alrededor de SecTrustEvaluate.

Aquí viene la parte de opinión. El pinning es un badén, no un control. Eleva el coste para un atacante ocasional y gana tiempo frente al utillaje automatizado, lo cual es realmente útil y merece la pena implementar. Pero si vencer el pin revela una API con la autorización rota, el pinning era cosmético. Probamos cada aplicación como si el pinning ya estuviera vencido, porque un atacante motivado con el binario y un dispositivo rooteado acabará venciéndolo. MASVS clasifica el pinning bajo resiliencia precisamente por eso: es defensa en profundidad, no un sustituto de un backend que aplique sus propias reglas.

¿Cómo se corrigen estos problemas?

Sobre todo respetando la plataforma. Usa el almacenamiento seguro que ofrece el sistema operativo en lugar de fabricar el tuyo: Android Keystore y EncryptedSharedPreferences a través de Jetpack Security, y el Keychain de iOS con una clase de accesibilidad sensata como kSecAttrAccessibleWhenUnlockedThisDeviceOnly. Nunca aparques secretos de larga vida en las SharedPreferences ni en NSUserDefaults.

Para la criptografía, recurre a bibliotecas de alto nivel contrastadas en vez de a llamadas de cifrado en crudo. Tink, de Google, es una buena opción por defecto porque convierte la elección segura en la fácil. No embarques claves dentro de la aplicación; derívalas o aprovisiónalas en tiempo de ejecución y mantén las verdaderas decisiones de confianza en el servidor. Trata al cliente como no confiable, de extremo a extremo – toda comprobación de autorización y validación que importe debe aplicarse en el servidor, porque el cliente móvil puede manipularse y se manipulará. Añade el pinning y el anti-tamper como capas adicionales una vez que los fundamentos estén en su sitio, no antes.

Cómo ayuda CyberXplore

Nuestro servicio de pentesting de aplicaciones móviles ejecuta contra tus builds de Android e iOS toda la metodología alineada con MASVS que se describe aquí: análisis estático del binario decompilado, análisis dinámico en dispositivos instrumentados, bypass del pinning y una mirada exigente a las API de backend en las que se apoya la aplicación. Recibes un informe que ordena los hallazgos por impacto real de negocio, con pasos de reproducción que un desarrollador puede seguir y un retest una vez aplicadas las correcciones, de modo que el arreglo quede verificado y no solo afirmado. ¿Te preparas para una revisión de la app store, un cuestionario de seguridad de un cliente o una auditoría de cumplimiento? Alineamos el proyecto con el nivel de verificación MASVS adecuado. Solicita un presupuesto y cuéntanos sobre tu aplicación; definiremos el alcance con honestidad.

FAQ

¿Cuánto tarda un pentest de una aplicación móvil?

Una aplicación centrada en una sola plataforma suele suponer una o dos semanas de pruebas, según el número de funciones, el tamaño de la superficie de API y si Android e iOS están ambos dentro del alcance. Las aplicaciones con mucha lógica de backend llevan más tiempo, porque la mayoría de los hallazgos serios viven en la autorización del lado del servidor, y ahí es donde se van las horas una vez que el tráfico es visible.

¿Se necesita el código fuente para probar una aplicación móvil?

No. Trabajamos perfectamente en modo caja negra solo con el APK o el IPA compilado, ya que la decompilación forma parte del trabajo de todos modos. Dicho esto, una prueba de caja gris en la que compartes el código fuente y cuentas de prueba encuentra más y lo encuentra antes, porque dedicamos las horas de prueba a bugs reales en lugar de a ingeniería inversa. Recomendamos la caja gris para la mejor relación calidad-precio.

¿Cuál es la diferencia entre MASVS y MASTG?

MASVS es el estándar: define los requisitos de seguridad que una aplicación móvil debería cumplir, agrupados en categorías y niveles de verificación. MASTG es la guía de pruebas: da a los testers técnicas concretas, uso de herramientas y casos de prueba para verificar cada requisito. En la práctica usamos MASVS como checklist de cobertura y MASTG como manual de procedimiento.

¿El certificate pinning hace que mi aplicación sea segura?

No. El pinning es un control de resiliencia que ralentiza la interceptación y los ataques automatizados, lo cual merece la pena tener, pero un tester decidido con un dispositivo rooteado lo eludirá. No hace nada frente al almacenamiento local inseguro, la criptografía débil o la autorización de backend rota. Considéralo una capa por encima de una aplicación que ya es segura sin él.

¿Con qué frecuencia deberíamos pentestear una aplicación móvil?

Al menos una vez al año, y después de cualquier cambio significativo como un nuevo flujo de autenticación, una función de pago o una integración de backend importante. Las aplicaciones móviles se publican rápido, y cada release puede reintroducir problemas antiguos o añadir nueva superficie de ataque, así que una prueba puntual solo te informa sobre el build que probaste. Muchos equipos combinan una prueba completa anual con retests más ligeros en los releases importantes.