Служебный email GitLab позволяет отправлять коммиты от имени пользователя
Исследователи Aikido Security обнаружили, что персональный адрес GitLab для создания задач по email может использоваться как учётные данные: владелец такого адреса способен отправить патч, создать коммит от имени пользователя в доступной ему ветке, включая main, и запустить задания CI/CD с его правами.
GitLab показывает этот адрес в функции Email work item to this project. Внутренняя часть адреса содержит токен, связанный с учётной записью. Документация GitLab указывает, что он не имеет срока действия. Письмо на этот адрес создаёт задачу в проекте от имени владельца токена, при этом GitLab не проверяет, с какого почтового ящика отправлено сообщение.
Один токен для доступных проектов
По данным Aikido Security, адреса, созданные для разных проектов одного пользователя, содержат один и тот же токен. Он действует для всех проектов, к которым у аккаунта есть доступ, включая публичные и приватные. Для атаки на конкретный проект также требуются его путь и числовой ID; для публичных репозиториев эти сведения доступны открыто.
Исследователи показали, что суффикс адреса можно изменить с -issue на -merge-request. Тогда GitLab обработает письмо как создание merge request. Если в теме письма указать целевую ветку и приложить патч, сервис применит изменения к этой ветке либо создаст её, если она отсутствует. Коммит будет оформлен от имени владельца токена.
Возможный запуск CI/CD и обход ограничений
При наличии у пользователя прав на запись в ветку изменения могут попасть и в main. Если приложенный патч меняет файл .gitlab-ci.yml и роль владельца позволяет такую операцию, GitLab запускает задание CI/CD с его полномочиями. Сам merge request нельзя направить в копию проекта, контролируемую атакующим, поэтому исполняемый код в описанном сценарии доставляется именно приложенным патчем.
Масштаб последствий зависит от роли скомпрометированного аккаунта. Токен пользователя с ролью Guest почти не даёт возможностей, тогда как токен Maintainer может открыть доступ к защищённым веткам и секретам CI/CD. Входящая почта не подпадает под IP-ограничения и работает без двухфакторной аутентификации. Aikido Security проверила это на приватном проекте с доступом только с одного IP: браузер и git clone блокировались, но письмо с merge request было принято, а коммит оказался в main.
Что можно сделать
GitLab.com включает входящую почту по умолчанию; функция также доступна на self-managed-инстансах при включённой настройке. GitLab Dedicated, по описанию Aikido Security, не затронут, однако исследователи не смогли проверить это непосредственно. Индивидуального переключателя для запрета создания задач и merge request по email нет.
Пользователь может отозвать скомпрометированный адрес, сбросив токен входящей почты на странице персональных access tokens: после этого все ранее выданные проектные адреса перестанут работать. Aikido Security советует проверить README, руководства для участников и страницы поддержки на опубликованные адреса. Администратор self-managed GitLab может отключить incoming email для всего инстанса.
GitLab обновила текст интерфейса, уточнив, что адрес создаёт не только задачи, но и merge request. Однако поведение не изменилось: токен не истекает, отправитель не проверяется, а персонального отключения функции нет. Компания рассматривает приём таких писем только с адреса, подтверждённого владельцем аккаунта, но это решение пока не внедрено. Для бизнеса практический вывод прост: служебные адреса входящей почты GitLab следует учитывать как долгоживущие секреты, регулярно перевыпускать и не публиковать без необходимости.