ЗАПРОС
КОНСУЛЬТАЦИИ

Команда перспективных исследований МТС RED ART (Advanced Research Team) в январе 2024 года провела исследование публичных репозиториев GitHub. Обнаружено более 1000 открытых репозиториев, уязвимых к атаке типа RepoJacking. Ниже изложены подробности исследования и инструкция по проверке программного кода на отсутствие уязвимостей данного типа.

В современной разработке широко распространено использование внешних компонентов от сторонних разработчиков — библиотек. Если они подключаются из внешнего репозитория, то существует риск кибератаки типа repository hijacking или RepoJacking (захват репозитория). Стандартные методы контроля цепочки поставок (к которой относятся и внешние программные пакеты) — например, фреймворк SLSA — не контролируют безопасность конвейера производства ПО на каждом этапе. В данном исследовании закрыт этот пробел в части атак типа RepoJacking — на уязвимости проверены все доступные публично репозитории GitHub как самого популярного хостинга кода. Сам подход пригоден для масштабирования и на другие источники программных пакетов. 

RepoJacking — это атака на репозиторий, которая позволяет получить контроль над его кодовой базой и распространяться в рамках подключаемой библиотеки или используемого стороннего кода. В результате атакующий может выполнить произвольный код в том контексте, в котором используется данная зависимость. 

Обычно механизм возникновения уязвимости выглядит следующим образом: 

1. Разработчик подключает сторонний код из чужого репозитория к своему коду напрямую или через пакетный менеджер.
2. Автор этого репозитория удаляет/переносит/продаёт свой аккаунт.
3. Злоумышленник регистрирует заново или получает доступ к тому же аккаунту и размещает в нём вредоносный код. 

В итоге все приложения, которые подключают код из этого репозитория, оказываются заражёнными.

Сбор аналитики по всему GitHub — ресурсоёмкая работа. Поэтому исследователи обычно ограничиваются небольшой выборкой репозиториев на GitHub в 2—5% от доступного объёма, после чего экстраполируют данные на всю выборку. 

Преимущество исследования RED ART по сравнению с работами, где проверялась только небольшая выборка доступных программных паркетов, — проверка всех публичных репозиториев на GitHub. Выявлены уязвимые зависимости, а также разработана методика для их самостоятельного поиска разработчиками в программном коде. 

Всего в ходе исследования было проверено более шести млн репозиториев.

В ходе исследования были проверены все репозитории, которые используются в пакетных менеджерах PyPI и NPM, а также исследован открытый набор данных GitHub в Google BigQuery. Среди них шёл поиск репозиториев, аккаунты которых были перенесены или удалены. Всего было собрано 6 349 287 репозиториев. Анализ показал, что 4,7 млн из них — уникальные, с которыми и происходила дальнейшая работа. 

Для получения полного списка репозиториев из Google BigQuery использовался стандартный запрос (SELECT * From 'bigquery-public-data.github_repos'). 

Для PyPI был создан парсер, в котором использовался метод подстановки имени пакета (https://pypi.org/project/{имя искомого пакета}) с дальнейшим изъятием значения (href) из элемента DOM-дерева сайта, ведущего на https://github.com/{Имя пользователя}/{Имя искомого пакета}. 

При работе с пакетным менеджером NPM работа велась по аналогии с PyPI — перебор методом подстановки имена пакетов (https://www.npmjs.com/package/{имя искомого пакета}) с дальнейшим изъятием значения (href) из элемента DOM-дерева сайта, ведущего на https://github.com/{Имя пользователя}/{Имя искомого пакета}. Однако пришлось учесть защитные механизмы сервиса. Для корректной работы запросы проводились с разных IP, что не могло повлиять на результаты исследований.

Сначала проводился поиск «битых» ссылок (corrupted links), по которым репозитории с кодом больше недоступны. Для этого использовалась утилита из набора Kali Linux — nuclei. Этот инструмент позволяет отправлять запросы на основе шаблонов с ожиданием заданного ответа. Для получения необходимого результата в шаблонах nuclei использовались две текстовые фразы: Sign in to GitHub и a GitHub Pages site here For root URLs, — эти сообщения выдаёт GitHub при обращении по «битым» ссылкам. Таким образом было получено 7 820 corrupted links — ссылок на репозитории, которые на момент исследования не содержали исходных кодов. 

Однако риски возникают лишь в случае, если аккаунт, которому принадлежит репозиторий, можно зарегистрировать заново. Если это сделает злоумышленник, он сможет разместить вредоносный код по ссылке. Поэтому проводилась попытка перерегистрации аккаунтов, содержащих битые ссылки. Для этого в автоматическом режиме в поле для регистрации https://github.com/signup поочерёдно подставлялись имена аккаунтов, в которых были обнаружены «битые» ссылки. Получение ответа вида «{имя пользователя} is available» значило, что логин свободен для регистрации. Таким образом был составлен список аккаунтов, подверженных атаке типа Repository Hijacking.

Чтобы определить, сколько репозиториев содержится в аккаунтах, подверженных перерегистрации, была проведена построчная проверка имен входящих в списки ссылок на репозитории в Google BigQuery, менеджерах пакетов PyPI и NPM. Всего было обнаружено 1 363 ссылки на репозитории, относящиеся к уязвимым аккаунтам. Эти репозитории до сих пор могут использоваться разработчиками при создании ПО. 

Результаты исследования: 

Совокупно обработано 6 349 287 репозиториев кода, в том числе 4 650 987 уникальных: 

• запросами в BigQuery через Google Cloud Сonsole найдено 3 325 634 репозитория, уникальных — 3 325 634;
• в менеджере пакетов PyPI найдено 484 233 репозитория, уникальных – 293 470;
• в NPM найдено 2 539 420 репозиториев, уникальных — 1 031 884. 

Обнаружено 7 820 «битых» ссылок на репозитории, из них: 

• 6 418 ссылок — в Google BigQuery;
• 1 046 ссылок — в PyPI;
• 356 ссылок — в NPM. 

Перерегистрация возможна для 986 уникальных аккаунтов (их репозитории уязвимы для атаки RepoJacking), из них: 

• 636 аккаунтов — в Google BigQuery;
• 294 аккаунта — в PyPI;
• 56 аккаунтов — в NPM.  

Обнаружено 1 363 репозитория, подверженных кибератакам типа RepoJacking, из них:

• 937 — в Google BigQuery;
• 352 — в PyPI;
• 74 — в NPM. 

Одним из результатов работы стала методика по проверке программного кода на устойчивость к атакам RepoJacking. Исследователи МТС RED ART рекомендуют разработчикам следующие меры: 

1. Извлеките все ссылки на GitHub из вашего кода.
2. Проверьте актуальность этих ссылок и убедитесь, что ни одна из них не возвращает ответ «Ошибка 404» или «Ошибка 301». Для этого можно использовать сканер nuclei с шаблоном для обнаружения атак типа subdomain takeover (атаки RepoJacking являются их подвидом).
3. Исключите из кодовой базы все репозитории, которые возвращают ошибку 404 или 301.
4. Применяйте пункты проверки 1-3 для каждого нового релиза. 

Более подробно методика проверки кода описана здесь. 

Данная методика имеет ограничение: она позволяет выявить те репозитории, которыми злоумышленники могут воспользоваться в будущем. Если репозитории были перехвачены ими ранее, методика не позволит выявить скомпрометированные зависимости. 

В целях повышения уровня безопасности исходного кода исследователи МТС RED ART рекомендуют применение ряда проактивных мер: 

1. Соберите и поддерживайте в актуальном состоянии список всех используемых сторонних компонентов. Пример решения подобной задачи с инструментами разработчика приведён здесь.
2. Внедрите инструмент software composition analysis (SCA), даже если у вас в компании пока не построен процесс DevSecOps (безопасная разработка) и не используются инструменты тестирования кода типа SAST/DAST.
3. Создайте внутренний репозиторий для всех зависимостей, поддерживайте его в актуальном состоянии. Предоставьте к нему доступ только для разработчиков.
4. Если у вас уже сформирован центр мониторинга и реагирования на кибератаки (SOC), повышайте объем покрытия техник Supply Chain Compromise: Compromise Software Dependencies and Development Tools по матрице MITRE ATT&CK.
5. Внедряйте процессы DevSecOps — создавайте инфраструктуру безопасной разработки и применяйте инструменты анализа компонентов программного обеспечения.