Qué aprendimos sobre la seguridad de secretos en el AppSec Village en DEF CON 32

Si creciste en los Estados Unidos, es probable que tengas recuerdos de ir a un campamento de verano. Incluso si no asististe a uno mismo, la experiencia del campamento de ir lejos de casa, aprender todo tipo de artes y oficios, conocer nuevos mejores amigos y emprender aventuras memorables está integrado en la cultura popular y los medios. Cada agosto, se celebra en el calor de Las Vegas el mayor campamento de hackers del mundo. Este año marcó la treinta segunda iteración de DEF CON.

Es difícil explicar DEF CON sin haberlo experimentado. Sí, hay tracks de charlas, talleres oficiales y varios capture-the-flags (CTFs), pero hay mucho más. Ninguna otra conferencia contiene tantas sub-conferencias y eventos dirigidos por la comunidad. Incluso los asistentes que han ido durante años dicen que aún no creen que hayan experimentado todo lo ofrecido.

Aunque no hay un número oficial publicado por los organizadores, eventos anteriores han variado entre 25.000 y 30.000 asistentes. Cada asistente trae con ellos un amor por la tecnología y mucho conocimiento para compartir. Las pasillos están llenos de personas que hacen hacks en hardware, escriben software, hacen música, comparten stickers y hacen que todo el funcionamiento de DEF CON sea divertido.

Los Villages

Hubo 33 pueblos dentro de DEF CON 32. Estos abarcan una amplia diversidad de intereses, desde el hacking aeronáutico, ingeniería social y desinformación hasta equipos rojos y aplicaciones seguras. Cada pueblo está organizado de manera independiente y ofrece un conjunto único de charlas, talleres y actividades prácticas para que los asistentes puedan interactuar con el área específica de su interés.

Pueblo Aplicaciones Seguras fue un espacio valioso dentro de la comunidad mayoritaria de hacking y seguridad que se enfoca en defender las aplicaciones que impulsan todas nuestras vidas. Tu autor fue una de las personas afortunadas que ayudó a organizar y a dirigir Pueblo Aplicaciones Seguras 2024.

Espía los Secretos 

Regresando al Pueblo Aplicaciones Seguras en la RSA Conference 2024, GitGuardian reveló nuestro juego Espía los Secretos, un juego de cartas que simula la experiencia de revisión de código manual para encontrar credenciales en claro. Los jugadores son invitados a competir para encontrar todas las API ocultas, contraseñas y otros secretos en claro que los atacantes podrían utilizar para obtener acceso adicional a una colección de muestras de código, tickets de Jira, archivos de registro y mensajes de Slack.

Espía los Secretos en el Pueblo Aplicaciones Seguras, editado para tener en cuenta las reglas de fotografía de DEF CON

En DEF CON, durante 2 días, pasaron por nuestro POD en AppSec Village más de 120 personas para experimentar personalmente este ejercicio. Incluso tuvimos una tabla de clasificación donde los jugadores más rápidos, que cometieron menos errores, ganaron premios especiales de regalos.

Preguntas Más Comunes Sobre las Preguntas de Seguridad secretas

Cuando las personas comenzaron a examinar las cartas que contenían el código, tuvimos todo tipo de preguntas. Creemos que sería beneficioso compartir algunas de estas preguntas en caso de que ustedes, también, no hayan escuchado respuestas a estas preguntas todavía.

Aquí están las 11 preguntas más comunes que oímos y nuestras respuestas.

1. ¿Qué es exactamente un commit?

Un commit es una unidad de trabajo en Git, el sistema de control de versiones utilizado por más del 97% de los desarrolladores globales. Es una instantánea del sistema de archivos en un momento determinado de tiempo, abarcando todo el trabajo que el desarrollador ha hecho desde el último commit. Si se alignan commit after commit, obtienes la historia de Git, que te permite examinar cada cambio incremental realizado en toda la vida del código base. Uno de los desafíos secretos de seguridad de utilizar Git es que la historia es un registro永久 compartido. Si se agrega un secreto a un commit y se elimina en el siguiente commit, el commit con el secreto aún se mantiene.

2. ¿Cómo puedes saber si algo es un secreto?

Un secreto es cualquier credencial que da acceso directo a un sistema o datos. Estos pueden adoptar la forma de las keys de API, contraseñas, certificados y tokens, entre otros. Parte de la razón por la que son difíciles de detectar es que se utilizan de muchas maneras dentro de código y desde la línea de comandos. Por ejemplo, dentro de un archivo de configuración, una variable específica podría establecerse para una key de API. Sin embargo, para sistemas como Slack, el token de API está integrado en la URL en sí misma, lo que significa que necesitarías ser familiar con ese sistema para saber que es un secreto.

Muchos sistemas utilizan números largos y únicos en sus URLs de interfaz de usuario, que pueden parecerse muy de cerca a tokens en línea. Por ejemplo, las URLs de Figma pueden parecer contener una cadena codificada en base64 en la ruta. Sin embargo, si sigues un enlace de Figma aleatorio, se te presentará una pantalla de inicio de sesión, ya que necesitas ser un usuario autenticado para conectarte a esa página. Dado que no otorga acceso al sistema automáticamente sino que simplemente identifica la ubicación de la página, un atacante sin un punto de apoyo en Figma devolvería el error “Sin Acceso” y seguiría andando. Esta es otra razón para adoptar herramientas para identificar secretos, ya que hay plataformas que pueden rápidamente determinar la diferencia entre una URL que contiene un token de autorización y una que solo parece que podría.

3. ¿Qué significa “Válido”?

Válido, en nuestro uso, significa que una credencial particular todavía funciona para otorgar acceso al sistema o datos relacionados. Si un atacante la encuentra, una secreta válida podría ser utilizada inmediatamente. Mientras que secretos no válidos pueden dar a un atacante una idea de la arquitectura general y los sistemas interconectados, solo los secretos válidos le ofrecen un camino directo a esas recursos. Estos tipos de movimientos laterales pueden ser difíciles de detectar.

4. ¿Cómo Se supone que debo saber cuáles son las secretas correctas para buscar?

La mejor respuesta es encontrar y eliminar cualquier secreto válido. Sin embargo, como demuestra Spot the Secrets, esto es un problema difícil de resolver sin las herramientas correctas. Revisar manualmente el código o herramientas que dependen exclusivamente de coincidencias de patrón simple pueden hacer que gastes tiempo corrigiendo secretos ya invalidados en lugar de centrarte en los válidos. Las claves vencidas no representan gran amenaza, así que los esfuerzos para eliminarlas deben tener una prioridad menor que cualquier credencial válida que descubras.

5. ¿Qué diferencia hay entre un secreto y simplemente un código mal escrito?

Los atacantes casi nunca leen tu código; están escaneando por maneras específicas de obtener acceso más amplio lo antes posible. El código mal escrito puede contener muchas vulnerabilidades que un atacante puede aprovechar, especialmente en la configuración de “Infrastructure as Code”. Sin embargo, aprovechar estos defectos requiere que un atacante tome el tiempo para entender el defecto y ejecutar un ataque específico contra esos problemas en lugar de simplemente utilizar credenciales en texto plano.

Los nombres de variables y los nombres de usuario pueden ser usados como parte de un ataque más elaborado. Por ejemplo, los nombres de usuario y correos electrónicos encontrados en el código pueden ser usados en ataques de spray de contraseñas o intentos de fuerza bruta, pero estos son mucho más fáciles de detectar que el uso directo de secretos y consume mucho tiempo para el atacante.

6. ¿Pero Qué Hago con Esto una vez que Encuentro un Secreto?

Ante todo, detén y respira. Esto pasa a los mejores de nosotros, así que no te preocupes demasiado si encuentras un secreto filtrado. Es bueno actuar con urgencia, pero no te pases de nervios y revoca un secreto encontrado sin saber qué ocurrirá. Esto puede causar una multitud de otras problemáticas.

Recomendamos seguir el siguiente camino:

1. Comprender qué cosa desbloquea el secreto.
2. Averiguar qué tan crítico es cualquier información asociada o sistema.
3. Revisar tus registros para detectar el uso no autorizado del secreto.
4. Determinar si se ha filtrado acceso a cualquier dato o servicio.
5. Saber qué se romperá cuando rotes el secreto.
6. Rotar el secreto y almacenar las nuevas credenciales de forma segura.
7. Arreglar cualquier flujo de trabajo o despliegue de producción que se haya roto.
8. Revisar el incidente y crear un plan de acción para evitar una futura filtración de secretos.

Lee más sobre el proceso de corrección en el artículo “Qué Hacer si Exposas un Secreto: Cómo permanecer calmado y responder a un incidente“.

7. Mi Equipo Siempre Reescribe el Historial de Git Cuando se Descubre un Secreto. ¿Es todo lo que Necesitamos Hacer?

Lamentablemente, no. Si bien nos encantaría la etapa de limpieza de Git del proceso de corrección, en realidad es la última etapa y muchas organizaciones la consideran opcional. Recomendamos rotar cualquier secreto que haya sido expuesto como texto plano (ver el enlace arriba para consejos sobre el proceso de corrección).

8. ¿No es suficiente eliminar el repositorio de público?

Honestamente, nos gustaría que esto fuera así, pero por desgracia para todos nosotros, una vez que se expone en GitHub públicamente, siempre debe considerarse comprometido. GitGuardian escanea cada nuevo commit y cada evento de isPublic que ocurre en la API pública de GitHub.

Esa es la forma en que creamos nuestro informe anual Estado de la Extensión de Secretos y la base de la oferta de Monitoreo Público de GitGuardian. Aunque nuestras intenciones son alertar a los autores de los commits de que han hecho algo potencialmente peligroso, no somos los únicos actores que monitorean esta API pública. Siempre deberíais suponer que hay una copia de cualquier código o archivos que hayan publicado nunca, hecha por alguien que no conocen, y almacenada en algún lugar que no conocen. Siempre recomendamos rotar cualquier secreto potencialmente expuesto.

9. ¿Por qué son problemáticos los falso positivos?

En nuestro ejercicio Spot the Secrets, le pedimos a los usuarios que encuentren todos los secretos colocados dentro de 100 posibles commits, Jira, Slack y tarjetas de Log, imponiendo una penalti de tiempo por cada falso positivo. Cualquier tarjeta en la que el jugador creyera falsamente que contenía un secreto cuando no lo hacía incurrería en una penalti de 10 segundos por error.

Mientras que en el limitado alcance del ejercicio, podría parecer una buena idea ser extremadamente cauteloso y marcar cosas que no contienen secretos, en toda realidad, supone un desperdicio de tiempo valioso, tanto para ti, el informador, como para cualquier persona que tenga la tarea de trabajar en una solución.

Cualquier herramienta o proceso que informe demasiados falsos positivos lleva a la fatiga de alertas. Los usuarios se inundan de alertas y comienzan a ignorarlas. Esto lleva a la desconfianza de las herramientas y un uso inconsistente. También puede atascar el proceso de corrección global y significar que algunos secretos positivos reportados no se atienden a tiempo.

10. ¿Qué tiene que ver el nombre de archivo con la identificación de un secreto?

En resumen: contexto. Los secretos generales pueden ser especialmente difíciles de encontrar solo mediante el análisis de patrones. Si hay una cadena larga en un archivo markdown, nuestros hallazgos indican una alta probabilidad de que sea una contraseña de ejemplo, por lo que probablemente no tendrías que lidiar con ella. Si, por otro lado, esa misma cadena aparece después de la cadena password= en un archivo llamado project.env, entonces hay una probabilidad mucho mayor de que tengas un secreto real en tu mano.

El nombre de archivo es solo uno de los elementos que consideramos con Pre- y Post Validación en el Motor de Detección de Secretos de GitGuardian y es uno de los factores que nos ayuda a eliminar falsos positivos internos a la plataforma FP remover.

11. ¿Realmente la gente realiza revisiones de código manuales para encontrar secretos?

Sí. Un 27% completo de los responsables de decisiones de TI que nosotros surveyearon dijeron que confían en las revisiones de código manuales para corregir la expansión de secretos, incluso a pesar de que un 75% dijo que habían sido afectados por una filtración de secretos.

Spot the Secrets fue diseñado para mostrar los problemas de confiar en humanos para detectar estos problemas. Las máquinas son mucho mejores en la detección de patrones a través de miles o millones de líneas de código.

Aprender juntos es de lo que se trata DEF CON

Aprendimos muchas lecciones en DEF CON, incluyendo mantenernos hidratados, conseguir al menos unas pocas horas de sueño por noche y permanecer dentro cuando afuera hace más de 110°F/43°C.

Hubo muchas charlas excelentes en el programa; no podemos esperar que las videos estén disponibles para recuperar el contenido que perdemos mientras ayudábamos a la gente a aprender sobre la Expansión de Secretos. Durante el proceso, aprendimos mucho sobre cómo la gente de seguridad, los desarrolladores y la gente en general ve este problema y cómo piensa en soluciones. GitGuardian espera integrar esas lecciones para hacer que la solución de este problema sea más accesible y fácil para todos nosotros.

Si nunca has considerado ir a DEF CON, lo recomendamos encarecidamente, incluso si solo por participar en el AppSec Village y encontrar a tu tribu en la escuela de verano de los hackers.