La empresa de seguridad de aplicaciones Aikido reveló que las direcciones de correo electrónico de la función Email work item to this project de GitLab aparecen a veces en archivos README, guías de contribución y páginas públicas de soporte. Estas direcciones contienen un token de larga duración vinculado a la cuenta del desarrollador, por lo que publicarlas se parece más a exponer credenciales que a publicar un medio habitual para recibir informes de errores.
La función permite a cualquier persona que envíe un mensaje a la dirección crear una incidencia o tarea en un proyecto de GitLab. Sin embargo, las pruebas realizadas por Aikido demostraron que el atacante puede modificar el sufijo -issue de la dirección a -merge-request, lo que hace que GitLab acepte el mensaje y cree una solicitud de fusión en el proyecto.
¿Qué puede ocurrir en la práctica?
El alcance del impacto depende de los permisos de la cuenta vinculada al token. Entre los posibles resultados se incluyen introducir cambios en el código, ejecutar trabajos de CI/CD, acceder a repositorios privados o extraer secretos almacenados en variables de CI/CD, además de consultar incidencias confidenciales. En los proyectos de código abierto, las direcciones expuestas podrían convertirse en un riesgo para la cadena de suministro si se utilizan para introducir cambios en proyectos de los que dependen un gran número de usuarios.
Los investigadores de Aikido encontraron durante una sola tarde alrededor de 12 direcciones activas publicadas en documentos públicos y afirmaron que algunas pertenecían a proyectos de código abierto ampliamente utilizados. El atacante no necesita suplantar la dirección de correo electrónico del propietario del token; GitLab procesa el mensaje como si hubiera sido enviado por el propietario del token, y las pruebas también demostraron que se pueden eludir las restricciones de direcciones IP.
Límites de la explotación y responsabilidad de los administradores
La exposición de la dirección no implica eludir los permisos de la cuenta; los permisos del usuario siguen siendo una limitación fundamental. El atacante también necesita conocer la ruta y el identificador del proyecto. Esta información está disponible en los proyectos públicos, mientras que atacar un proyecto privado requiere que se filtre la ruta, aunque el identificador pueda adivinarse mediante fuerza bruta.
La propia documentación de GitLab advierte contra compartir estas direcciones y las describe como privadas y generadas para el usuario correspondiente, señalando que quien las conozca puede crear incidencias o solicitudes de fusión como si fuera su propietario. La plataforma recomienda restablecer el token inmediatamente si se sospecha que se ha filtrado.
¿Qué significa esto para los proyectos?
Aikido informó del problema a GitLab a través de HackerOne en mayo, pero el informe se cerró porque se consideró que el comportamiento era intencionado. Tras una segunda notificación en junio, GitLab actualizó su interfaz para mencionar la posibilidad de crear solicitudes de fusión, eliminó afirmaciones imprecisas sobre el acceso a los datos del token y documentó que la recepción de mensajes por correo electrónico elude las restricciones de IP.
El paso práctico más importante corresponde a los administradores de los proyectos: eliminar estas direcciones de los documentos públicos y restablecer los tokens de los proyectos que se hayan publicado anteriormente. Las preguntas abiertas se refieren al grado en que GitLab dependerá en el futuro de la coincidencia entre la dirección del remitente y el correo electrónico del propietario del token como capa de defensa adicional, un mecanismo que, según Aikido, la plataforma está estudiando actualmente.