MobSF es bueno, pero no es la biblia sagrada (dejen de citarlo como si fuera)
18 de junio de 2025
El altar de MobSF y sus devotos de siempre
Vamos directo al grano: Mobile Security Framework (MobSF) se ha vuelto la herramienta más sobrevalorada del pentesting móvil. Y no es porque sea mala - de hecho, está bastante decente. El problema es que medio mundo la venera como si fuera la respuesta a todos los males del análisis de seguridad Android.
La pura verdad: Si tu metodología de pentesting móvil consiste en arrastrar un APK a MobSF, esperar a que escupa su reporte colorinche, y luego cobrar como si fueras el mismísimo Kevin Mitnick, entonces no eres pentester, eres un copy-paste con título universitario.
Y sí, ya me tienen podrido viendo “expertos” en ciberseguridad móvil cuya experiencia se resume a saber hacer click en “Analyze” y copiar resultados de análisis estático Android como si fuera su tesis de grado.
Cuando el “MobSF dice que…” se vuelve palabra sagrada
¿Te suena este diálogo de cualquier reunión de pentesting móvil?
- “MobSF encontró 47 vulnerabilidades críticas en la app”
- “El Mobile Security Framework dice que no hay SSL pinning”
- “Según el análisis estático de MobSF, están usando librerías vulnerables”
Y ahí aparezco yo, como cojudo, haciendo la pregunta incómoda: “¿Y verificaste eso a mano, o solo confías en lo que dice la herramienta?”
Respuesta clásica: Silencio de velorio y miradas de “¿para qué voy a verificar si MobSF ya me armó el reporte?”
Esta mentalidad de “herramientas de seguridad móvil que no fallan” es exactamente lo que está convirtiendo el pentesting móvil en un show de análisis de mentira.
Falsos positivos dignos de un museo del absurdo
Déjame contarte las joyas que MobSF considera “vulnerabilidades críticas” y que los devotos repiten como loros:
Los “hardcoded secrets” que son cualquier cosa
MobSF ve un string que se parece a API key y automáticamente grita “VULNERABILIDAD CRÍTICA!” con luces rojas y toda la cosa. La realidad: el 70% de las veces son:
- Claves de demo públicas de la documentación oficial
- Identificadores de servicios que obviamente son visibles
- Constantes de configuración que no tienen nada de secreto
- URLs de endpoints públicos como Plaza de Armas
Pero como el reporte HTML queda bonito con su alerta roja, nadie se molesta en verificar si realmente es algo serio.
SSL pinning “ausente” cuando está más presente que vendedor ambulante
Escenario de todos los días: MobSF no detecta certificate pinning, así que el “experto” concluye que la app es vulnerable a man-in-the-middle.
Lo que realmente pasa: Llega el análisis dinámico y resulta que sí hay SSL pinning, pero implementado de forma casera que el análisis estático Android no puede detectar automáticamente.
¿Quién queda como pavito? El que confió ciegamente en MobSF sin hacer hooking real con Frida.
Permisos “peligrosos” que son más normales que tráfico en el Centro
Mi favorito personal: “VULNERABILIDAD CRÍTICA: La aplicación solicita INTERNET permission”
A ver, genio. Es una app que necesita conexión a internet. ¿Qué esperabas, que funcione con señales de humo?
El límite del análisis estático: cuando el runtime te cachetea
Aquí está la limitación de fondo que los fanáticos de MobSF no quieren aceptar: el análisis estático tiene sus límites, y esos límites están muy por debajo de lo que necesitas para hacer pentesting móvil en serio.
MobSF jamás va a detectar:
- Vulnerabilidades lógicas en el flujo de autenticación
- Race conditions en operaciones críticas
- Fallas de lógica de negocio específicos del contexto
- Bypass de validaciones que solo se ven cuando la app está corriendo
- Vulnerabilidades en APIs backend que no aparecen en el código cliente
Pero como el reporte tiene gráficos bonitos y colores llamativos, la gente cree que “ya revisé toda la aplicación”.
La realidad: No revisaste ni el 30% de lo que importa.
La experiencia que MobSF nunca va a darte
Historia que me duele hasta recordar: Un “pentester móvil” me mostró su análisis de una app bancaria. Quince páginas de puro reporte MobSF con vulnerabilidades que sonaban como si el mundo se fuera a acabar.
Le pedí acceso a la misma aplicación. En 45 minutos de análisis manual encontré:
- Bypass completo del PIN usando hooking con Frida
- SQL injection en endpoint escondido mediante proxy interception
- Session fixation aprovechable en el flujo de login
- Master key hardcodeada en código nativo (que MobSF ni siquiera toca)
¿Estaba alguna de estas vulnerabilidades en su reporte de Mobile Security Framework?
Ni de casualidad. Porque estas vulnerabilidades requieren usar el cerebro, análisis dinámico real, y entender a fondo cómo funcionan las aplicaciones móviles.
Cuándo usar MobSF (y cuándo dejarlo en la caja de herramientas)
No soy un hater irracional. MobSF tiene su lugar en un workflow de pentesting móvil inteligente:
Reconocimiento inicial (los primeros 15 minutos)
Para mapear la superficie básica: librerías usadas, permisos solicitados, estructura general del APK. Es como el primer vistazo antes de la inmersión profunda.
Hunting de strings interesantes
Para encontrar URLs hardcodeadas, patrones sospechosos, imports raros. Me ahorra tiempo de grep manual en código decompilado.
Compliance básico corporativo
Para generar reportes que cumplan checkboxes administrativos: verificación de HTTPS, analysis básico de permisos, detección de librerías conocidamente vulnerables.
Documentación para gerentes
Los reportes HTML quedan lindos para anexar. Los jefes no técnicos aman los gráficos coloridos que “demuestran trabajo”.
PERO JAMÁS DE LOS JAMASES como única metodología para análisis de seguridad Android serio.
El problema no es MobSF, es la religión que se armó alrededor
El problema real no es Mobile Security Framework como herramienta. El problema es la mentalidad de “herramienta mágica” que se armó alrededor: creer que existe una herramienta que va a hacer todo el pentesting móvil por ti.
La verdad sin maquillaje: No existe. Nunca va a existir.
El análisis de seguridad móvil de verdad requiere:
- Dominio de Android internals y sistema de permisos
- Capacidad de análisis manual de código decompilado
- Experiencia en hooking dinámico y bypass de protecciones
- Entender protocolos de red y arquitecturas backend
- Pensamiento lateral para detectar fallas de lógica de negocio
- Experiencia en análisis forense de dispositivos físicos
Y todo eso, ningún análisis estático automático te lo va a dar.
Mensaje final: deja de ser operador de herramientas y empieza a ser pentester
MobSF es un martillo bueno, pero no puedes construir una casa solo con martillo.
Si tu proceso de pentesting móvil se resume a:
arrastrar APK → MobSFclick "Generate Report"copiar → pegar → facturar
Entonces no estás haciendo pentesting, estás haciendo trabajo de oficina automatizado.
Y tarde o temprano, alguien que sí haga análisis real va a encontrar las vulnerabilidades críticas que tu reporte bonito nunca detectó.
Mi consejo sin pelos en la lengua: Usa MobSF como punto de partida, no como meta final. Combínalo con análisis dinámico, hooking manual, proxy interception, y sobre todo, usa la cabeza.
Porque al final del día, las vulnerabilidades más jugosas las encuentra el que piensa, no el software que hace todo automático.
PD: Si una herramienta puede hacer tu trabajo completo sin que muevas un dedo, tal vez deberías preguntarte qué tan valioso eres realmente en el mercado de ciberseguridad móvil.