Publicado en

Alerta en GitLab: Cómo una dirección de correo filtrada puede comprometer su cadena de suministro de software

El riesgo oculto en las funciones de automatización de GitLab

En el ecosistema de desarrollo moderno, herramientas de DevOps como GitLab son fundamentales para la agilidad empresarial. Sin embargo, una reciente investigación de seguridad ha puesto de manifiesto cómo una funcionalidad diseñada para la conveniencia —la creación de issues mediante correo electrónico— puede transformarse en una puerta trasera para actores maliciosos.

El problema radica en que las direcciones de correo electrónico privadas que GitLab asigna a los usuarios para reportar incidencias no son simples alias; funcionan como credenciales de autenticación permanentes. Si una de estas direcciones se filtra, cualquier persona que la posea puede inyectar código y ejecutar procesos automatizados en nombre del usuario afectado.

¿Cómo funciona esta vulnerabilidad?

GitLab permite a los usuarios enviar correos a una dirección específica para abrir un «elemento de trabajo» (work item). Esta dirección contiene un token único vinculado a la cuenta del usuario. Según el informe técnico de Aikido Security, existen varios factores críticos que elevan el riesgo:

  • Tokens persistentes: El token incluido en la dirección de correo no expira automáticamente.
  • Falta de verificación del remitente: GitLab no comprueba quién envía el correo, solo valida que el token sea correcto. Esto significa que cualquier buzón de correo del mundo puede actuar en nombre del usuario legítimo.
  • Escalada de funcionalidades: Aunque la dirección se promociona para crear issues, un atacante puede cambiar el sufijo de la dirección de -issue a -merge-request. Esto permite enviar parches de código (patches) que GitLab aplicará directamente a las ramas del repositorio.

Impacto en la seguridad empresarial

Desde una perspectiva de gestión de riesgos, esta vulnerabilidad es especialmente preocupante por su capacidad para eludir controles de seguridad críticos:

  1. Bypass de Doble Factor (2FA): Las funciones de correo entrante operan sin necesidad de autenticación multifactor, incluso en instancias donde el 2FA es obligatorio.
  2. Evasión de restricciones de IP: El tráfico de correo electrónico entrante suele estar exento de las listas de IP permitidas (allowlists), permitiendo ataques desde cualquier ubicación geográfica.
  3. Ejecución de CI/CD: Si el atacante incluye cambios en el archivo .gitlab-ci.yml, GitLab ejecutará trabajos de integración continua con los permisos del usuario, lo que podría dar acceso a secretos corporativos y claves de infraestructura.

El alcance del daño depende de los privilegios del usuario cuya dirección se haya filtrado. Mientras que un perfil de ‘Invitado’ tiene un impacto limitado, la filtración de la dirección de un ‘Mantenedor’ o ‘Administrador’ podría comprometer por completo la cadena de suministro de software de la organización.

Recomendaciones para responsables de TI y Ciberseguridad

Para mitigar este riesgo en su organización, desde Intedya recomendamos las siguientes acciones inmediatas:

  • Auditoría de documentación: Revisar archivos README, guías de contribución y páginas de soporte para asegurar que ninguna dirección de correo de este tipo haya sido publicada accidentalmente.
  • Restablecimiento de tokens: Instar a los desarrolladores con altos privilegios a resetear su Incoming Email Token desde la configuración de su perfil personal en GitLab.
  • Gestión de la instancia: En instalaciones self-managed, los administradores deben evaluar si la funcionalidad de correo entrante es estrictamente necesaria. De lo contrario, lo más seguro es desactivarla a nivel global.
  • Monitoreo de commits: Implementar alertas para detectar commits o merge requests realizados a través de la interfaz de correo electrónico, especialmente en ramas protegidas.

La seguridad no es un estado estático, sino un proceso de vigilancia continua. En Intedya, ayudamos a las organizaciones a fortalecer sus políticas de seguridad y cumplimiento para anticiparse a riesgos que, como este, se esconden en las funcionalidades más cotidianas de sus herramientas de trabajo.


Fuentes