Атаки на GitHub-разработчика в 2024 году

Тренд «Platform Engineering», предложенный аналитическими агентствами, стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.

Меня зовут Денис Макрушин, и вместе с командой SourceCraft я создаю технологии безопасной разработки, чтобы кибербезопасность была драйвером для инноваций, а разработчик мог эффективно использовать свои когнитивные способности. В этой статье я собрал коллекцию интересных уязвимостей и методов атак на пользователей крупной платформы разработки, обзор актуальных методов атак, выявленных в 2024 году. Понимание актуальных угроз позволяет лучше разобраться в необходимости улучшения практик безопасности в такой платформе на примере GitHub. Материал будет полезен как разработчикам, так и специалистам по информационной безопасности для защиты своих проектов.

Поиск секретов в скрытых git-коммитах

Искать секреты в исходном коде мы умеем. Но в git‑репозиториях остались интересные места, до которых стандартными способами не доберёшься. Речь о скрытых коммитах — информации об изменённых файлах в репозитории, которая была удалена и не отображается в истории проекта.

Когда разработчик вносит изменения (коммит) в репозиторий, а затем по какой‑то причине хочет отменить эти изменения, он выполняет команды:

git reset --hard HEAD^ git push origin -f

Первая строка отменяет последний коммит и все последние изменения в файлах целевого репозитория, а вторая строка применяет все изменения в этом репозитории. То есть, данные команды удаляют последние внесенные изменения.

Тут появляется важная особенность, которую отметили исследователи: если коммит недоступен в истории изменений, то это не означает, что его нельзя восстановить. И тогда все коммиты, которые содержали секреты и затем были удалены разработчиком, можно восстановить и извлечь из них ценную информацию.

Исследователи опубликовали инструмент для извлечения скрытых коммитов публичного GitHub‑репозитория и их анализа. Для репозиториев GitLab эта техника тоже работает, и также есть готовый инструмент. Security‑чемпионы и специалисты по безопасности приложений берут этот подход в работу.

Распространение вредоносного кода через комментарии GitHub

Исследователи обнаружили троян, который распространяется под видом игровых читов и крадёт информацию с заражённой станции. Сам зловред вряд ли чем‑то примечателен, но интересен способ его распространения. Источник, в котором опубликован загрузчик трояна, — официальные GitHub‑репозитории Microsoft.

GitHub позволяет злоумышленникам обходить правила блокировки на основе чёрных и белых списков.

Как троян там оказывается:

1. Злодей создаёт комментарий к любому коммиту или issue в репозитории Microsoft.

2. В комментарий загружается вложение с произвольным файлом.

3. Файл будет загружен в GitHub CDN и привязан к проекту с уникальной ссылкой. Формат ссылки:

   https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}

4. Комментарий может быть не опубликован, но при этом ссылка становится активной.

Атакующий может прикрепить вредоносный файл к любому репозиторию. Пока что единственный вариант уберечь свой проект от подобного использования — отключить комментарии.

Доступ к данным из удалённых и приватных репозиториев GitHub

Когда одна ветка репозитория позволяет получить ценные данные из другой удалённой или приватной ветки, мы имеем дело с новым вектором атаки: Cross Fork Object Reference (CFOR).

По аналогии с уязвимостями Insecure Direct Object Reference (небезопасные прямые ссылки на объект), атакующий использует хэши коммитов, чтобы напрямую получить доступ к данным в этих коммитах. Даже если коммит содержится в удалённом или приватном репозитории. Атакующему остается только узнать хэш коммита. Как?

GitHub позволяет использовать короткие значения хэшей SHA-1, которые можно просто подобрать методом простого перебора. К примеру, вместо длинной ссылки:

github.com/<user>/<repo>/commit/07f01e8337c1073d2c45bb12d688170fcd44c637

Можно использовать короткую ссылку:

github.com/<user>/<repo>/commit/07f01e

где 07f01e — короткий хэш. Его можно подобрать через пользовательский интерфейс GitHub. А уже после получения доступа к коммитам атакующий приступает к поиску секретов.

GitHub в курсе данной проблемы и не планирует исправление, потому что это не баг, а фича.

GitHub-звёзды могут обмануть разработчика

Как мы обычно оцениваем репутацию какого‑нибудь GitHub‑репозитория? Чаще всего на основе количества звёзд и активности в этом репозитории. Для кого‑то из разработчиков число звёзд напрямую определяет степень доверия к этому репозиторию.

В связи с этим растёт количество фейковых звезд на GitHub: их уже насчитывается более 3,7 миллионов. Эти звёзды создают ложное впечатление популярности проектов, которые на самом деле скрывают вредоносное ПО или какой‑либо мошеннический контент. Злодеи используют их для обмана разработчиков, маскируя опасные репозитории под успешные проекты.

Чтобы защитить себя от этого вида мошенничества анализируем всю активность в проекте. Например, изучаем обсуждения в репозитории и репутацию авторов.

Отравление пайплайна разработки

Мы уже изучали, как злоумышленник может навредить разработчику и заразить зависимости в цепочке поставок. А вот сам CI/CD-пайплайн — дирижёр конвейера разработки — стоит рассмотреть ещё. При этом GitLab и GitHub регулярно закрывают уязвимости в своих продуктах, что говорит о внимании злодеев к ключевым технологиям в инфраструктуре.
                                     
OWASP давно опубликовал документ CI/CD Top 10 Risks. Значительная часть рекомендаций по защите отдана на сторону разработчика и владельца репозитория: не доверяйте pull request от сторонних контрибьюторов, аккуратнее прописывайте правила автоматического слияния веток кода, не запускайте сборку недоверенных обновлений кода рядом со сборками основной ветки и так далее. Однако злодей активно использует уязвимости в самих CI/CD-платформах для внедрения имплантов, поэтому одних рекомендаций, требующих внимания разработчика, — недостаточно. 

Многим знакомы GitHub Actions — это сервис, который позволяет автоматизировать процессы сборки, тестирования, развёртывания своего приложения и множество других рутинных действий. Можно изучить подборку актуальных методов эксплуатации GitHub Actions, чтобы понять типичный сценарий атаки на CI-окружение (который также был замечен в дикой природе):

1. Атакующий изменяет конфигурационный файл CI в репозитории, к которому у него есть доступ, и внедряет в этот файл команду: «отдай мне переменные окружения с ценными данными».

2. Затем заносит изменения непосредственно в основную ветку репозитория или отправляет pull request с изменениями из ветки или форка.

3. Если у атакующего нет возможности вносить изменения напрямую в файл конфигурации CI, то он может внедрить вредоносный код в файлы, на которые ссылается CI-конфиг.

4. Далее атакующий отправляет pull request, который заставляет CI-платформу запустить процесс сборки на основе вредоносного конфига.

5. Так как процесс сборки практически всегда обращается к чувствительным данным и привилегированным учётным записям, то в итоге атакующий выполняет команду «отдай мне переменные окружения» на хосте, где выполняется сборка.

Исследователи из Open Source Security Foundation продвинулись ещё дальше и на примере коллекции наиболее распространённых атак на GitHub Actions рассмотрели конкретные техники защиты от каждой проблемы. 

Если коротко и в формате «атака: защита»

1. Запуск недоверенного кода в привилегированном рабочем процессе (Workflow): разделение процесса на два блока (с привилегиями и без).

2. Внедрение кода через недоверенный ввод данных, недоверенные файлы и файлы окружения: сбор параметров для Actions‑строк, ограничение прав на GitHub‑токен до минимально необходимых.

3. Вредоносные Actions: ограничение прав на GitHub‑токен до минимально необходимых, доверять только официальным Actions от GitHub (остальные — проверять на наличие уязвимостей и затем патчить, например, с помощью Dependabot).

4. Вредоносные коммиты: ограничение прав на GitHub‑токен до минимально необходимых, сверять хэши Actions при обновлении Workflow.

5. Кража токенов кеша для получения контекста других рабочих процессов, использующих кеширование: не кеэшировать ценную информацию, не запускать недоверенный код в контексте основной ветки.

Опечатки в GitHub Actions запускают вредоносные действия

Атаки typosquatting при разработке ПО эксплуатируют человеческий фактор. Злодей ожидает, что разработчик опечатается в имени компонента и по ошибке подключит вредоносный код в свой проект. Оказалось, что эта техника атак может применяться и для подключения вредоносных GitHub Actions.

Многообразие рутинных задач можно автоматизировать, а подходящие автоматизации можно найти в маркетплейсе. Только есть проблема: кто угодно может создать произвольный Action и опубликовать его под произвольным именем.

Что если кто‑то создаст организацию trufllesecurity, затем создаст Action trufllesecurity/trufflehog и разместит в нём код, который собирает все секреты из CI/CD? Когда разработчик вместо uses: trufflesecurity/trufflehog допустит опечатку и напишет uses: trufllesecurity/trufflehog — в его пайплайне запустится вредоносное действие.

Пока злоумышленники собирают с миру по нитке, следуем рекомендациям, чтобы не оказаться в этом клубке:

• перепроверяем названия всех используемых GitHub Actions;

• явно прописываем конкретные версии Actions;

• рассказываем своим коллегам-разработчикам о проблеме.

Фишинг для GitHub-пользователей

Платформа ведёт борьбу со спам‑ботами, которые эксплуатируют её репутацию и отправляют пользователям сообщения с вредоносными ссылками.

Особенность этого фишинга: пользователь платформы получает письмо от GitHub. Боты добавляют вредоносные ссылки в комментариях к существующим задачам (issues) открытых проектов. И затем эти комментарии приземляются в почту в виде нотификации к пользователям этого проекта. Дальше уже всё по классике: запуск вредоноса, захват GitHub‑аккаунта и публикация аналогичного комментария со ссылкой в репозиториях, которые добавил в закладки этот аккаунт.

Red Team рассматривает эту особенность как дополнительный канал доставки импланта, потому что в комбинации с техникой загрузки вредоносных файлов в GitHub CDN он позволяет уверенно обходить спам‑фильтры. А Blue Team теперь внимательнее следит за почтовыми уведомлениями от GitHub.

Вместо итогов

Злодеи не перестают изобретать всё более хитрые способы навредить: они отравляют пайплайны, накручивают звёзды, раскапывают скрытые коммиты и ищут там секреты. Но самой эффективной атакой по‑прежнему остаётся заражение зависимостей. Эта техника даёт возможность заразить сразу кучу проектов, используя каждую заражённую библиотеку как новый плацдарм для распространения угроз.

Чтобы защитить свои проекты, важно знать все методы. И даже иногда воспроизводить их в своих процессах. Значит, нужно строить надёжную защиту на всех этапах разработки, чтобы сохранить пайплайн в безопасности — будь то на GitHub или любой другой платформе.