Este artículo fue coescrito por Zach Rice y Joe Leon, ambos en Aikido Security.
En resumen: Algunas credenciales están destinadas a ser públicas, pero los escáneres de secretos aún las marcan como secretos genéricos. Escribimos reglas de supresión para las más comunes y redujimos los falsos positivos en aproximadamente un 2%. Estas reglas se incluyen ahora por defecto en Betterleaks.
Los escáneres de secretos se basan en expresiones regulares. Cada patrón se dirige a un tipo de credencial específico, como una clave de acceso secreta de AWS, un PAT de GitHub o un token de Stripe. Una vez que el escáner identifica un secreto potencial, realiza una comprobación de actividad, por ejemplo, enviando una solicitud HTTP para verificar si la credencial está activa.
Este flujo de trabajo se interrumpe cuando los escáneres de secretos intentan identificar secretos genéricos. Los secretos genéricos son las claves API y credenciales que no tienen una firma única o conocida. Los escáneres aún pueden usar una expresión regular para encontrarlos, pero en lugar de buscar una coincidencia con un formato de credencial conocido, utiliza un patrón genérico para recopilar cualquier cosa que parezca que podría ser un secreto.
Reducción del ruido en el escaneo de secretos y el problema con las expresiones regulares
Es bastante fácil escribir una expresión regular sofisticada para identificar cadenas en el código (y otros lugares) que parecen secretos. Pero sin una comprobación de actividad predefinida, el escáner no puede decir definitivamente si un secreto genérico es realmente un secreto activo.
Este enfoque deja a los usuarios la tarea de cribar manualmente los falsos positivos. Pero eso no es divertido. Así que, durante los próximos meses, lanzaremos una serie de capas de reducción de ruido:
- Filtrado de eficiencia de tokens (última publicación)
- Lista negra de credenciales publicables (esta publicación)
- Lista negra de secretos públicos
- Dividir las reglas genéricas en dos tipos: tokens y nombres de usuario/contraseñas
- Triaje asistido por ML
Queremos hacer las cosas en esta secuencia particular porque buscamos eliminar tantos falsos positivos como sea posible al menor coste, y luego usar operaciones de ML costosas para la ambigüedad restante. Nunca será perfecto, pero creemos que los secretos genéricos son donde reside la mayor oportunidad en el escaneo de secretos. Es el mejor lugar para que los investigadores descubran hallazgos novedosos y los defensores superen a los actores 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 escala.
Por qué algunas claves se consideran publicables (no tan secretas)
Muchos proveedores de SaaS y cloud emiten credenciales para usuarios que están diseñadas para ser públicas. Stripe, el procesador de pagos, proporciona a los usuarios múltiples tipos de claves, incluida una "Publishable API key". Estas claves están diseñadas para ser "colocadas en el código front-end".
Una regla genérica de detección de secretos probablemente lo identificaría como un secreto candidato. Tiene alta entropía, 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 de secretos genéricos de Betterleaks.
Pero Stripe es solo un tipo de clave. Necesitábamos escalar 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. Sí, manualmente. La IA fue sorprendentemente inútil para esta tarea.
Reducción de las tasas de falsos positivos entre los secretos genéricos
Después de horas de añadir manualmente estas expresiones, quisimos ver si valía la pena. Para medir el cambio, descargamos 100 GB de Common Crawl y lo escaneamos dos veces con Betterleaks. Una vez con las nuevas firmas, otra sin ellas.
Las nuevas firmas de credenciales publicables redujeron los falsos positivos en un 2,37%. En nuestro conjunto de datos, eso significó 27.886 secretos menos para revisar manualmente.
Cuesta aproximadamente un 5% más de tiempo de escaneo, pero evitar tantos falsos positivos bien lo vale.
Su tasa de reducción variará con los datos que escanee. Common Crawl se inclina hacia HTML y JavaScript de front-end, exactamente donde residen las credenciales publicables, por lo que probablemente infla nuestros resultados. De cualquier manera, cada clave publicable que el filtro elimina es una que un investigador o analista nunca tendrá que clasificar.
Público no siempre significa seguro
El desafío de adoptar este enfoque es que las credenciales publicables no significan necesariamente que no haya riesgo. Cada tipo de clave requiere una revisión manual de la forma de la clave y el acceso concedido a la misma dentro del contexto de la plataforma SaaS. Mientras elaborábamos esta lista, encontramos cinco casos que merecen ser revisados, especialmente para cualquiera que esté considerando enviar un PR para añadir más (¡por favor, hágalo!).
Forma única: fácil
Estos son fáciles. 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 potencialmente válido.
Sin forma única: necesita contexto
Son cadenas que literalmente podrían aparecer en cualquier lugar. Tal vez sea un UUID, o quizás solo 32 caracteres hexadecimales. El formato por sí solo no identifica 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 proveedor de cloud específico.
Este enfoque no es nuevo. Hacemos esto todo el tiempo para las credenciales secretas.
Misma forma que un secreto: necesita una comprobación de actividad
Estos son difíciles. Algunos proveedores de SaaS deciden emitir credenciales secretas y publicables con exactamente el mismo formato. Sinceramente, desearíamos que no hicieran esto. Dificulta la detección de secretos y confunde a los usuarios. Pero nos encontramos con muchos de estos casos.
En estos casos, la única forma de eliminar de forma segura el tipo de clave publicable es añadir una firma de detección (con una solicitud de comprobación de actividad HTTP) para la credencial secreta.
Dado que las claves publicables y secretas tienen la misma forma, la firma de detección de tipo de clave secreta detectaría ambas y, después de una comprobación de actividad, determinaría que la clave publicable no es un secreto y la descartaría.
Sensible solo si está mal configurado: requiere una comprobación de actividad
Existen algunos tipos de claves que los proveedores de SaaS y cloud emiten, donde, dependiendo de si un usuario añadió un permiso específico, la clave podría ser sensible o no presentar riesgo. He escrito bastante sobre las claves API de Google y su capacidad para acceder a Gemini. Ese es un caso. Pero he visto este patrón con las claves de Algolia y otras.
En estas situaciones, el mejor camino a seguir es similar a cuando vemos colisiones de formato entre claves publicables y secretas: enviamos una comprobación de actividad para determinar si puede acceder a algo sensible.
Credenciales de prueba: requiere triaje manual
Algunas plataformas SaaS, como Stripe, proporcionan a los usuarios un entorno de prueba o sandbox. Al principio, consideramos eliminar categóricamente estos resultados de los resultados de detección de secretos genéricos.
Sin embargo, al examinarlo más de cerca, quedó claro que algunas organizaciones ponen datos de producción en sus entornos de prueba. Y aunque una clave de Stripe de sandbox filtrada podría no ser capaz de enviar miles de dólares a la cuenta de un actor de amenazas, podría proporcionar a un actor de amenazas acceso a PII de clientes u otros datos internos importantes. Dado que no podemos saber si una credencial de prueba proporciona acceso a datos internos sensibles, dejamos estos resultados en los hallazgos y confiamos en el triaje manual.
Solucionando la detección genérica de secretos paso a paso
La detección de secretos genéricos es un problema de filtrado, y el filtrado se gana con una serie de pequeñas victorias apiladas una sobre otra. Estamos empezando por eliminar aquello de lo que estamos seguros. Nuestra esperanza es que algunos de estos pequeños cambios permitan una detección efectiva de secretos genéricos a escala.
La versión actual de Betterleaks filtra las claves publicables de los resultados genéricos por defecto. ¡Pruébalo!
