Las direcciones de correo electrónico expuestas del proyecto GitLab permiten a los atacantes enviar código

La dirección de correo electrónico privada de GitLab que permite a los desarrolladores impulsar problemas o trabajar en un proyecto se expone intencionalmente en el archivo README, la guía para colaboradores y las páginas de soporte que se utilizan para recopilar informes de errores.

Las direcciones son parte de una característica incorporada de GitLab llamada “Elementos de trabajo de correo electrónico para este proyecto” y contienen un token de larga duración vinculado a la cuenta del desarrollador.

Estas direcciones se generan automáticamente y contienen una cadena que sirve como calificador para crear elementos de trabajo por correo electrónico. Cuando un cliente externo envía un mensaje a uno de ellos, GitLab lo analiza en un problema de proyecto o tarea.

Los investigadores de la empresa de seguridad de aplicaciones Aikido encontraron varias direcciones privadas de GitLab expuestas en documentos públicos y advirtieron sobre los riesgos asociados.

Un atacante puede usarlos para comprometer cuentas de GitLab en ataques que envían código a ramas protegidas en repositorios privados, roban código fuente, recopilan secretos de variables CI/CD u obtienen acceso a problemas confidenciales.

Cada una de estas direcciones privadas de GitLab incorpora un código ‘glimt-‘ que actúa como una credencial para acceder al proyecto, que persiste en todas las direcciones similares generadas para el proyecto respectivo.

“Cambie el sufijo -issue en la dirección de correo electrónico a -merge-request y GitLab abrirá una solicitud de fusión”, dice Aikido.

Un atacante que conozca esta dirección o pueda recuperarla podría cambiar el sufijo ‘-issue’ a ‘solicitud-solicitud’, y GitLab lo aceptaría, abriendo una solicitud de fusión en el proyecto.

“En principio, verificar que la dirección de envío coincida con el correo electrónico del propietario del token agregaría una capa de defensa, pero GitLab no lo hace (aunque actualmente lo están considerando)”, dicen los investigadores.

“Cualquier buzón de Internet puede enviar a esta dirección y GitLab trata el mensaje como el propietario del token”.

Además, las pruebas de Aikido mostraron que el ataque también podría eludir las restricciones de direcciones IP.

El nivel de acceso resultante depende de los permisos de la cuenta del usuario y puede permitir cambios de código, ejecución de CI/CD, acceso a almacenamiento privado, secretos, etc.

Los investigadores señalan que, además de la restricción de permisos, que no se puede eludir, un atacante también necesita la ruta y el ID del proyecto objetivo.

En proyectos públicos esta información está disponible públicamente, mientras que en proyectos privados la identidad puede ser forzada, pero el camino debe fluir.

GitLab advierte en su documentación sobre las implicaciones de seguridad de exponer estas direcciones, diciendo que son privadas y “generadas solo para usted”.

“Guárdelo para usted, porque cualquiera que lo sepa puede crear problemas o fusionar solicitudes como si fuera usted. Si sospecha que esta dirección de correo electrónico privada se ha filtrado, restablezca el token inmediatamente”, advierte GitLab.

Exponer dirección de correo electrónico privada

En una tarde, los investigadores de Aikido encontraron una docena de direcciones de correo electrónico de GitLab en sus páginas públicas README, guía para contribuyentes y páginas de soporte.

Los investigadores dicen que estas direcciones se incluyeron deliberadamente en documentos públicos para enviar informes de errores a los administradores.

En muchos casos, la exposición afectó a proyectos populares de código abierto, creando riesgos en la cadena de suministro para grandes bases de usuarios. “Algunos formaban parte de proyectos de código abierto muy populares”, afirman los investigadores.

Aikido dice que informó del problema a GitLab a través de HackerOne en mayo, pero GitLab lo cerró como “comportamiento intencional”.

La compañía siguió con una segunda notificación en junio, lo que llevó a GitLab a actualizar su interfaz de usuario para mencionar solicitudes de fusión, eliminar declaraciones falsas sobre el acceso a datos simbólicos y documentar que el correo electrónico entrante elude las restricciones de IP.

Los mantenedores de proyectos deberían dejar de exponer voluntariamente esta información en documentos públicos y restablecer los tokens de proyectos que han sido expuestos de esta manera en el pasado.