Esta investigación se realizó en colaboración con Harsh Bothra y Luke Stephens de Hackercontent .

Después de analizar un millón de los principales sitios web según Alexa en busca de posibles fugas de información, encontramos una revelación alarmante. Identificamos millas de repositorios de código fuente expuestos y cientos de claves API aún en uso. Aquí están nuestras cinco conclusiones principales:

Exposición pública de 4,500 sitios web altamente visitados: Descubrimos que 4,500 de los sitios web más populares en el mundo tenían sus directorios de Git expuestos públicamente, lo que podría incluir su código fuente completo y privado. Esto podría ser utilizado por posibles atacantes para lanzar ataques contra las aplicaciones web de las víctimas o buscar credenciales activas para servicios de terceros, como AWS.

Con mayor frecuencia, los secretos filtrados más comunes incluyen las claves de acceso a AWS y las claves de GitHub

Las credenciales más comparables filtradas.

Las claves de acceso de AWS y GitHub en conjunto representaron el 45% de todas las credenciales filtradas. La abundancia de tokens de GitHub se explica por su inclusión frecuente en los archivos de configuración de Git durante la clonación de repositorios remotos. Además, una proporción significativa de las credenciales filtradas pertenecen a servicios de marketing por correo electrónico de terceros, como Mailgun, SendInBlue, Mailchimp y Sendgrid.

Es relevante destacar que el 67% de las credenciales de GitHub acceso tenían de administrador. Para confirmar la autenticidad de estas credenciales, TruffleHog realiza una solicitud GET al punto final de la API de GitHub llamado ‘/user’, revelando los permisos otorgados a ese token de acceso personal (PAT), los cuales se encuentran en el encabezado X- Ámbitos de OAuth.

Varios tokens de GitHub tenían privilegios de administrador asignados.

“Después de revisar los permisos otorgados a cada Token de Acceso Personal (PAT) de GitHub válido, encontramos que la mayoría (67%) tenía privilegios de nivel de administrador. Además, todos (100%) tenían permisos de repositorio, lo que significa que un atacante podría realizar acciones arbitrarias en todos los repositorios del usuario víctima, incluyendo la posibilidad de implantar malware en el código.

En otro caso, se descubrió que un sitio web había filtrado la clave privada de su certificado SSL. TruffleHog identificó una clave RSA privada y luego utilizó la herramienta de verificación de uso de claves privadas llamada Driftwood para confirmar que la clave RSA correspondía al certificado TLS de ese dominio.

Comprobación de la clave privada TLS de un sitio web

Los posibles atacantes podrían haber aprovechado esta clave privada para llevar a cabo un ataque de intermediario y realizar otras acciones maliciosas contra el dominio en cuestión.

Variación en la Exposición de Directorios Git entre Diferentes Organizaciones

Notamos que la exposición de directorios Git variaba entre organizaciones en dos rondas de investigación realizadas con un mes de diferencia en la misma lista de un millón de sitios web. La primera ronda reveló 255 claves filtradas, mientras que la segunda mostró 97 claves filtradas. Esta discrepancia se debe al flujo natural de vulnerabilidades: algunos sitios web eliminaron sus directorios .git, mientras que otros revelaron nuevas claves.

Si realizamos un estudio similar en el futuro, es probable que obtuviéramos resultados diferentes. Sin embargo, es probable que sigamos identificando cientos de claves filtradas como mínimo.

¿Un directorio Git?

Se crea al iniciar un repositorio Git y contiene información esencial de control de versiones, como confirmaciones de código, mensajes de confirmación, rutas de archivos y más. En esencia, es la “plomería” que sustenta un repositorio de código fuente. Sin embargo, exponer públicamente este directorio puede dar a los atacantes acceso a:

1. Código fuente completo: Esto incluye el código fuente del proyecto, incluyendo algoritmos propietarios, software personalizado y secretos comerciales.
2. Archivos de configuración: Los archivos en “.git/CONFIG” a menudo contienen información sensible, como contraseñas del repositorio de Git.
3. Historial de confirmaciones: El historial de confirmaciones del repositorio puede revelar errores pasados ​​de una organización y detalles sobre servicios internos.
4. Credenciales de acceso: Si las credenciales se almacenan en el directorio “.git”, una copia también se guarda ahí. Los atacantes pueden utilizar estas credenciales para acceder a sistemas y datos. Por lo general, los atacantes buscan credenciales en confirmaciones anteriores.

Detectar Directorios Git Accesibles Públicamente

Iniciar la búsqueda de directorios Git en una lista de sitios web públicos al principio parecía ser una tarea directa. Sin embargo, resultó ser más complejo que simplemente enviar solicitudes HTTP GET a “/.git” y registrar todas las respuestas HTTP 200. Esto se debió a que muchos de los sitios web incluidos en los primeros 1 millón según Alexa empleaban un Firewall de Aplicaciones Web (WAF) que generaba resultados impredecibles. Además, algunos sitios devolvían una respuesta HTTP 403 (Prohibido) al acceder a la ruta “/.git”, pero aún así era posible obtener acceso a todos los subdirectorios y archivos dentro de la carpeta “/.git”.

Para superar este desafío, nuestro equipo de investigación revisó la documentación oficial de Git y realizó que la forma más confiable de identificar un directorio Git válido era buscar el archivo “.git/CONFIG”. Por lo tanto, procedimos a solicitar el archivo de configuración Git de cada sitio web (por ejemplo, https://dominio.com/.git/config ) y luego comprobamos la primera línea de texto para asegurarnos de que se tratara de un archivo. Git CONFIG auténtico.

Ejemplo de Configuración Git con Credenciales en Texto Plano

Reconstrucción del Código Fuente del Proyecto

Descargar un repositorio Git completo parecía ser una tarea sencilla al principio (simplemente con el comando ‘git clone’, ¿verdad?). Sin embargo, nos enfrentamos a diversos desafíos, incluyendo repositorios corruptos y situaciones excepcionales. Para abordar la reconstrucción y clonación de estos repositorios Git en nuestra máquina local, optamos por utilizar la herramienta de código abierto llamada Goop. Descubrimos que Goop ofrece una variedad de funciones y es altamente eficiente en su desempeño.

Ejecutar Goop es sumamente sencillo, solo se requiere pasar la URL del repositorio como único argumento en la línea de comandos.

Logrando una Ejecución Exitosa con Goop

Uso de TruffleHog para detectar información confidencial en repositorios Git

TruffleHog realiza un escaneo exhaustivo de repositorios Git y otras fuentes para identificar información confidencial, como contraseñas, tokens y claves. Cuando TruffleHog detecta un secreto (en la actualidad, puede identificar aproximadamente 750 tipos diferentes de secretos), realiza un intento de autenticación utilizando esa credencial.Esto proporciona a los usuarios una alta confianza de que cualquier secreto marcado como ‘verificado’ está en uso, ya que se ha utilizado para autenticar.

Si bien en la mayoría de los casos recomendamos utilizar el comando ‘gitsub’ en repositorios Git, en ocasiones, cuando los repositorios están dañados, utilizamos una combinación de comandos del sistema de archivos y Git. Los siguientes pasos detallan cómo ejecutar TruffleHog en un directorio Git expuesto:

1. Ejecute el comando ‘TruffleHog filesystem’ (o ‘git’) en el directorio local de Git”.

2. Cuando se realiza el análisis y se detectan secretos expuestos, notará que todos los resultados verificados están marcados en verde, mientras que los resultados no verificados se muestran en gris. La verificación de un resultado significa que TruffleHog pudo autenticarse con éxito en el servicio en cuestión utilizando la credencial detectada. Es esencial comprender que un resultado no verificado no necesariamente descarta la posibilidad de que la clave sea activada; Simplemente indica que TruffleHog no logró autenticarse con éxito en el servicio de terceros correspondiente.

Autenticación de claves de AWS en TruffleHog: Verificadas y No Verificadas

Para visualizar únicamente los secretos marcados como ‘verificados’, vuelva a ejecutar el comando anterior con la opción ‘–only-verified’ activada.

Mostrar solo las claves autenticadas en TruffleHog

Informe Ético de Vulnerabilidades

Después de identificar y verificar un secreto expuesto, nuestro equipo de investigación se embarcó en el proceso de contacto con los propietarios de los sitios web afectados, lo cual resultó ser la parte más laboriosa de nuestra investigación. Para la mayoría de los sitios web, seguimos estos cuatro pasos:

1. Búsqueda de direcciones de correo electrónico válidas en el historial de Git: En el historial de Git, la identidad, incluida la dirección de correo electrónico, se asocia a los cambios de código. Sin embargo, lamentablemente, muchos de los sitios web tenían repositorios de Git corruptos, lo que dificultó la reconstrucción del historial de Git y la identificación de contactos adecuados a gran escala.
2. Búsqueda en WHOIS: Intentamos buscar información en WHOIS, pero la mayoría de las organizaciones utilizaban registros privados, lo que limitaba la utilidad de esta búsqueda.
3. Adivinanza de direcciones de correo electrónico basada en roles (por ejemplo, seguridad@dominio, info@dominio): Aunque no es un enfoque perfecto, muchas organizaciones tienen al menos una dirección de correo electrónico basada en funciones. Probamos de manera rutinaria con direcciones como security@ e info@, a menos que tuviéramos razones para intentar con otras (por ejemplo, seguridad@ para un sitio web con sede en España).
4. Confianza en configuraciones de correo electrónico general: Algunos servicios de correo electrónico implementan una política general en la que los correos electrónicos enviados a un usuario inexistente se redirigen a una bandeja de entrada general. Sin embargo, este método es menos efectivo y puede hacer que nuestros mensajes parezcan spam.

Fuente: trufflesecurity