Comments 16
Это потребует достаточно много усилий по первоначальному заполнению файла
Почему? Одной команды достаточно: ./gradlew --write-verification-metadata pgp,sha256
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Кажется, о подобном типе атак писали еще 3 года назад:
Добрый день!
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Шикарная статья!
Итак, мы возвращаемся к Ant :)
нет. возвращаемся к заявлению в "первый отдел" для обновления версии библиотеки. и, конечно, это все "ради вашей же безопастности"
Вот очень хотелось бы как нибудь без этого обойтись. Нужны инженерные, а не административно-силовые методы решения этой проблемы. Потому что сидеть на старых версиях библиотек - тоже весьма и весьма небезопасное занятие :(
Полностью согласен.
Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
Красным выделил индикаторы данной уязвимости у Jfrog Xray.
Jfrog Xray Scan/Audit показывает у нас так:
Jfrog Xray отчет:
молодцы они, быстро сориентировались :)
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
И это для мобильных приложений.
Они правда реализовали это не совсем понятно ибо в конвейере вообще не понятно, что за уязвимость, что разрабов ввело в замешательство, как видно из скриншота нет никакой информации об уязвимости в консоли конвейера. При просмотре же уязвимостей у билда в Artifactory она не отображалась из-за настроенных у нас watches, но при выгрузке pdf отчета она отображается… Возможно, поправят в скором времени.
ИМХО - реально серьёзная проблема. Отслеживать правообладателей доменов 100500 open source библиотек, используемых в проекте... Да еще и транзитивных зависимостей... Самому, в одиночку, просто нереально :( Тут со стороны сообщества нужно вырабатывать защитный механизм.
Полностью согласен, поэтому и написал эту статью, так как мне показалось, что данная атака была недостаточно раскрыта и недооценена.
Или комьюнити или инструмент, который по SBOM позволит сказать, какие проблемные компоненты есть в приложении.
Как минимум для мобильных приложений мы уже выпустили подобный функционал. Думаю, что и для Java появится в скором времени что-то подобное.
Разбираемся с MavenGate, новой атакой на цепочку поставок для Java и Android-приложений