La secuencia real de un proyecto de iOS o de Android, de las rules of engagement al retest, incluido lo que este tipo de test no cubre a propósito.
Un pentest de aplicación móvil es una evaluación manual de una app de iOS o de Android y del servidor con el que habla, hecha desde la posición de alguien que se ha descargado tu app en un dispositivo que controla por completo.
Esa última frase es toda la disciplina. Cuando una versión llega a una tienda, el atacante es dueño del tiempo de ejecución: la desmonta sin conexión, la instala en hardware sin restricciones, la engancha mientras corre y repite lo que envía, y nada de eso toca tu infraestructura.
Así que el test no responde a si la app es segura, sino a tres preguntas más estrechas: qué puede sacar alguien del paquete, qué puede saltarse en el dispositivo y qué le permite eso hacerle a tu servidor.
Nada técnico empieza hasta que el alcance está en papel: qué apps, qué plataformas, qué identificadores de versión, qué entorno de servidor, qué cuentas de prueba y qué podemos hacerle a cada cosa.
Las rules of engagement importan aquí más de lo que los clientes esperan, porque el trabajo tiene dos mitades con radios de daño muy distintos. Desmontar un paquete en nuestro hardware no toca nada tuyo. Seguir hasta tu API el token que encontramos dentro, sí. La NIST SP 800-115 define las rules of engagement como el documento que da al equipo de pruebas autoridad para realizar unas actividades definidas sin necesitar permisos adicionales. La mitad del servidor necesita antes ventanas acordadas, límites de frecuencia acordados y una persona de contacto con nombre.
La primera fase técnica no necesita que nada esté en marcha. Abrimos el .apk, el .aab o el .ipa: el manifiesto o el Info.plist, el código compilado, los recursos, los SDK empaquetados y cada cadena de texto que se publicó por descuido.
iOS y Android se acotan por separado, porque un fallo en una muchas veces no existe en la otra. La configuración de seguridad de red de Android deja que una app elija en qué autoridades de certificación confía, que renuncie al tráfico en claro y que fije certificados; para las apps orientadas a Android 9 (nivel de API 28) y superior, el valor por defecto pone cleartextTrafficPermitted a falso. App Transport Security funciona por defecto en las apps enlazadas contra el SDK de iOS 9.0 o posterior, y exige TLS 1.2 o superior y confidencialidad hacia el futuro mediante ECDHE. Las dos se pueden aflojar en unas pocas líneas, y aquí es donde te enteras.
Esta fase es del móvil y de nada más. La versión se instala en un terminal con root o con jailbreak y la vemos trabajar. MASVS-RESILIENCE-1 enuncia la premisa mejor de lo que podríamos nosotros: correr sobre una plataforma que ha sido manipulada puede ser muy peligroso para una app, porque eso puede desactivar ciertas funciones de seguridad. Así que la manipulamos a propósito, y después examinamos en qué daba por hecho la app que podía confiar.
Ahora la app habla y necesitamos leerla, lo que significa derrotar la fijación de certificados en un dispositivo que ya controlamos. Ese salto no es un hallazgo por sí mismo. Es la entrada a la mitad del proyecto donde está el daño.
En el lado del servidor el trabajo es el que cubre un proyecto de API, acotado a la superficie que llama la app. Empieza por la autorización rota a nivel de objeto, la primera del OWASP API Security Top 10 de 2023: cambiar el identificador de una petición de tu objeto al de otra persona y ver si el servidor comprueba algo. La autorización rota a nivel de función, el consumo de recursos sin restricciones y la gestión inadecuada del inventario están en la misma lista.
Esas cadenas pocas veces terminan en la app: los mismos identificadores de objeto llegan a la API, y la API llega hasta donde pueda llegar la cuenta cloud que hay detrás.
Hasta aquí tenemos candidatos. La explotación convierte un candidato en un hecho, y es lo que separa un pentest de un escaneo. La NIST SP 800-115 traza la raya: mientras los escáneres de vulnerabilidades solo comprueban la posible existencia de una vulnerabilidad, la fase de ataque de un pentest la explota para confirmar que existe.
Una clave dentro del binario es una nota. Una clave que además sigue autenticando contra un endpoint de producción, que a continuación devuelve los registros de otro cliente, es un incidente que alguien todavía no ha tenido. Así que cada candidato se lleva hasta donde llegue, y las fases hacen bucle: el modelo de cuatro etapas de la NIST SP 800-115, planificación, descubrimiento, ataque e informe, tiene un camino de realimentación documentado que vuelve del ataque al descubrimiento.
Cada paso que funciona se guarda para que tus desarrolladores puedan repetirlo: petición y respuesta, guion de instrumentación, estado del dispositivo e identificador de la versión.
La severidad se puntúa con CVSS, que mantiene FIRST. Una puntuación base es la severidad técnica intrínseca, constante entre entornos y en el tiempo, y la especificación es explícita en que alimenta un proceso de riesgo que pesa además la exposición normativa, el impacto en el cliente y la pérdida para el negocio. Los hallazgos se ordenan por lo que alcanzan en tu entorno.
Después el retest. Un hallazgo está cerrado cuando la prueba de concepto original deja de funcionar contra la versión corregida, relanzada en los mismos dispositivos y con los mismos pasos. Eso pilla la corrección dirigida a la demostración en vez de al patrón, y la corrección que entró en la app mientras el servidor seguía aceptando la petición antigua. Todos los proyectos de Asperis lo incluyen sin coste adicional.
Una app de una sola plataforma son normalmente una o dos semanas de pruebas activas. Las dos, iOS y Android, o un servidor complejo dentro del alcance, se van a dos o tres semanas. El alcance se acuerda antes de que se abra esa ventana y el retest va detrás de tus correcciones.
Qué lo mueve: las plataformas que entran, cuántos roles autenticados hay, el tamaño de la superficie de API, si la app maneja pagos, identidad o datos de salud, y si hay que derrotar antes los controles de resiliencia.
El OWASP Mobile Top 10 de 2024 es una lista de concienciación y no una metodología; los hallazgos se corresponden con ella porque tus interlocutores la conocen. Para las apps que compras en vez de construir, la NIST SP 800-163 revisión 1, Vetting the Security of Mobile Applications, de abril de 2019, es el proceso complementario.
Si un proveedor dice que su test de móvil cubre las seis, pregúntale cuál de las seis no está haciendo.
Todas las referencias a marcos y todos los valores por defecto de plataforma de este artículo salen de aquí.
La secuencia real de un pentest de red externa: alcance y rules of engagement, reconocimiento, análisis del perímetro, explotación, informe y retest, además de lo que el test no va a cubrir.
La secuencia de un pentest de red interna real: el punto de partida que acordamos, en qué se convierte una cuenta de dominio, qué recibes al final, cuánto dura y qué cosas no cubre el ejercicio a propósito.
La secuencia real de un pentest wifi, de las rules of engagement al retest: qué pasa en cada fase, qué necesitas tener listo, cuánto dura y qué cosas no cubre este test a propósito.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
