Свяжитесь с нами для подбора нужного решения. Наши эксперты ответят на ваши вопросы.
Команда перспективных исследований МТС RED ART (Advanced Research Team) в январе 2024 года провела исследование публичных репозиториев GitHub. Обнаружено более 1000 открытых репозиториев, уязвимых к атаке типа RepoJacking. Ниже изложены подробности исследования и инструкция по проверке программного кода на отсутствие уязвимостей данного типа.
В современной разработке широко распространено использование внешних компонентов от сторонних разработчиков — библиотек. Если они подключаются из внешнего репозитория, то существует риск кибератаки типа repository hijacking или RepoJacking (захват репозитория). Стандартные методы контроля цепочки поставок (к которой относятся и внешние программные пакеты) — например, фреймворк SLSA — не контролируют безопасность конвейера производства ПО на каждом этапе. В данном исследовании закрыт этот пробел в части атак типа RepoJacking — на уязвимости проверены все доступные публично репозитории GitHub как самого популярного хостинга кода. Сам подход пригоден для масштабирования и на другие источники программных пакетов.
RepoJacking — это атака на репозиторий, которая позволяет получить контроль над его кодовой базой и распространяться в рамках подключаемой библиотеки или используемого стороннего кода. В результате атакующий может выполнить произвольный код в том контексте, в котором используется данная зависимость.
Обычно механизм возникновения уязвимости выглядит следующим образом:
В итоге все приложения, которые подключают код из этого репозитория, оказываются заражёнными.
Сбор аналитики по всему 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 уникальных:
Обнаружено 7 820 «битых» ссылок на репозитории, из них:
Перерегистрация возможна для 986 уникальных аккаунтов (их репозитории уязвимы для атаки RepoJacking), из них:
Обнаружено 1 363 репозитория, подверженных кибератакам типа RepoJacking, из них:
Одним из результатов работы стала методика по проверке программного кода на устойчивость к атакам RepoJacking. Исследователи МТС RED ART рекомендуют разработчикам следующие меры:
Более подробно методика проверки кода описана здесь.
Данная методика имеет ограничение: она позволяет выявить те репозитории, которыми злоумышленники могут воспользоваться в будущем. Если репозитории были перехвачены ими ранее, методика не позволит выявить скомпрометированные зависимости.
В целях повышения уровня безопасности исходного кода исследователи МТС RED ART рекомендуют применение ряда проактивных мер: