Filtración de direcciones de correo en GitLab
GitLab ha sido objeto de un hallazgo preocupante que pone en riesgo la seguridad de sus usuarios. Una dirección de correo electrónico privada utilizada para presentar incidencias puede ser explotada para que cualquier persona envíe código y ejecute trabajos de CI/CD en nombre de otros usuarios. Esto es posible gracias a un token que forma parte de la dirección y que no caduca.
Los investigadores de Aikido Security alertaron sobre esta vulnerabilidad. Cuando un usuario crea un proyecto en GitLab, se le asigna una dirección de correo electrónico para comunicar incidencias. Sin embargo, todas las direcciones generadas para los diferentes proyectos de un mismo usuario comparten el mismo token, lo que significa que quien tenga acceso a esa dirección puede actuar como si fuera el propietario de la cuenta.
Cómo funciona la vulnerabilidad
GitLab permite que cualquier correo electrónico enviado a esta dirección genere automáticamente un problema en el proyecto correspondiente, como si lo hubiera creado el usuario real. El token en la dirección está vinculado a la cuenta del usuario y, según la documentación de GitLab, no tiene fecha de caducidad. Esto implica que cualquier atacante que obtenga esta dirección puede realizar acciones maliciosas sin necesidad de acceder al correo del usuario.
Los investigadores demostraron que, modificando el sufijo de la dirección de correo de `-issue` a `-merge-request`, un atacante puede enviar un código para que se realicen solicitudes de fusión en lugar de problemas. Esto permite que el atacante envíe un parche que se aplicará a una rama específica del proyecto, incluso si esa rama es la principal. Si el parche modifica el archivo `.gitlab-ci.yml`, GitLab ejecutará el trabajo del atacante como si fuera el usuario legítimo, siempre y cuando el rol del usuario lo permita.
Impacto según el rol del usuario
El nivel de acceso que un atacante puede obtener depende del rol del usuario afectado. Por ejemplo, si la dirección filtrada pertenece a un usuario con rol de Mantenedor, el atacante podría tener acceso a ramas protegidas y secretos de CI/CD. Sin embargo, si se trata de un Guest, el impacto sería mucho menor.
Para acceder a un proyecto específico, un atacante necesita no solo la dirección de correo, sino también la ruta y el ID numérico del proyecto, lo que añade una capa adicional de dificultad a la explotación de esta vulnerabilidad en proyectos privados.
Consecuencias y mitigaciones
Una de las mayores preocupaciones es que las restricciones de IP no se aplican a los correos electrónicos entrantes. Esto significa que un atacante puede enviar un correo desde cualquier ubicación, incluso si el proyecto tiene restricciones de acceso. GitLab ha sido incapaz de bloquear este tipo de ataques, ya que la verificación de IP no se aplica a los correos electrónicos.
Aikido intentó limitar el acceso a un proyecto privado a una única dirección IP, pero GitLab aceptó un correo de fusión desde fuera de esa IP, permitiendo así que el atacante comprometiera el proyecto.
Para mitigar el riesgo, los usuarios de GitLab deben reiniciar su token de correo electrónico desde la configuración de su perfil, lo que invalidará todas las direcciones anteriores. Sin embargo, esto significa que cualquier dirección activa dejará de funcionar hasta que se proporcione la nueva dirección.
Recomendaciones finales
GitLab ha tomado nota de esta vulnerabilidad y ha comenzado a modificar la descripción de la funcionalidad del token. Sin embargo, no se ha implementado una solución definitiva. Actualmente, GitLab está considerando aceptar correos electrónicos solo de direcciones verificadas en la cuenta, pero todavía no hay cambios en vigor. La comunidad de usuarios debe estar alerta y tomar medidas para proteger sus cuentas ante esta vulnerabilidad, que podría tener consecuencias graves si no se gestiona adecuadamente.