В конце марта в блоге GitHub вышла статья, как защищаться от уязвимостей типа RepoJacking. В первых строчках автор советовал использовать пакетные менеджеры типа NPM и PyPI, чтобы киберугроза этого вида «не угрожала пользователю напрямую». Можно было бы вздохнуть с облегчением, но читатели Хабра уже знают об исследовании команды МТС RED ART, которое позволило найти более 1300 уязвимых для RepoJacking репозиториев.
Меня зовут Андрей Сомсиков, я — руководитель команды МТС RED ART. В этой статье — вторая часть нашего исследования уязвимых репозиториев на GitHub. Мы нашли уязвимости в популярных библиотеках: для разработки на Ruby, для электронных замков и даже для пользователей Reddit и Minecraft. Но не всё так страшно! В конце дам рекомендации от всей нашей команды по борьбе с уязвимостями в популярных хостингах кода.
Атаки на цепочку поставок — грустный современный тренд
Актуальность нашего исследования показывает аналитика ENISA — европейские эксперты назвали атаки на цепочку поставок киберугрозой №1 в этом десятилетии. В прошлый раз мы рассказывали, какие вектора атак предпочитают злоумышленники и выбрали два варианта для исследования. Мы уже проверили в предыдущей статье публичные репозитории GitHub на уязвимость к захвату (Repository hijacking или RepoJacking). А теперь поднимемся на ступеньку выше и поищем среди них библиотеки, которые часто используются. Ведь для большинства библиотек репозиторий содержит не только код, но и документацию — инструкции по установке и использованию. Если мы сможем захватить репозиторий, то реализуем атаку типа URL hijacking для уже «раскрученного» репозитория. Пользователь получит в документации отсылку к уязвимым библиотекам или рабочим, но вредящим по национальному признаку — так называемым protestware. Они не портят и не крадут данные системы кибербезопасности, но неприятности пользователю доставляют.
Напомним, что в первой части исследования мы создали метод быстрой проверки репозиториев GitHub на уязвимости. Для этого мы использовали Google BigQuery и пакетные менеджеры NPM, PyPI. Благодаря производительности метода мы проверили более 6,3 млн ссылок на репозитории, из которых 4,6 млн оказались уникальными. Из них 1363 оказались уязвимы к RepoJacking. Как проверить свой код на отсутствие уязвимых зависимостей без регистрации и СМС с помощью свободно-доступных инструментов, мы рассказали на сайте МТС RED.
Уязвимости второго уровня
В новом исследовании мы отобрали репозитории с кодом, который был опубликован как библиотека в пакетном менеджере, или имел признаки полезного и готового к использованию. Проверили эти репозитории на уязвимость и выбрали самые популярные. Рекордсменом среди уязвимых программных пакетов оказалась библиотека Ruby, последнюю версию которой скачали более 250 000 раз! Более ранние её версии могли не иметь ссылки на уязвимый репозиторий.
Мы приняли меры, чтобы страница со скриншота выше больше не была доступна для перехвата, но таких на GitHub ещё десятки.
Даже одной уязвимой библиотеки хватило бы злоумышленникам для планирования кибератаки. Но исследование позволило найти 32 популярные библиотеки самой разной функциональности, подверженные атаке типа Repojacking и URL hijacking. Среди них библиотеки, используемые, например, в работе игр и соцсетей:
C#-модуль, опубликован на cakebuild.net
Clojure-модули — на clojars.org
NPM-модули — на npmjs.com
Python-модуль управления электронным дверным замком известного производителя
Python-модуль, реализующий REST API
Ruby-модули, опубликованные на rubygems.org (включая вышеупомянутый, с 350 000 скачиваний)
Бот для форума Reddit
Модуль расширения для игры Counter-Strike
Модуль расширения для игры Minecraft
Модуль расширения игрового движка Godot Engine
Образы контейнеров — опубликован на Docker Hub.
Велика вероятность, что кто-то ими сейчас пользуется или в будущем построит на их основе новые программные пакеты, неумышленно сохранив ссылку на уязвимые репозитории. Подведем итоги нашего исследования.
Уязвимости не исчезли
Хотя хранилища кода приняли защитные меры — такие, как обязательная двухфакторная аутентификация для новых репозиториев и невозможность перерегистрации популярных репозиториев на GitHub, их оказалось недостаточно. Наше исследование показывает, что по-прежнему на самом популярном хранилище кода можно найти подверженные атаке RepoJacking репозитории и даже «живые» проекты со ссылками на уязвимые репозитории. А также мы обнаружили библиотеки с перенаправлением на инструкции, подверженные URL hijacking. Прям меню для злоумышленника.
Есть и хорошая новость. Современный процесс разработки редко завязан на прямое взаимодействие с внешним хранилищем кода. А обращения к зависимостям обычно контролируются, например, через использование приватного доверенного репозитория или repository firewall в целом.
Однако всегда есть риск, что уязвимости останутся в программных пакетах после перемещения в приватные репозитории компаний. Если такие пакеты когда-то станут популярными, злоумышленники могут найти или вспомнить об уязвимости. Ведь хакеры неоднократно показывали расчетливость и терпеливость — например, Эван Бохс описывает схему внедрения бэкдора в опенсорсный код Linux, которую злоумышленники готовили несколько лет. Поэтому нельзя просто оставить уязвимый репозиторий, надеясь, что его никогда не найдут, может это подготовка хакеров к новой атаке.
По мнению экспертов RED ART, обнаруженные уязвимости вряд ли станут поводом для экзотических атак типа zero-day, но могут быть использованы в актуальных сейчас атаках с использованием социальной инженерии. Например, таких, как подмена библиотек на криптовалютных платформах. Этот метод экономит деньги хакеров — иначе им приходится рекламировать и продвигать вредоносные библиотеки (естественно, как «легальные и полезные»), чтобы пользователи применяли их. Полагаем, наши исследования и статьи помогут выстроить приоритеты и решить, в какие сроки и какими ресурсами проверить код на внешние зависимости.
Выводы
Атаки, направленные на захват репозитория, получили распространение несколько лет назад. Из этого материала видно, что не все угрозы еще устранены. Даже защита GitHub от RepoJacking, резервирующая URL репозиториев, ненадежна. Важно не поддаваться ложному чувству безопасности, чтобы не стать жертвой атаки.
Что может делать каждый разработчик?
Устанавливайте сторонние библиотеки из менеджеров пакетов — так вы создаете многослойную защиту.
Всегда фиксируйте конкретную версию зависимости, коммит или хэш.
Проверьте, что ваш код не ссылается на удаленные репозитории — методика команды МТС RED ART для бесплатной проверки есть здесь.
Убедитесь, что репозитории зависимостей или документация к ним не перенаправляются на новый адрес. Если это произошло, не стоит доверять функции редиректа, надежнее обновить прямую ссылку.
Если вы переносите репозиторий, гарантированно защититься от «угона» старого имени можно только оставив его под своим контролем. Переведите его в состояние архива и вместо переноса сделайте git-зеркало. В случае использования встроенной функции GitHub по переносу репозитория, проверьте сохранность резервирования старого URL за вами (он не должен быть доступен для злоумышленников) — попробуйте создать его заново.
Приглашаем сообщество объединиться для регулярного контроля уязвимостей репозиториев. Обеспечим киберустойчивость нашей работы вместе!
