Las filtraciones de claves API ya no son infrecuentes, al igual que las infracciones posteriores. Entonces, ¿por qué los tokens sensibles siguen estando expuestos tan fácilmente?
Para averiguarlo, el equipo de investigación de Intruder investigó qué cubren realmente los escáneres de vulnerabilidades tradicionales y creó un nuevo método de detección secreto para abordar las lagunas en los enfoques existentes.
La aplicación de esto a escala mediante el escaneo de 5 millones de aplicaciones reveló más de 42 000 tokens expuestos en 334 tipos de secretos, exponiendo una clase importante de secretos expuestos que no son bien manejados por las herramientas existentes, en particular las aplicaciones de una sola página (SPA).
Este artículo detalla los métodos de detección de secretos existentes y revela lo que encontramos al escanear millones de aplicaciones en busca de secretos ocultos en paquetes de JavaScript.
Métodos de detección de secretos establecidos (y sus limitaciones)
Detección de secretos tradicional
Un enfoque tradicional y totalmente automatizado para descubrir secretos de aplicaciones es buscar en un conjunto de rutas conocidas y aplicar una expresión regular que coincida con el formato secreto conocido.
Aunque este método es útil y puede detectar algunas fugas, tiene limitaciones obvias y no puede detectar todos los tipos de fugas, especialmente aquellas que requieren análisis de aplicaciones o autenticación a través de escáneres.
Un buen ejemplo de esto es la plantilla de token de acceso personal GitLab de Nuclei. El escáner se suministra con una URL base (por ejemplo, https://portal.intruder.io/) y la plantilla tiene este aspecto:
Realice una solicitud HTTP GET a https://portal.intruder.io/. Inspeccione la respuesta directa a esa solicitud, ignorando otras páginas, archivos JavaScript y otros recursos. Intenta identificar patrones en los tokens 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, plantee el problema.
Obviamente, este es un ejemplo simple, pero este enfoque es efectivo. Esto es especialmente cierto si la plantilla define muchos caminos a través de los cuales los secretos se exponen públicamente.
Este formato es típico de los escáneres de infraestructura, que normalmente no ejecutan navegadores sin cabeza. Una vez que el escáner recibe una URL base para escanear (como https://portal.intruder.io), las solicitudes posteriores realizadas por el navegador (como los archivos JavaScript necesarios para representar la página, como https://portal.intruder.io/assets/index-DzChsIZu.js) no se realizan con este enfoque antiguo.
Pruebas dinámicas de seguridad de aplicaciones (DAST)
Las herramientas de prueba dinámica de seguridad de aplicaciones (DAST) son generalmente un método más sólido para escanear aplicaciones y tienden a tener características más complejas, lo que permite un análisis completo de las aplicaciones, soporte para autenticación y capacidades más amplias para detectar debilidades en la capa de aplicaciones. De hecho, los escáneres DAST pueden parecer una opción natural para la detección de secretos en las interfaces de aplicaciones. No hay nada que impida que el escáner DAST descubra archivos JavaScript disponibles o busque secretos dentro de ellos.
Sin embargo, este tipo de escaneo es más caro, requiere una configuración cuidadosa y, en la práctica, suele reservarse para unas pocas aplicaciones de alto valor. Por ejemplo, es poco probable que los escáneres DAST se configuren para todas las aplicaciones que existen en una amplia gama de activos digitales. Además, muchas herramientas DAST no implementan una gama suficiente de expresiones regulares en comparación con las herramientas de línea de comandos conocidas.
Esto crea una brecha obvia que deberían cubrir los escáneres de infraestructura tradicionales, pero no lo hacen. También es probable que ni siquiera un escáner DAST lo cubra 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) son el método principal para analizar el código fuente para identificar vulnerabilidades y descubrir secretos antes de que el código llegue a producción. Son eficaces para capturar credenciales codificadas y evitar la filtración de algunas clases.
Sin embargo, descubrimos que el método SAST tampoco cubría el panorama completo. Además, algunos secretos del paquete de JavaScript se estaban escapando de una manera que el análisis estático pasaba desapercibido.
Cree comprobaciones de detección de secretos para paquetes de JavaScript
Cuando comenzó este estudio, no estaba claro qué tan común era este problema. ¿Están realmente incluidos los secretos en las interfaces de JavaScript y están lo suficientemente extendidos como para justificar un enfoque automatizado?
Para averiguarlo, creamos controles automatizados y escaneamos aproximadamente 5 millones de solicitudes. El resultado fue un número de exposiciones mucho mayor de lo esperado. Solo el archivo de salida tenía más de 100 MB de texto sin formato y contenía más de 42.000 tokens en 334 secretos diferentes.
Aunque no evaluamos completamente todos los resultados, identificamos una serie de exposiciones de alto impacto entre las muestras que revisamos.
lo que encontramos
token del repositorio de código
Las infracciones más impactantes que identificamos fueron tokens para plataformas de repositorio de código como GitHub y GitLab. Se encontraron un total de 688 tokens, muchos de los cuales todavía estaban activos y permitían acceso completo al repositorio.
En un caso, que se muestra a continuación, se incrustó un token de acceso personal de GitLab directamente en un archivo JavaScript. El alcance del token se estableció para permitir el acceso a todos los repositorios privados dentro de la organización, incluidos los secretos de canalización de CI/CD para servicios de seguimiento como AWS y SSH.
Clave API de gestión de proyectos
Otra exposición importante involucró las claves API para Linear, una aplicación de gestión de proyectos integrada directamente en el código de interfaz de usuario.
Este token expuso toda la instancia Linear de su organización, incluidos tickets internos, proyectos y enlaces a servicios posteriores y proyectos SaaS.
Más información
Hemos identificado secretos filtrados en una amplia gama de otros servicios, incluidos:
API de software CAD: acceso a datos de usuario, metadatos de proyectos y diseños de edificios, incluidos hospitales
Acortador de enlaces: capacidad de crear y enumerar enlaces
Plataforma 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
PDF Converter: acceso a herramientas de generación de documentos de terceros
Plataforma de análisis e inteligencia de ventas: acceso a datos de contacto y de empresa extraídos
no revelar secretos
El control Shift-Izquierda es importante. SAST, escaneos de repositorios y barreras de seguridad IDE detectan problemas reales y evitan cualquier tipo de exposición. Sin embargo, como muestra esta investigación, no cubre todos los caminos posibles para que los secretos se introduzcan en la producción.
Los secretos introducidos durante la construcción y la implementación pueden eludir estas salvaguardas e incorporarse al código de interfaz mucho después de que el control de desplazamiento a la izquierda ya se esté ejecutando. Y a medida que la automatización y el código generado por IA se vuelvan más comunes, este problema será aún mayor.
Por lo tanto, se requiere un rastreo de aplicaciones de una sola página para capturar secretos antes de que lleguen a producción. Construimos una detección automatizada de secretos de SPA en Intruder para que los equipos puedan descubrirlo. aprender más.
Source link
