Google представил проект OSS Rebuild для выявления скрытых изменений в пакетах

Компания Google представила проект OSS Rebuild, предназначенный для выявления скрытых изменений в готовых пакетах, публикуемых в репозиториях. Работа OSS Rebuild основана на концепции воспроизводимых сборок и сводится к проверке соответствия размещённого в репозитории пакета с пакетом полученным на основе пересборки из эталонного исходного кода, соответствующего заявленной версии пакета. Код инструментария написан на языке Go и распространяется под лицензией Apache 2.0.

В настоящее время в OSS Rebuild реализована поддержка верификации пакетов из репозиториев NPM (JavaScript/TypeScript), PyPI (Python) и Crates.io (Rust). В будущем число поддерживаемых репозиториев планируют расширить. На практике инструментарий позволяет выявлять варианты атаки класса «supply chain», в ходе которых после компрометации учётных записей сопровождающих или диверсии внутри проекта в репозитории публикуется вредоносное обновление. При этом код в исходном репозитории основного проекта остаётся корректным, а вредоносные изменения вносятся только в готовые пакеты.

Система по возможности автоматически формирует сценарий для воспроизводимой сборки выбранного пакета, используя эвристику и подбирая параметры, позволяющие добиться идентичности артефактов, поставляемых в пакете. Если автоматически не удаётся воспроизвести размещённый в репозитории пакет, возможно ручное добавление сборочной спецификации. После того как удалось воспроизвести пакет, инструментарий OSS Rebuild сохраняет описание процесса сборки для последующей проверки новых версий пакета. Дополнительно публикуется информация для верификации с использованием фреймворка SLSA.

После проведения проверки конкретной версии пакета формируются данные аттестации, которые могут использоваться другими для оценки уже верифицированных пакетов. Проверку можно осуществить через запуск утилиты командной строк или сверку хэша, сохранённого в отдельном облачном хранилище. Инфраструктуру для проверки пакетов можно развернуть на собственном сервере. Так же можно воспользоваться информацией о проверках, выполненяемых в Google для нескольких тысяч пакетов.

В качестве примеров разных методов атак, от которых мог бы защитить OSS Rebuild, приводится добавление бэкдора в XZ, внедрение вредоносного кода в официальный JavaScript-клиент для криптовалюты Solana и подстановка изменений через Actions-обработчик changed-files:

• В случае с проектом XZ код в репозитории не содержал подозрительных изменений, а образующие бэкдор вредоносные компоненты поставлялись внутри файлов, используемых в тестовом наборе для проверки корректности работы распаковщика XZ. Бэкдор активировался на уровне системы сборки, а сам исходный код XZ совпадал с кодом из репозитория. Активирующие бэкдор m4-макросы для инструментария Automake были включены только в готовый архив с кодом и отсутствовали в репозитории. Для выявления подобных атак в OSS Rebuild применяется динамический анализ поставляемых в пакете артефактов, путей выполнения и подозрительных операций.
• Подстановка вредоносных изменений в библиотеку @solana/web3.js произошла из-за компрометации учётной записи сопровождающего, используя методы социального инжиниринга и фишинга. В репозитории NPM был размещён новый выпуск, включающий вредоносные изменения. В Git-репозитории проекта этот выпуск создан не был и вредоносные изменения присутствовали только в результирующем пакете. Защита в этом случае сводится к выявлению в пакете кода, отсутствующего в основном репозитории.
• Компрометация репозитория обработчика changed-files позволила провести атаку на проекты, использующие changed-files для отслеживания изменения файлов и каталогов в инфраструктуре непрерывной интеграции на базе GitHub Actions. Для защиты от подстановки изменений после компрометации сборочного окружения в OSS Rebuild применяется отслеживание изменений и подозрительной активности в стандартизированных урезанных сборочных окружениях.

Источник: opennet.ru