Защищаемся от Dependency Confusion с помощью Nexus Repo и Nexus IQ
Привет, Хабр!
Несколько недель назад во всех источниках нашумела новость про новую (ну или немного забытую) атаку через цепочку поставок, названную Dependency Hijacking или Dependency Confusion. В качестве быстрого решения многие воспользовались скриптами по проверки имен компонентов в репозиториях, кто-то написал роуты для загрузки, а команды разработки начали переходить на неймспейсы в именах своих библиотек. Тем временем Sonatype подготовили свежие релизы Nexus Repo и Nexus IQ, позволяющие автоматизировать защиту от данной атаки.
Суть атаки можно почитать в блоге Sonatype или в оригинальном отчете исследователя. Если в двух словах, то, пользуясь данной атакой, злоумышленник может загрузить в публичный репозиторий поддельный пакет с именем вашей внутренней библиотеки, а ваш сборщик скачает его при следующей сборке приложения (и некотором стечении обстоятельств), что приведет к внедрению или выполнению вредоносного кода, в том числе и в закрытом контуре. Чтобы проверить, уязвимы ли ваши приложения на текущий момент, можно воспользоваться утилитами repo-diff или confused, в том числе добавить их в планировщик для организации процесса.
Пример работы утилиты repo-diff на нескольких репозиториях
В результате отображаются пакеты, имя которых встрачалось в proxy- и hosted-репозиториях одновременно.
Многие инструменты практик OSA/SCA позволяют задать правила именования внутренних компонентов, настроить определенные политики и требуемые действия (пропуск, блокировка, предупреждение), но это по-прежнему является некоторым набором ручных действий.
С новым обновлением в Nexus Repository появилась возможность автоматически помечать все компоненты в отдельном hosted-репозитории как внутренние, а в Nexus IQ появилось новое условие Proprietary Name Conflict, срабатывающее при конфликте имен внутренних компонентов и тех, которые загружаются через прокси-репозитории. С помощью такого условия можно сделать отдельную политику, к примеру Dependency Confusion, или отредактировать какую-то существующую. Единственная рекомендация здесь — проверить, что в выбранных hosted-репозиториях нет публичных библиотек, которые вы, возможно, модифицируете или пересобираете в силу необходимости. На этом ручные действия заканчиваются, дальше все работает автоматически.
Итоговый набор шагов для автоматизации защиты от Dependency Confusion:
Обновить Nexus Repository до версии 3.30, Nexus IQ Server до версии 106.
Подключить Nexus Repository к Nexus IQ (раздел Settings > IQ Server).
В выбранном hosted-репозитории, в котором содержатся ваши внутренние библиотеки, активировать опцию Components in this repository count as proprietary for dependency confusion attacks. Также можно сразу управлять всеми такими репозиториями из меню Proprietary Repositories.
Создать политику Dependency Confusion в Nexus IQ, добавить условие Proprietary Name Conflict is present, а также действие Fail для Proxy.
Можно идти пить кофе с коллегами, т. к. правило начинает работать автоматически на всех прокси-репозиториях, подключенных к проверке через Nexus IQ.
Короткая видео-инструкция и оригинал статьи в блоге Sonatype. Там же информация о том, какие дополнительные действия (в том числе и до текущего обновления) предпринимает компания по предотвращению рисков, связанных с использованием небезопасных компонентов, включая Malware Detection System и Advanced Development Pack.
В результате всех проведенных настроек защита от Dependency Confusion будет работает на всех подключенных репозиториях. И если, к примеру, вы разрабатываете внутренний пакет billing (npm) и сохраняете его в репозиторий npm-hosted, то попытка загрузки пакета с тем же именем из проксирующего репозитория npm-proxy приведет к ошибке.
Сообщение об ошибке в консоли разработчика/пайплайне
Request item is quarantined, а также ссылка не отчет Nexus IQ.В отчете по репозиторию Nexus IQ нарушение политики будет выглядеть следующим образом:
На этом все.
Всем хороших выходных!
Женскую половину с наступающим 8 марта!
