Частные адреса электронной почты GitLab, которые позволяют разработчикам отправлять в проект задачи или проблемы, намеренно публикуются в файлах README, руководствах по участию в проекте и на страницах поддержки, используемых для сбора отчетов об ошибках.
Эти адреса являются частью встроенной функции GitLab под названием «Отправить рабочий элемент в этот проект по электронной почте» и содержат долговременный токен, привязанный к учетной записи разработчика.
Эти адреса генерируются автоматически и содержат строку, которая служит учетными данными для создания рабочих элементов по электронной почте. Когда внешний клиент отправляет сообщение на один из этих адресов, GitLab преобразует его в задачу или проблему проекта.
Исследователи из компании Aikido, специализирующейся на безопасности приложений, обнаружили несколько закрытых адресов GitLab в общедоступной документации и предупреждают о связанных с этим рисках.
Злоумышленник может использовать их для компрометации учетных записей GitLab в ходе атак, направленных на отправку кода в защищенные ветки частных репозиториев, для кражи исходного кода, сбора секретных данных из переменных CI/CD или получения доступа к конфиденциальным задачам.
Каждый из этих приватных адресов GitLab содержит строку «glimt-», которая служит учетными данными для доступа к проекту и сохраняется во всех аналогичных адресах, сгенерированных для соответствующего проекта.
«Измените суффикс -issue в адресе электронной почты на -merge-request, и GitLab откроет запрос на слияние», — говорит Айкидо.
Изменение адреса электронной почты
Источник: Aikido
Злоумышленник, который знает этот адрес или может его получить, может изменить суффикс «-issue» на «merge-request», и GitLab примет его, открыв запрос на слияние в проекте.
«В принципе, проверка того, что адрес отправителя совпадает с адресом электронной почты владельца токена, могла бы стать дополнительным уровнем защиты, но GitLab этого не делает (хотя сейчас они рассматривают такую возможность)», — говорят исследователи.
«Любой почтовый ящик в интернете может отправить письмо на этот адрес, и GitLab обработает его как сообщение от владельца токена».
Кроме того, тесты Aikido показали, что такая атака позволяет обойти ограничения по IP-адресам.
Полученный уровень доступа зависит от прав учетной записи пользователя и может включать в себя возможность вносить изменения в код, запускать CI/CD, получать доступ к частным репозиториям, секретным данным и т. д.
Исследователи отмечают, что помимо ограничения прав доступа, которое невозможно обойти, злоумышленнику также нужны путь и идентификатор целевого проекта.
В публичных проектах эта информация находится в открытом доступе, а в частных проектах идентификатор можно подобрать методом перебора, но тогда станет известен путь.
GitLab в своей документации предупреждает о рисках, связанных с раскрытием этих адресов, и сообщает, что они являются конфиденциальными и «генерируются специально для вас».
«Держите его при себе, потому что любой, кто его знает, может создавать проблемы или запросы на слияние, как будто это вы. Если вы подозреваете, что этот личный адрес электронной почты был раскрыт, немедленно сбросьте токен», — предупреждает GitLab.
Раскрытые личные адреса электронной почты
За один день исследователи Aikido обнаружили десяток действующих адресов электронной почты для входящей почты GitLab в общедоступных файлах README, руководствах для участников и на страницах поддержки.
По словам исследователей, эти адреса были намеренно включены в общедоступную документацию, чтобы отправлять сообщения об ошибках разработчикам.
Во многих случаях уязвимость затрагивала популярные проекты с открытым исходным кодом, создавая риски для цепочек поставок для большого числа пользователей. «Некоторые из них принадлежали очень популярным проектам с открытым исходным кодом», — говорят исследователи.
В Aikido сообщили о проблеме в GitLab через HackerOne в мае, но GitLab закрыла ее как «преднамеренное действие».
В июне компания отправила второе уведомление, после чего GitLab обновила свой пользовательский интерфейс, добавив упоминание о запросах на слияние, убрав ложные утверждения о доступе к данным токенов и задокументировав, что входящая электронная почта обходит ограничения по IP.
Сопровождающие проекты должны прекратить добровольно публиковать эту информацию в общедоступной документации и отозвать токены для проектов, которые они публиковали таким образом в прошлом.
