Pruebas de penetración de aplicaciones móviles: qué alcanza un atacante antes de la API

Un informe de pruebas de penetración sin hallazgos no significa que su aplicación móvil sea segura. Puede significar simplemente que el tester nunca salió de la capa de la API. Si el equipo de seguridad de un cliente corporativo o un auditor le pidió un pen test de la aplicación móvil y usted entregó un informe construido a partir de escaneos de endpoints de la API, entregó el documento equivocado, y lo notarán en la página dos.

Las pruebas de penetración de aplicaciones móviles son una evaluación de seguridad del binario de la propia aplicación y del dispositivo en el que se ejecuta, no de los servidores con los que se comunica. Un tester cualificado extrae la aplicación, inspecciona cómo guarda datos localmente, comprueba si hay secretos incrustados en el código compilado, intercepta y manipula su tráfico de red, y la ejecuta en vivo en un dispositivo con jailbreak o root para ver qué protecciones aguantan de verdad. La API también entra en el alcance, pero es la mitad más pequeña del trabajo.

Esa distinción importa porque la mayoría de los proveedores que anuncian “pruebas de penetración móviles” lanzan un escáner de aplicaciones web contra el backend de su app, envuelven el resultado en un PDF y lo dan por terminado. Parece exhaustivo. No responde a ninguna de las preguntas que hará un revisor especializado en móvil, o su propio equipo de seguridad.

¿En qué se diferencian las pruebas de penetración móviles de las web?

Una aplicación web vive en un servidor que usted controla. Una aplicación móvil vive en el teléfono de un desconocido, y ese teléfono es el hardware del propio atacante. Puede ponerlo en su banco de trabajo, descompilarla, conectarle un depurador y tomarse todo el tiempo que quiera. Nadie tiene ese nivel de acceso físico a sus servidores de producción.

Ese único hecho cambia lo que la prueba tiene que cubrir.

Para la parte de la API y del lado del servidor, que merece su propia pasada dedicada, nuestra lista de comprobación de pruebas de penetración de aplicaciones web cubre ese terreno como corresponde. Este artículo se queda en el cliente, el dispositivo y el transporte que hay entre medias, porque esa es la superficie que un encargo exclusivamente móvil debe cubrir.

¿Qué cubren realmente las pruebas de penetración de aplicaciones móviles?

Todo encargo serio de seguridad y pruebas de penetración de aplicaciones móviles recorre la misma superficie de ataque central, mapeada contra OWASP MASVS y el OWASP Mobile Top 10. Esto es lo que hace un tester en cada capa, y lo que acaba en el informe como evidencia.

Almacenamiento local de datos

Vía del atacante: Un atacante con el dispositivo, o con una copia de su backup, extrae el sandbox de la aplicación y lee todo lo que esta escribió en disco: bases de datos SQLite, archivos plist o de preferencias compartidas, respuestas de API en caché, archivos de log. Si algo de eso contiene tokens, datos personales o información de sesión en texto plano, ya lo tiene sin tocar un solo servidor.

Qué se entrega como evidencia: Un listado archivo por archivo del almacenamiento local de la aplicación con el contenido sin cifrar señalado, capturas de los datos legibles extraídos directamente del sistema de archivos del dispositivo, y una nota sobre qué requisito de almacenamiento de OWASP MASVS incumple.

Uso incorrecto de Keychain y Keystore

Vía del atacante: El Keychain de iOS y el Keystore de Android existen para que los secretos no queden en archivos planos, pero muchas aplicaciones los usan mal, guardando un token con la clase de accesibilidad o el nivel de protección equivocados, de modo que queda legible tras un jailbreak o en un dispositivo sin pantalla de bloqueo. El atacante simplemente le pide el elemento al sistema operativo y lo recibe.

Qué se entrega como evidencia: La entrada concreta del keychain o keystore, la configuración de accesibilidad o protección bajo la que se guardó, y una prueba de concepto de extracción que muestra el valor en claro.

Secretos incrustados en el binario

Vía del atacante: Claves de API, secretos de firma o URLs internas acaban compilados dentro de la aplicación en lugar de obtenerse en tiempo de ejecución. Un tester descompila el binario (o simplemente ejecuta strings contra él) y el secreto está ahí en texto plano, listo para reutilizarse directamente contra su backend.

Qué se entrega como evidencia: El fragmento descompilado o desensamblado que muestra el secreto en contexto, y una demostración de qué desbloquea ese secreto: un endpoint interno, la clave de un servicio de terceros, un certificado de firma.

Certificate pinning e interceptación de tráfico

Vía del atacante: Sin un pinning adecuado, un atacante enruta el tráfico de la aplicación a través de un proxy de interceptación en un dispositivo que controla, lee cada petición y cada respuesta, y las modifica al vuelo, cambiando un precio, un identificador de usuario o un indicador de permisos en pleno trayecto.

Qué se entrega como evidencia: Una captura completa de peticiones y respuestas de la sesión de interceptación y, cuando el pinning existe pero es evitable, la técnica de bypass concreta que se usó (framework de hooking, binario parcheado) junto al tráfico que quedó expuesto.

Evasión de la detección de jailbreak y root

Vía del atacante: Las aplicaciones que comprueban si el dispositivo tiene jailbreak o root suelen apoyarse en un puñado de comprobaciones muy conocidas, rutas de archivos, llamadas al sistema, listas de paquetes, que un tester derrota con una herramienta de hooking lista para usar en cuestión de minutos. Una vez evitadas, cualquier otra protección construida sobre la premisa de “este dispositivo es de confianza” deja de significar nada.

Qué se entrega como evidencia: Qué método de detección estaba implementado, el bypass exacto usado contra él, y qué quedó accesible una vez derrotada la comprobación (normalmente: todo lo anterior).

Ingeniería inversa y reempaquetado

Vía del atacante: Un tester descompila la aplicación para evaluar cuánta lógica de negocio, comprobaciones de licencia o código anti-manipulación queda expuesto y legible, y después reempaqueta una versión modificada (funciones desbloqueadas, publicidad eliminada, código inyectado) y confirma si se instala y se ejecuta igual que la original.

Qué se entrega como evidencia: El código fuente descompilado o su representación intermedia, una lista anotada de qué lógica se pudo recuperar y, si el reempaquetado funcionó, la aplicación modificada instalada y ejecutándose en un dispositivo de prueba.

Comunicación entre aplicaciones: deep links y componentes exportados

Vía del atacante: Los deep links y las actividades, intents o content providers exportados son la forma en que las aplicaciones se comunican entre sí, y también la forma en que una aplicación maliciosa instalada en el mismo dispositivo alcanza la suya, disparando una acción o extrayendo datos sin pasar nunca por su interfaz prevista ni por su gestión de sesiones. Aquí es donde buena parte de la misma lógica de confianza rota que provoca la autenticación rota en la web reaparece en móvil, solo que por otra puerta.

Qué se entrega como evidencia: El componente exportado o el esquema de deep link, una llamada funcional desde una aplicación de prueba sin privilegios que lo dispara, y qué quedó expuesto o se ejecutó como consecuencia.

Cómo es un entregable real de pen test móvil

Esta es la forma más rápida de distinguir un encargo genuino de un escaneo automatizado con un generador de informes acoplado: pregunte qué se ejecutó en un dispositivo real.

Un pen test móvil de verdad combina tres cosas, no una:

1. Análisis estático del binario descompilado, del código fuente cuando está disponible, de los archivos de configuración y de los recursos embebidos.
2. Análisis dinámico de la aplicación en ejecución, interceptación de tráfico, manipulación en tiempo de ejecución, comportamiento ante entradas anómalas.
3. Una sesión en vivo sobre un dispositivo con jailbreak o root, donde el tester derrota realmente las protecciones de la aplicación en tiempo real en lugar de limitarse a señalar que existen.

Un producto de escaneo automatizado más PDF se salta el paso tres por completo. Puede decirle que una cadena incrustada parece una clave de API. No puede decirle si la detección de jailbreak aguanta un intento de bypass real, porque eso solo se ve cuando alguien ejecuta la aplicación en un teléfono con jailbreak y lo intenta.

Pida a cualquier proveedor el índice del entregable antes de firmar. Si no incluye una sesión en dispositivo en tiempo de ejecución con capturas y técnicas de bypass concretas, y todos los hallazgos parecen salidos de una lista de reglas en lugar de un dispositivo, está comprando un escaneo, no un pen test de aplicación móvil. Nuestro propio proceso de pruebas de seguridad explica cómo delimitamos y estructuramos ese encargo de tres partes antes de empezar a trabajar.

Cuándo las pruebas móviles por sí solas no bastan

Un pen test móvil le dice qué alcanza un atacante a través del cliente, el dispositivo y el transporte. No le dice si su API tiene autorización rota a nivel de objeto, limitación de peticiones débil o un fallo de inyección que un atacante podría explotar directamente, saltándose la aplicación por completo y hablando con su backend desde un script. Esos son riesgos reales y necesitan su propio alcance, no una nota al pie dentro de un informe móvil.

Si un marco normativo o el cuestionario de seguridad de un cliente corporativo pide “pruebas de seguridad de aplicaciones móviles”, confirme por escrito si esperan la API como partida separada o dentro del mismo encargo. Dar por supuesta cualquiera de las dos opciones es como un informe impecable acaba cubriendo solo la mitad de lo que realmente se prometió.

Cómo ejecuta QAwerk un pen test de aplicación móvil

Delimitamos cada encargo de pen testing de aplicaciones móviles como una partida propia, análisis estático y dinámico más una sesión en tiempo de ejecución sobre dispositivos reales con jailbreak y root, no integrado dentro de una evaluación web genérica ni automatizado de principio a fin. Es la misma razón por la que nuestros clientes nos traen aplicaciones fintech de verificación de identidad antes de una revisión de cumplimiento de Google Play o la App Store, y aplicaciones de citas y redes sociales que almacenan datos personales más sensibles de lo que sus equipos esperan al principio: el informe tiene que aguantar la lectura atenta de otra persona, no solo parecer completo.

Ese encargo se enmarca en nuestros servicios de pruebas de penetración, delimitados con el mismo precio transparente por tiempo y materiales en todos los tipos de prueba que su aplicación realmente necesite.

Preguntas frecuentes

¿Qué son las pruebas de penetración de aplicaciones móviles?

Son una evaluación de seguridad del binario de una aplicación móvil, de su almacenamiento local y de su comportamiento a nivel de dispositivo, distinta de probar los servidores con los que se conecta. Un tester analiza la aplicación de forma estática, la prueba dinámicamente mientras se ejecuta y realiza una sesión en vivo sobre un dispositivo con jailbreak o root para confirmar qué protecciones aguantan de verdad.

¿En qué se diferencian las pruebas de penetración móviles de las web?

Las pruebas web apuntan a la lógica de servidor a través de la red. Las móviles apuntan a un binario que el atacante tiene en la mano, y cubren almacenamiento local, secretos incrustados, certificate pinning, detección de jailbreak e ingeniería inversa, nada de lo cual tiene equivalente en web.

¿Qué incluye un pen test de aplicación móvil?

Revisión del almacenamiento local de datos, comprobaciones de keychain y keystore, detección de secretos incrustados, pruebas de certificate pinning e interceptación de tráfico, evasión de la detección de jailbreak y root, intentos de ingeniería inversa y reempaquetado, y pruebas de comunicación entre aplicaciones mediante deep links y componentes exportados.

¿Un pen test de aplicación móvil cubre también la API del backend?

Algunos encargos incluyen una pasada limitada de API, pero la API merece su propio alcance dedicado, el mismo que se usa en una evaluación web estándar. Confírmelo explícitamente cuando un requisito normativo o la petición de un cliente hablen de “pruebas de seguridad de aplicaciones móviles”.

¿Con qué frecuencia debe someterse una aplicación móvil a pruebas de penetración?

Depende de la cadencia de publicación y del perfil de riesgo, no de un calendario fijo. Nuestra guía sobre la frecuencia de las pruebas de penetración explica cómo fijar un calendario que encaje con su situación.