Один лишь адрес электронной почты: как почтовые адреса GitLab становятся оружием в атаках на цепочку поставок
Оказывается, киберпреступникам достаточно одного адреса электронной почты, чтобы нанести серьёзный ущерб.
Новое исследование Aikido Security, опубликованное сегодня, показывает: входящий адрес электронной почты GitLab фактически работает как высокопривилегированный токен доступа, дающий широкие права пользователя на публичные и приватные проекты организации. GitLab автоматически выдаёт каждому пользователю платформы DevOps приватный адрес, чтобы тот мог создавать задачи в своих программных проектах: если написать на этот адрес, в проекте появится новая задача от имени владельца адреса.
Сама по себе возможность создавать задачи письмами на уникальные автоматические адреса — не редкость, отмечает Aikido в отчёте. Похожие функции есть, например, у платформ управления проектами вроде Trello, Todoist и Monday.com.
Но адреса GitLab содержат неистекающий токен, который даёт широкий доступ к ресурсам организации — причём не только к проекту, в котором работает конкретный пользователь. А если сам адрес раскрыт публично, злоумышленник может использовать его для атак на цепочку поставок, не имея реального доступа к аккаунту.
«Любой почтовый ящик в интернете может отправить письмо на этот адрес, и GitLab обработает сообщение как действие владельца токена, — говорится в отчёте. — Если у вас есть адрес, у вас есть и аутентификация, и авторизация».
Команда исследователей Aikido утверждает, что многие пользователи GitLab, вероятно, не осознают связанных с этими адресами рисков — на это указывает количество намеренно раскрытых адресов в открытом интернете.
Какой у вас адрес в GitLab?
Исследователь Aikido Джо Леон рассказал Dark Reading, что простая функция GitLab для создания задач с годами обросла дополнительными возможностями: через неё можно отправлять запросы на слияние и патчи, причём с привилегированным доступом. И хотя эти возможности описаны в документации, риски, по словам Леона, преуменьшены — особенно в интерфейсе GitLab.
«Нигде чётко не сказано, что там есть нечто чувствительное, что умеет не только создавать задачи, но и заливать код. А заливая код, оно потенциально может писать в основную ветку или запускать задачу CI/CD», — говорит он.
Интерфейс GitLab описывает адрес как инструмент для добавления рабочих элементов вроде задач в конкретный проект и прямо утверждает, что «его нельзя использовать для доступа к другим данным». По данным Aikido, это утверждение явно неверно.
«Учётные данные, встроенные в адрес, можно переиспользовать для всех публичных и приватных проектов», — говорит Леон.
Леон обнаружил, что адреса содержат префикс glimt- (GitLab Incoming Mail Token), и что строка токена у каждого пользователя одинакова для всех публичных и приватных проектов, к которым у него есть доступ. Если адрес для публичного проекта раскрыт, злоумышленник может изменить в письме slug пути и идентификатор проекта, чтобы добраться до приватных проектов. В отчёте Aikido отмечено, что идентификаторы предсказуемы, но атакующему потребуется узнать имя проекта.
«Они подают это как адрес для создания задачи в конкретном проекте. И если вы работаете над публичным проектом, вы можете его распространять — это логично, — говорит Леон. — Но я не осознавал, что с этими учётными данными, просто подправив адрес, кто угодно может писать код и в мои приватные проекты. Меня это ошеломило».
Кроме того, Леон выяснил, что с помощью почтовых адресов GitLab можно обходить ограничения по IP. Он ограничил приватный проект одним случайным IP-адресом, который ему не принадлежал: запрет GitLab не давал склонировать проект или открыть его в браузере — но письма с запросами на слияние эту защиту пробили.
Раскрытые почтовые адреса GitLab — серьёзный риск
В рамках исследования Леон провёл «весьма неполный поиск» в интернете, занявший пару часов, и без труда нашёл дюжину входящих почтовых адресов, намеренно опубликованных в файлах ReadMe и документации поддержки. Часть раскрытых адресов принадлежит популярным проектам с открытым кодом, говорит Леон.
«Уверен, что таких гораздо больше, — говорит он. — Это были самые доступные плоды».
Леон также отмечает, что определить, злоупотребил ли атакующий входящим адресом — например, чтобы отравить проект вредоносным кодом через запрос на слияние, — может быть трудно. «Неочевидно, что это было сделано через почту, — добавляет он. — Нужен доступ к серверам GitLab — при условии, что они собирают такие данные».
О находках Aikido сообщила GitLab через HackerOne в мае, но компания закрыла отчёт как «предполагаемое поведение». Затем в июне вендор кибербезопасности создал конфиденциальную задачу в репозитории GitLab. В итоге GitLab изменила интерфейс, указав, что адрес можно использовать для запросов на слияние, и убрала фразу «его нельзя использовать для доступа к другим данным».
GitLab также обновила документацию, предупредив пользователей, что на почтовые адреса не распространяются ограничения по IP.
Лучшей мерой защиты Леон считает требование, чтобы адрес отправителя совпадал с адресом в аккаунте GitLab. Это создало бы серьёзное препятствие для атак: злоумышленникам пришлось бы скомпрометировать почтовый аккаунт пользователя, а не обходиться одним адресом GitLab.
«Это фактически устраняет подавляющую часть проблемы», — говорит он.
По словам Леона, GitLab рассматривает такое изменение.
Dark Reading обратилась к GitLab за комментарием, но на момент публикации компания не ответила.
Тем временем Aikido рекомендует организациям сокращать поверхность атаки: заранее менять токены доступа в своих почтовых адресах GitLab и сканировать среду разработки и репозитории на наличие таких адресов, как любые другие секреты.
Вывод исследования шире одной функции GitLab: любой автоматический адрес, по которому система принимает команды от имени пользователя, по сути является секретом — даже если выглядит как обычная почта для создания задач. Пока такие адреса публикуют в файлах ReadMe и документации поддержки, они остаются удобной точкой входа для атак на цепочку поставок: от создания задач и запросов на слияние до заливки кода в ветки и запуска конвейеров CI/CD. Именно поэтому специалисты советуют относиться к входящим адресам так же строго, как к API-ключам и токенам доступа.
