Las claves API filtradas ya no son infrecuentes, ni tampoco lo son las infracciones resultantes. ¿Por qué los tokens sensibles siguen filtrándose tan fácilmente?
Para averiguarlo, el equipo de investigación de Intruder examinó qué cubren realmente los escáneres de vulnerabilidades tradicionales y desarrolló un nuevo método de detección secreto para llenar los vacíos en los enfoques existentes.
El análisis de aplicaciones a gran escala de 5 millones de aplicaciones descubrió más de 42.000 tokens expuestos en 334 tipos secretos. Esto expuso una gran clase de secretos filtrados que las herramientas existentes no manejan bien, particularmente en aplicaciones de una sola página (SPA).
En este artículo, analizamos los métodos de detección de secretos existentes y mostramos lo que encontramos cuando buscamos en millones de aplicaciones secretos ocultos en paquetes de JavaScript.
Métodos establecidos para la detección de secretos (y sus limitaciones)
Detección de secretos tradicional
El enfoque tradicional y totalmente automatizado para detectar secretos de aplicaciones es buscar en un conjunto de rutas conocidas y aplicar expresiones regulares para que coincidan con formatos secretos conocidos.
Si bien este método es útil y puede detectar algunas vulnerabilidades, tiene limitaciones importantes y no detecta todo tipo de fugas, especialmente aquellas que requieren que el escáner rastree o autentique la aplicación.
Un buen ejemplo de esto es la plantilla GitLab del token de acceso personal de Nuclei. El escáner recibe una URL base, por ejemplo https://portal.intruder.io/, lo que hace que la plantilla haga lo siguiente:
- Realice una solicitud HTTP GET a https://portal.intruder.io/.
- Consulta la respuesta directa a esta única solicitud. Ignorar otras páginas y recursos como archivos JavaScript
- Intente identificar el patrón de un token de acceso personal de GitLab
- Si lo encuentra, realice una solicitud de seguimiento a la API pública de GitLab para verificar si el token está activo.
- Si está activo, informar un problema
Este es claramente un ejemplo simple, pero este enfoque es efectivo. Esto es especialmente cierto cuando las plantillas definen muchos caminos donde se revelan secretos con frecuencia.
Este formato es típico de los escáneres de infraestructura que normalmente no ejecutan un navegador sin cabeza. Cuando se le proporciona al escáner la URL base para escanear (por ejemplo, https://portal.intruder.io), las solicitudes posteriores que realizaría un navegador (por ejemplo, los archivos JavaScript necesarios para representar la página, por ejemplo, https://portal.intruder.io/assets/index-DzChsIZu.js) no se realizan utilizando este enfoque antiguo.
Pruebas dinámicas de seguridad de aplicaciones (DAST)
Las herramientas de prueba dinámica de seguridad de aplicaciones (DAST) generalmente proporcionan un método más sólido para escanear aplicaciones y, por lo general, tienen funciones más sofisticadas. Permiten un análisis completo de las aplicaciones, admiten la autenticación y proporcionan mayores capacidades de detección de vulnerabilidades a nivel de las aplicaciones. De hecho, los escáneres DAST parecen ser la opción natural para detectar secretos en las interfaces de las aplicaciones. Nada debería impedir que un escáner DAST descubra archivos JavaScript disponibles o busque secretos dentro de ellos.
Sin embargo, este tipo de escaneo es más costoso, requiere una configuración extensa y, en realidad, generalmente está reservado para una pequeña cantidad de aplicaciones de alto valor. Por ejemplo, es poco probable que configure un escáner DAST para cada aplicación que tenga en un amplio dominio digital. Además, muchas herramientas DAST no implementan suficientes expresiones regulares en comparación con las herramientas de línea de comandos más conocidas.
Esto deja una clara brecha que debería puede o no estar cubierto por el escáner de infraestructura tradicional y, con toda probabilidad, no estará cubierto por los escáneres DAST debido a limitaciones de implementación, presupuesto y mantenimiento.
Pruebas de seguridad de aplicaciones estáticas (SAST)
Las herramientas de prueba de seguridad de aplicaciones estáticas (SAST) analizan el código fuente para identificar vulnerabilidades y son una forma principal de descubrir secretos antes de que el código entre en producción. Son eficaces para capturar credenciales codificadas y evitar que ciertas especies se vean comprometidas.
Sin embargo, descubrimos que ni siquiera los métodos SAST cubren el panorama completo y, una vez más, algunos secretos dentro de los paquetes de JavaScript se filtraron de manera que el análisis estático pasaría desapercibidos.
Crear una verificación de detección de secretos para paquetes de JavaScript
Cuando comenzamos esta investigación, no estaba claro qué tan común sería este problema. ¿Están realmente incluidos los secretos en las interfaces de JavaScript? ¿Está esto lo suficientemente extendido como para justificar un enfoque automatizado?
No seleccionamos completamente todos los resultados, pero entre las muestras que revisamos identificamos una serie de exposiciones de alto impacto.
lo que encontramos
Tokens del repositorio de código
Los ataques más impactantes que identificamos fueron tokens para plataformas de repositorio de código como GitHub y GitLab. En total, encontramos 688 tokens, muchos de los cuales todavía estaban activos y proporcionaban acceso completo a los repositorios.
En uno de los casos que se muestran a continuación, se incrustó un token de acceso personal de GitLab directamente en un archivo JavaScript. El alcance del token permitía el acceso a todos los repositorios privados dentro de la organización, incluidos los secretos de canalización de CI/CD para servicios de reenvío como AWS y SSH.
Clave API de gestión de proyectos
Otra revelación importante involucró una clave API para Linear, una aplicación de gestión de proyectos, que estaba integrada directamente en el código del front-end:
El token expuso toda la instancia lineal de la organización, incluidos tickets internos, proyectos y enlaces a servicios posteriores y proyectos SaaS.
y mas
Hemos identificado secretos divulgados en una variedad de otros servicios, que incluyen:
API de software CAD – Acceso a datos de usuario, metadatos de proyectos y diseños de edificios, incluido un hospital.
Acortador de enlaces – Capacidad para crear y enumerar enlaces.
Plataformas de correo electrónico – Acceso a listas de correo, campañas y datos de suscriptores
Webhooks para plataformas de chat y automatización – 213 Slack, 2 Microsoft Teams, 1 Discord y 98 Zapier, todos activos
Conversor de PDF – Acceso a herramientas de creación de documentos de terceros.
Plataformas de análisis e inteligencia de ventas – Acceso a la empresa eliminada y a los datos de contacto.
No cuentes tus secretos
El control de desplazamiento a la izquierda es importante. Las protecciones SAST, escaneo de repositorios e IDE detectan problemas reales y evitan que clases enteras se vean comprometidas. Pero como muestra esta investigación, no cubren todos los caminos que un secreto puede seguir hasta su producción.
Los secretos introducidos durante la construcción y la implementación pueden eludir estas protecciones y terminar en el código de front-end mucho después de que los controles de desplazamiento hacia la izquierda ya se hayan ejecutado. Y este problema no hará más que crecer a medida que la automatización y el código generado por IA se vuelvan más comunes.
Esta es la razón por la que es necesario el rastreo de aplicaciones de una sola página para detectar secretos antes de que lleguen a producción. Hemos integrado la detección automática de secretos de SPA en Intruder para que los equipos puedan descubrirlos. Obtenga más información.
About The Author
