GitLab: correos expuestos permiten a atacantes subir código

Algunos desarrolladores publican direcciones de correo privadas de GitLab en archivos README, guías de contribución y páginas de soporte para recibir informes de errores. Según los investigadores de Aikido, empresa de seguridad de aplicaciones, estas direcciones llevan una credencial que los atacantes pueden usar para actuar en GitLab como el desarrollador al que pertenecen.

Las direcciones proceden de una función integrada de GitLab llamada "Email work item to this project". GitLab las genera automáticamente. Cuando alguien envía un mensaje a una de ellas, GitLab convierte el correo en una incidencia o una tarea dentro del proyecto.

El problema es que cada dirección contiene un token de larga duración vinculado a la cuenta del desarrollador. Esa cadena funciona como credencial para crear elementos de trabajo por correo electrónico.

Un token oculto en la dirección

Cada dirección privada de este tipo incluye una cadena "glimt-" que da acceso al proyecto. La misma cadena se usa en todas las direcciones similares que se generan para ese proyecto.

Aikido descubrió que la dirección no se limita a las incidencias. "Si se cambia el sufijo -issue de la dirección de correo por -merge-request, GitLab abrirá una solicitud de fusión", explicaron los investigadores.

Además, GitLab no comprueba quién envía el mensaje. "En principio, comprobar que la dirección del remitente coincide con el correo del propietario del token añadiría una capa de defensa, pero GitLab no lo hace (aunque ahora se lo está planteando)", señalaron los investigadores. "Cualquier buzón de internet puede enviar un mensaje a esa dirección, y GitLab lo procesa como si fuera del propietario del token".

Las pruebas de Aikido también demostraron que la técnica se salta las restricciones por dirección IP.

Lo que puede hacer un atacante depende de los permisos de la cuenta que hay detrás del token. Según Aikido, una cuenta comprometida podría usarse para:

• subir código a ramas protegidas de repositorios privados
• robar código fuente
• recopilar secretos guardados en variables de CI/CD
• leer incidencias confidenciales

Los permisos de la cuenta no se pueden eludir. El atacante también necesita la ruta y el ID del proyecto objetivo. En los proyectos públicos, ambos datos son fáciles de encontrar. En los privados, el ID puede obtenerse por fuerza bruta, pero la ruta tendría que haberse filtrado.

Direcciones publicadas a propósito

En una sola tarde, Aikido encontró una docena de direcciones de correo entrante de GitLab activas en documentación pública. Según los investigadores, los responsables de mantenimiento las añadieron deliberadamente para que los usuarios pudieran enviar informes de errores.

Varias de estas direcciones pertenecían a proyectos de código abierto populares. "Unas cuantas pertenecían a proyectos de código abierto muy populares", apuntaron los investigadores. En proyectos con una gran base de usuarios, esto supone un riesgo para la cadena de suministro.

La propia documentación de GitLab indica que las direcciones son privadas y se generan "solo para ti". Y advierte: "No la compartas, porque cualquiera que la conozca puede crear incidencias o solicitudes de fusión como si fueras tú. Si sospechas que esta dirección de correo privada se ha filtrado, restablece el token de inmediato".

La respuesta de GitLab

Aikido comunicó el problema a GitLab en mayo a través de HackerOne, una plataforma de recompensas por errores. GitLab cerró el informe como "comportamiento previsto".

Aikido envió un segundo aviso en junio. Después, GitLab introdujo varios cambios:

• su interfaz ahora menciona las solicitudes de fusión
• eliminó afirmaciones falsas sobre los datos a los que puede acceder el token
• su documentación indica ahora que el correo entrante se salta las restricciones por IP

Los investigadores recomiendan a los responsables de mantenimiento que dejen de publicar estas direcciones en la documentación pública. Quien lo haya hecho en el pasado debería restablecer los tokens de los proyectos afectados.

Nuestro análisis

Este caso tiene menos que ver con un fallo de software clásico que con una función pensada para la comodidad cuyos riesgos eran fáciles de pasar por alto. GitLab advirtió a los usuarios de que mantuvieran las direcciones en privado, pero los responsables de mantenimiento las publicaron igualmente, al parecer tratándolas como buzones de soporte corrientes. El hecho de que la misma dirección también pudiera abrir solicitudes de fusión no se documentó con claridad hasta que Aikido lo planteó por segunda vez.

Encaja en una tendencia más amplia en la que la documentación pública para desarrolladores se convierte en una vía de entrada para los ataques. Los secretos guardados en las canalizaciones de CI/CD son valiosos para los atacantes, como demostraron casos anteriores como el del fallo de TeamCity aprovechado por bandas de ransomware. Un token que da ese tipo de acceso a través de una dirección de correo merece el mismo cuidado que una clave de API.

Para los lectores que mantienen proyectos en GitLab, el paso práctico es revisar los README, las guías de contribución y las páginas de soporte en busca de direcciones de correo entrante y restablecer cualquier token expuesto. Conviene estar atentos a si GitLab acaba comprobando la dirección del remitente. Aikido asegura que la empresa se lo está planteando, y eso cerraría la brecha más evidente. Hasta entonces, lo más seguro es dar por hecho que cualquier dirección de este tipo que se haya publicado ya ha sido descubierta.