Un fallo de dise\u00f1o en la funcionalidad de correo electr\u00f3nico de GitLab est\u00e1 permitiendo a atacantes comprometer repositorios privados con solo modificar una direcci\u00f3n de correo electr\u00f3nico expuesta en documentaci\u00f3n p\u00fablica. Investigadores de seguridad han demostrado que los tokens incrustados en estas direcciones, dise\u00f1ados para crear issues por correo, pueden ser reutilizados para abrir merge requests y empujar c\u00f3digo directamente a ramas protegidas, eludiendo restricciones de IP y de verificaci\u00f3n del remitente.<\/p>\n
GitLab incluye una funcionalidad llamada \u00abEmail work item to this project\u00bb que permite a los desarrolladores crear issues o tareas en un proyecto enviando un correo electr\u00f3nico a una direcci\u00f3n especialmente generada. Cada direcci\u00f3n contiene un token persistente identificado por el prefijo glimt-<\/strong>, que act\u00faa como una credencial vinculada a la cuenta del desarrollador. Cuando un cliente externo env\u00eda un mensaje a esa direcci\u00f3n, GitLab lo parsea y lo convierte en un issue o tarea dentro del proyecto.<\/p>\n La vulnerabilidad descubierta por los investigadores de la empresa de seguridad Aikido radica en que estas direcciones pueden modificarse trivialmente. Cambiando el sufijo -issue<\/strong> por -merge-request<\/strong> en cualquier direcci\u00f3n de este tipo, GitLab interpreta el mensaje como una solicitud de merge, abriendo un merge request en el proyecto. El sistema no verifica que el remitente del correo coincida con el propietario del token, ni siquiera comprueba la direcci\u00f3n de origen. Cualquier buz\u00f3n de internet puede enviar a esa direcci\u00f3n, y GitLab procesa el mensaje como si fuera el propietario del token.<\/p>\n El token glimt-<\/strong> es una cadena \u00fanica generada autom\u00e1ticamente por GitLab para cada proyecto que tiene habilitada la recepci\u00f3n de work items por correo. Este token permanece constante para todas las direcciones generadas para ese proyecto, y sirve como credencial de acceso. Al estar incrustado en la direcci\u00f3n de correo, cualquier persona que conozca esa direcci\u00f3n puede utilizarla para interactuar con el proyecto como si fuera el desarrollador original. GitLab advierte expl\u00edcitamente en su documentaci\u00f3n que estas direcciones son privadas y que \u00abcualquiera que las conozca puede crear issues o merge requests como si fuera usted\u00bb.<\/p>\n En una sola tarde de investigaci\u00f3n, los analistas de Aikido localizaron una docena de direcciones de correo electr\u00f3nico activas de GitLab expuestas en archivos README p\u00fablicos, gu\u00edas de contribuci\u00f3n y p\u00e1ginas de soporte. Estas direcciones hab\u00edan sido incluidas deliberadamente por los mantenedores de los proyectos para facilitar el env\u00edo de informes de errores. En varios casos, los proyectos afectados eran repositorios de c\u00f3digo abierto muy populares, lo que crea un riesgo significativo en la cadena de suministro de software para grandes bases de usuarios.<\/p>\n Los investigadores subrayan que, adem\u00e1s de la restricci\u00f3n de permisos (que no puede eludirse), un atacante necesita conocer el path y el ID del proyecto objetivo. En proyectos p\u00fablicos, esta informaci\u00f3n est\u00e1 disponible abiertamente. En proyectos privados, el ID puede ser obtenido mediante fuerza bruta, aunque el path requerir\u00eda una filtraci\u00f3n previa. La combinaci\u00f3n de una direcci\u00f3n de correo expuesta con la posibilidad de obtener el path y el ID hace que el ataque sea factible incluso contra repositorios privados.<\/p>\n El ataque se desarrolla en varios pasos:<\/p>\n Los investigadores de Aikido confirmaron que este ataque elude por completo las restricciones de direcci\u00f3n IP configuradas en el proyecto. El nivel de acceso resultante depende enteramente de los permisos del usuario cuyo token est\u00e1 vinculado a la direcci\u00f3n. En escenarios donde el desarrollador tiene permisos de mantenedor o superior, un atacante podr\u00eda:<\/p>\n Aikido report\u00f3 la vulnerabilidad a GitLab a trav\u00e9s de la plataforma HackerOne en mayo de 2024. GitLab cerr\u00f3 el reporte inicial calific\u00e1ndolo como \u00abcomportamiento intencionado\u00bb, argumentando que la funcionalidad est\u00e1 documentada y que la exposici\u00f3n de las direcciones es responsabilidad del usuario. Sin embargo, tras una segunda notificaci\u00f3n en junio, GitLab realiz\u00f3 varias actualizaciones: modific\u00f3 la interfaz de usuario para mencionar tambi\u00e9n los merge requests, elimin\u00f3 afirmaciones incorrectas sobre el acceso a datos del token, y document\u00f3 expl\u00edcitamente que el correo entrante elude las restricciones de IP.<\/p>\n A pesar de estas mejoras, GitLab no ha modificado el comportamiento fundamental del sistema. La compa\u00f1\u00eda ha abierto un work item interno (n\u00famero 617883) para considerar la posibilidad de verificar que la direcci\u00f3n de env\u00edo coincida con el correo del propietario del token, pero hasta la fecha no se ha implementado ning\u00fan cambio sustancial.<\/p>\n La postura de GitLab se basa en que la documentaci\u00f3n ya advert\u00eda a los usuarios que no compartieran estas direcciones. Sin embargo, los investigadores de Aikido se\u00f1alan que la facilidad con la que se puede modificar el sufijo para pasar de issues a merge requests no estaba claramente documentada, y que muchos mantenedores de proyectos desconocen que exponer la direcci\u00f3n para issues abre autom\u00e1ticamente la posibilidad de merge requests. La falta de verificaci\u00f3n del remitente agrava el problema, ya que cualquier atacante que encuentre la direcci\u00f3n puede abusar de ella sin necesidad de suplantar el correo del propietario.<\/p>\n El hallazgo tiene consecuencias directas para la seguridad del ecosistema open source. Los proyectos populares que exponen estas direcciones en su documentaci\u00f3n ponen en riesgo a todos los usuarios que dependen de ellos. Un atacante podr\u00eda inyectar c\u00f3digo malicioso en un proyecto de c\u00f3digo abierto ampliamente utilizado, propagando malware a trav\u00e9s de actualizaciones leg\u00edtimas. Este tipo de ataque a la cadena de suministro ha sido responsable de incidentes de alto perfil en el pasado, como el compromiso de SolarWinds o la inyecci\u00f3n de backdoors en bibliotecas de JavaScript.<\/p>\n La naturaleza persistente del token (no caduca a menos que se reinicie manualmente) hace que el riesgo sea continuo. Incluso si un mantenedor elimina la direcci\u00f3n expuesta de la documentaci\u00f3n, el token sigue siendo v\u00e1lido y puede ser utilizado por cualquiera que lo haya capturado durante el per\u00edodo de exposici\u00f3n.<\/p>\n Los mantenedores de proyectos deben dejar de incluir direcciones de correo de GitLab en documentaci\u00f3n p\u00fablica, incluso si solo pretenden recibir informes de errores. Existen alternativas m\u00e1s seguras, como formularios web, issues tracker integrados o servicios de terceros especializados. Para aquellos que ya hayan expuesto direcciones en el pasado, es imprescindible reiniciar el token inmediatamente. GitLab proporciona una opci\u00f3n para regenerar el token en la configuraci\u00f3n del proyecto, lo que invalida todas las direcciones existentes.<\/p>\n Los administradores de instancias de GitLab (tanto self-managed como SaaS) deber\u00edan revisar si la funcionalidad de correo entrante est\u00e1 habilitada por defecto y considerar deshabilitarla para proyectos que no la necesiten expl\u00edcitamente. Tambi\u00e9n pueden implementar pol\u00edticas de seguridad que exijan la verificaci\u00f3n del remitente o la restricci\u00f3n por IP a nivel de servidor de correo, aunque GitLab ya ha confirmado que sus propias restricciones de IP no se aplican a este canal.<\/p>\n Los equipos de seguridad deber\u00edan auditar sus repositorios y documentaci\u00f3n p\u00fablica en busca de direcciones de correo que contengan el patr\u00f3n glimt-<\/strong>. Herramientas de escaneo automatizado pueden detectar estas cadenas en archivos README, gu\u00edas de contribuci\u00f3n, p\u00e1ginas wiki y cualquier otro documento accesible p\u00fablicamente. Adem\u00e1s, es recomendable revisar los logs de merge requests en busca de solicitudes inusuales que puedan haberse originado a trav\u00e9s del canal de correo.<\/p>\n En un nivel m\u00e1s amplio, este incidente subraya la necesidad de que las plataformas de desarrollo adopten un enfoque de seguridad por dise\u00f1o, donde las funcionalidades que otorgan acceso privilegiado requieran autenticaci\u00f3n adicional por defecto, en lugar de confiar en que los usuarios no compartir\u00e1n informaci\u00f3n sensible.<\/p>\n La caracter\u00edstica de crear work items por correo electr\u00f3nico tiene un claro valor de productividad: permite a desarrolladores y contribuyentes externos enviar tareas sin necesidad de acceder a la interfaz web de GitLab. Sin embargo, cuando esa misma direcci\u00f3n puede ser reutilizada para abrir merge requests sin verificaci\u00f3n del remitente, el equilibrio se inclina peligrosamente hacia el riesgo. La decisi\u00f3n de GitLab de considerar esto como comportamiento intencionado refleja una filosof\u00eda en la que la funcionalidad prima sobre la seguridad, dejando la responsabilidad en manos del usuario final.<\/p>\n Los investigadores de Aikido resumen la cuesti\u00f3n de forma contundente: \u00abEn principio, comprobar que la direcci\u00f3n de env\u00edo coincide con el correo del propietario del token a\u00f1adir\u00eda una capa de defensa, pero GitLab no hace esto\u00bb. Hasta que la plataforma implemente esa verificaci\u00f3n o un mecanismo equivalente, la responsabilidad recae exclusivamente en los mantenedores y administradores. En un ecosistema donde los ataques a la cadena de suministro son cada vez m\u00e1s sofisticados, exponer estas direcciones es un riesgo evitable que ning\u00fan proyecto deber\u00eda asumir.<\/p>\n","protected":false},"excerpt":{"rendered":" Un fallo de dise\u00f1o en la funcionalidad de correo electr\u00f3nico de GitLab est\u00e1 permitiendo a atacantes comprometer repositorios privados con solo modificar una direcci\u00f3n de correo electr\u00f3nico expuesta en documentaci\u00f3n p\u00fablica. Investigadores de seguridad han demostrado que los tokens incrustados en estas direcciones, dise\u00f1ados para crear issues por correo, pueden ser reutilizados para abrir merge […]<\/p>\n","protected":false},"author":2,"featured_media":69755,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/es\/69750.png","fifu_image_alt":"Atacantes explotan correos de GitLab expuestos para subir c\u00f3digo","footnotes":""},"categories":[5],"tags":[],"class_list":["post-69750","post","type-post","status-publish","format-standard","has-post-thumbnail","category-tecnologia"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/es\/69750.png","fifu_image_alt":"Atacantes explotan correos de GitLab expuestos para subir c\u00f3digo","_links":{"self":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/69750","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/comments?post=69750"}],"version-history":[{"count":1,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/69750\/revisions"}],"predecessor-version":[{"id":69756,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/69750\/revisions\/69756"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media\/69755"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media?parent=69750"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/categories?post=69750"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/tags?post=69750"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\u00bfQu\u00e9 es exactamente el token ‘glimt-‘ y por qu\u00e9 es cr\u00edtico?<\/h3>\n
Hallazgos de Aikido: una docena de direcciones expuestas en una tarde<\/h2>\n
\u00bfC\u00f3mo puede un atacante explotar una direcci\u00f3n expuesta?<\/h3>\n
\n
\n
La respuesta de GitLab: de ‘comportamiento intencionado’ a actualizaciones parciales<\/h2>\n
\u00bfPor qu\u00e9 GitLab considera esto un comportamiento intencionado?<\/h3>\n
Implicaciones para la cadena de suministro de software<\/h2>\n
Recomendaciones pr\u00e1cticas para desarrolladores y administradores<\/h2>\n
\u00bfQu\u00e9 deben hacer los equipos de seguridad?<\/h3>\n
El equilibrio entre funcionalidad y seguridad en las herramientas de desarrollo<\/h2>\n