GitHub encuentra 24 vulnerabilidades de Android con su agente de seguridad con IA
Security Lab publica como open source los taskflows con los que sus investigadores han reportado 24 fallos en apps Android, entre ellos el seguimiento de ubicación en OsmAnd.
GitHub Security Lab ha reportado 24 vulnerabilidades en aplicaciones Android usando un agente de seguridad basado en IA, y acaba de publicar el sistema que hay detrás como open source. No es un modelo suelto al que se le pide que busque bugs: son taskflows, flujos de prompts que trocean la auditoría en pasos y que el modelo sigue de forma repetible. El equipo lleva tiempo defendiendo ese enfoque frente a la conversación única con el LLM.
La herramienta vive en el repositorio seclab-taskflow-agent. Para ejecutarla sobre un proyecto propio hace falta una licencia de GitHub Copilot, los prompts consumen peticiones de modelo premium y el flujo dispara tantas llamadas a herramientas que se come los tokens con facilidad. El arranque es sencillo: abrir un codespace sobre el repositorio, lanzar ./scripts/audit/run_mobile.sh mi_org/mi_repo y esperar. En un repositorio de tamaño medio, una o dos horas. Al terminar se abre un visor de SQLite con la tabla audit_results; las filas con marca en la columna has_vulnerability son las que interesan.
Cómo se guía al modelo
Dos taskflows hacen el trabajo específico de Android. gather_mobile_entry_point_info.yaml recoge los puntos de entrada del código, esos sitios por donde puede circular datos controlados por un atacante, y los separa entre los propios de una app móvil y los que no. Así el agente entiende bien la superficie de ataque en repos que mezclan aplicaciones móviles, servidores web y programas de escritorio. classify_application_local.yaml, por su parte, lleva una lista de clases de vulnerabilidad conocidas y obliga al modelo a comprobarlas en cada punto de entrada y componente. Si el paso anterior ha marcado un entry point basado en intent, el flujo revisa las clases típicas de ese caso, como el confused deputy o las emisiones inseguras. La combinación de un prompt estricto repetido varias veces evita que se escapen los fallos evidentes, mientras que el prompt abierto deja margen a que el modelo aplique su propia capacidad de asociación.
Seguir al usuario con OsmAnd
El caso más vistoso de los tres que encontraron en OsmAnd. La app de navegación, que tira de OpenStreetMap y supera los 10 millones de descargas en Play Store, exporta una activity llamada MapActivity para abrir ajustes y enlaces internos. Está exportada, de modo que cualquier aplicación instalada puede lanzarla. La app espera que ciertos extras —settings_version, silent_import, replace, export_type_list_key— lleguen desde un servicio AIDL, cuando deberían haber viajado por un canal dentro del proceso. Android no ofrece ninguna forma de limitar qué extras puede añadir un llamante externo a una activity exportada. Con silent_import y replace, otra app puede importar ajustes sin que el usuario vea nada, y a partir de ahí seguir la ubicación del dispositivo.
El agente no es barato de operar ni sustituye al investigador que decide qué merece atención. Lo que cambia es el reparto del trabajo: el barrido repetitivo se va al modelo y la persona se queda con el diseño de los prompts y la clasificación de los fallos. Queda ver si estos taskflows aguantan el ritmo cuando el código cambie y haya que volver a pasarlos.
