Este artículo ha sido escrito en colaboración con Zach Rice y Joe Leon, ambos de Aikido Security.
En resumen: algunas credenciales están pensadas para ser públicas, pero los escáneres de secretos siguen marcándolas como secretos genéricos. Hemos creado reglas de supresión para las más comunes y hemos reducido los falsos positivos en aproximadamente un 2 %. Estas reglas ahora se incluyen de forma predeterminada en Betterleaks.
Los escáneres de secretos se basan en expresiones regulares. Cada patrón se centra en un tipo específico de credencial, como una clave de acceso secreta de AWS, una PAT de GitHub o un token de Stripe. Una vez que el escáner identifica un posible secreto, realiza una comprobación de validez, por ejemplo, enviando una solicitud HTTP para verificar si la credencial está activa.
Este flujo de trabajo falla cuando los escáneres de secretos intentan identificar secretos genéricos. Los secretos genéricos son las claves de API y las credenciales que no tienen una firma única o conocida. Los escáneres pueden seguir utilizando una expresión regular para encontrarlos, pero en lugar de buscar coincidencias con un formato de credencial conocido, utilizan un patrón genérico para recopilar cualquier elemento que parezca que podría ser un secreto.
Reducción del ruido en escaneo de secretos el problema con las expresiones regulares
Es bastante fácil escribir una expresión regular sofisticada para detectar cadenas en el código (y en otros lugares) que parezcan secretos. Pero sin una comprobación de vigencia predefinida, el escáner no puede afirmar con certeza si un secreto genérico es realmente un secreto vigente.
Este enfoque obliga a los usuarios a revisar manualmente los falsos positivos. Pero eso no es nada divertido. Por eso, a lo largo de los próximos meses, vamos a lanzar una serie de capas de reducción de ruido:
- Filtrado por eficiencia de tokens (última publicación)
- Lista negra de credenciales publicables (esta entrada)
- Lista de exclusión de secretos públicos
- División de las reglas genéricas en dos tipos: tokens y nombres de usuario/contraseñas
- Triaje asistido por aprendizaje automático
Queremos seguir este orden concreto porque nuestro objetivo es eliminar el mayor número posible de falsos positivos con el menor coste posible y, a continuación, utilizar operaciones de aprendizaje automático más costosas para resolver la ambigüedad restante. Nunca será perfecto, pero creemos que los secretos genéricos son donde reside la mayor oportunidad en escaneo de secretos. Es el mejor ámbito para que los investigadores descubran hallazgos novedosos y para que los defensores se adelanten a los autores de amenazas. El objetivo de esta serie es hacer que las reglas predeterminadas de Betterleaks sean lo suficientemente buenas como para permitir a los investigadores y analistas clasificar los resultados de secretos genéricos a gran escala.
¿Por qué se considera que algunas claves son «publicables» (es decir, no tan secretas)?
Muchos proveedores de SaaS y de servicios en la nube generan credenciales para los usuarios que están pensadas para ser públicas. Stripe, el procesador de pagos, ofrece a los usuarios varios tipos de claves, entre ellas una «clave API publicable». Estas claves están pensadas para «incluirse en el código front-end».
Es probable que una regla genérica de detección de secretos identifique esto como un posible secreto. Tiene una entropía elevada, se encuentra cerca de palabras clave como «api_key» y, en general, parece una credencial. Pero no es un secreto real. Está destinado a ser público y no es algo en lo que un investigador o analista deba perder el tiempo revisando manualmente.
Así que escribimos una expresión regular para eliminar este tipo de clave de los resultados genéricos de secretos de Betterleak.
Pero Stripe es solo un tipo de clave. Necesitábamos ampliar este proceso. Investigamos los tipos de credenciales «públicas por diseño» más populares y creamos manualmente firmas de detección para cada una de ellas. Sí, manualmente. La IA resultó ser sorprendentemente inútil para esta tarea.
Reducción de las tasas de falsos positivos entre los secretos genéricos
Tras pasar horas añadiendo estas expresiones manualmente, queríamos comprobar si merecía la pena. Para evaluar el cambio, descargamos 100 GB de Common Crawl y los analizamos dos veces con Betterleaks: una vez con las nuevas firmas y otra sin ellas.
Las nuevas firmas de credenciales publicables reducen los falsos positivos en un 2,37 %. En nuestro conjunto de datos, eso supuso 27 886 secretos menos que revisar manualmente.
Supone un aumento del tiempo de análisis de aproximadamente un 5 %, pero evitar tantos falsos positivos merece mucho la pena.
Tu tasa de reducción variará en función de los datos que escanees. Common Crawl se centra principalmente en el HTML y el JavaScript del front-end, que es precisamente donde se encuentran las credenciales publicables, por lo que es probable que esto exagere nuestros resultados. En cualquier caso, cada clave publicable que el filtro elimina es una que un investigador o analista nunca tendrá que evaluar.
Que algo sea público no siempre significa que sea seguro
El problema de adoptar este enfoque es que el hecho de que las credenciales sean públicas no significa necesariamente que no haya riesgo. Cada tipo de clave requiere una revisión manual de su estructura y del acceso que se le concede en el contexto de la plataforma SaaS. Al elaborar esta lista, nos hemos encontrado con cinco casos que merece la pena analizar, sobre todo para quienes estén pensando en enviar una solicitud de incorporación de cambios (¡por favor, hacedlo!) para añadir más.
Forma única: fácil
Esto es sencillo. La credencial publicable tiene una forma única e inconfundible. Escribimos una expresión regular única y estamos seguros de que esto no excluirá ningún secreto genérico que pueda ser válido.
No tiene una forma concreta: depende del contexto
Se trata de cadenas que, literalmente, podrían aparecer en cualquier parte. Puede tratarse de un UUID o simplemente de cualquier secuencia de 32 caracteres hexadecimales. El formato por sí solo no permite identificar esta cadena como un tipo de credencial publicable. En estos casos, nos basamos en una palabra clave cercana que confirme que pertenece a una plataforma SaaS o a un proveedor de servicios en la nube concretos.
Este enfoque no es nuevo. Lo hacemos constantemente con las credenciales secretas.
Tiene la misma forma que un secreto: hay que comprobar que sigue activo
Esto es complicado. Algunos proveedores de SaaS deciden generar credenciales secretas y públicas con exactamente el mismo formato. Sinceramente, preferiríamos que no lo hicieran. Dificulta la detección de credenciales secretas y confunde a los usuarios. Pero nos hemos encontrado con muchos casos así.
En estos casos, la única forma de eliminar de forma segura el tipo de clave punible es añadir una firma de detección (mediante una solicitud de comprobación de actividad HTTP) para la credencial secreta.
Dado que las claves publicables y secretas tienen la misma estructura, la firma de detección del tipo de clave secreta detectaría ambas y, tras una comprobación de vitalidad, determinaría que la clave publicable no es secreta y la descartaría.
Solo es vulnerable si está mal configurado: requiere una comprobación de estado activo
Hay algunos tipos de claves que generan los proveedores de SaaS y de servicios en la nube en los que, dependiendo de si un usuario ha añadido un permiso concreto, la clave puede ser sensible o no presentar ningún riesgo. He escrito bastante sobre las claves de la API de Google y su capacidad para acceder a Gemini. Ese es un caso. Pero he observado este patrón con las claves de Algolia y otras.
En estas situaciones, el mejor procedimiento a seguir es similar al que seguimos cuando se producen conflictos de formato entre las claves de publicación y las claves secretas: enviamos una comprobación de actividad para determinar si puede acceder a información confidencial.
Credenciales de prueba: requieren una evaluación manual
Algunas plataformas SaaS, como Stripe, ofrecen a los usuarios un entorno de prueba o «sandbox». Al principio, nos planteamos eliminar por completo estos resultados de los resultados generales de detección de secretos.
Sin embargo, al analizarlo más detenidamente, quedó claro que algunas organizaciones introducen datos de producción en sus entornos de prueba. Y aunque es posible que una clave de Stripe filtrada en un entorno de pruebas no permita enviar miles de dólares a la cuenta de un actor malintencionado, sí podría proporcionarle acceso a la información de identificación personal (PII) de los clientes u otros datos internos importantes. Dado que no podemos saber si una credencial de prueba da acceso a datos internos confidenciales, incluimos estos resultados en las conclusiones y nos basamos en una clasificación manual.
Solucionar detección de secretos genérica detección de secretos a paso
La detección genérica de secretos es un problema de filtrado, y el filtrado se consigue mediante una serie de pequeños avances que se van sumando unos a otros. Empezamos por eliminar aquello de lo que estamos seguros. Esperamos que algunos de estos pequeños cambios permitan una detección genérica de secretos eficaz a gran escala.
La versión actual de Betterleaks filtra, de forma predeterminada, las claves que se pueden publicar de entre los resultados genéricos. ¡Pruébala!
