В Rust-пакетах впервые обнаружена скрытая кража исходного кода через сборочный скрипт

security

Волна кибератак на цепочки поставок, прокатившаяся по экосистемам пакетных менеджеров этим летом, добралась до Rust. Если предыдущие инциденты в npm, PyPI и на GitHub были нацелены главным образом на кражу учётных данных и ключей доступа, то свежая находка демонстрирует принципиально иной вектор. Злоумышленники заразили популярный крейт (Rust-пакет) onering, используемый для высокопроизводительной синхронной передачи данных. Крейт скачали более 18 тысяч раз.

Описание

Инцидент, зафиксированный 10 июня 2026 года, интересен не столько масштабом, сколько изощрённостью. Вредоносная логика была скрыта не в исполняемом коде библиотеки, а в сборочном скрипте build.rs. Это принципиальный момент. В экосистеме Rust сборочный скрипт компилируется и запускается на машине разработчика автоматически - достаточно просто указать заражённый крейт в зависимостях и запустить сборку. Никаких дополнительных действий от программиста не требуется.

Атака затронула версию крейта 1.4.1. Исследователи из компании Aikido обнаружили активность и немедленно уведомили автора пакета. Специалисты отметили, что проблема не ограничивается публикацией на официальном реестре crates.io. Репозиторий сопровождающего на GitHub также оказался скомпрометирован, поэтому загрузка крейта напрямую из системы управления версиями не гарантирует безопасности.

Механизм атаки заслуживает пристального внимания. Вредоносный build.rs выполняет три последовательных действия. Первым делом скрипт определяет корневой каталог проекта, в котором происходит сборка. Вместо собственной директории он поднимается по дереву папок от переменной окружения OUT_DIR до тех пор, пока не обнаружит каталог target, после чего берёт его родителя. Так злоумышленники получают полный доступ к репозиторию жертвы.

Второй этап - это извлечение git-данных. Скрипт выполняет две команды. Первая собирает метаданные последнего коммита: его хеш, имя и электронную почту автора, дату и тему. Вторая команда - git diff HEAD^ HEAD - захватывает полную текстовую разницу между последним и предпоследним коммитом. Эта операция происходит при каждой сборке. В результате злоумышленники получают не единичный снимок кода, а непрерывный поток изменений, которые разработчик вносит в проект.

Третий этап - самая изобретательная часть. Собранные данные маскируются под телеметрическое событие платформы Sentry, популярного сервиса для отслеживания ошибок и crash-репортов. Скрипт формирует POST-запрос на адрес ingest.de.sentry.io - штатной точки приёма данных Sentry. Метаданные коммита подставляются в качестве тегов события, а сам код упаковывается в поле extra.patch.

Такая маскировка - осознанный выбор атакующих. Любой администратор, заметивший исходящий трафик во время сборки, воспримет запрос к Sentry как штатную работу инструментов мониторинга. Только при вдумчивом анализе содержимого пакета и пакетного трафика можно обнаружить, что фактически происходит кража интеллектуальной собственности.

Специалисты обращают внимание на одну характерную деталь. В коде найдена закомментированная строка std::fs::write(data.txt, payload), что свидетельствует о локальном тестировании payload перед интеграцией сетевой отправки. Злоумышленники отлаживали полезную нагрузку, записывая её в файл, и лишь затем активировали эксфильтрацию через интернет.

Последствия подобной атаки могут быть катастрофическими. Если традиционные атаки на цепочку поставок нацелены на кражу паролей, токенов и ключей шифрования, то здесь объектом выступает сам исходный код продукта. Компания рискует потерять коммерческую тайну до того, как продукт будет выпущен. Более того, кража последовательных diff-изменений позволяет атакующим изучать внутреннюю архитектуру, алгоритмы и подходы к решению задач, что даёт стратегическое преимущество конкурентам.

Тенденция очевидна: злоумышленники переходят от кражи статических данных к краже процесса разработки. Атака через build.rs в Rust - прямое продолжение приёмов, ранее опробованных в npm и PyPI, где скрипты установки пакетов использовались для запуска произвольных команд. Rust, с его репутацией безопасного языка, не стал исключением.

Рекомендации для разработчиков вытекают из самого инцидента. Необходимо тщательно проверять версии зависимостей перед обновлением, анализировать файлы build.rs на предмет подозрительных сетевых вызовов и внедрять инструменты, способные перехватывать исходящий трафик на этапе сборки. Особое внимание стоит уделить пакетам, которые внезапно обновляются после долгого периода стабильности.

Рынок решений для защиты цепочек поставок уже реагирует. Компании начинают предлагать сервисы, отслеживающие аномалии в поведении пакетов во время сборки. Однако, как показывает практика, превентивные меры - доверие к подписям сопровождающих, публичным репозиториям и устоявшимся каналам распространения - больше не работают.

Экосистема Rust столкнулась с вызовом, который ранее казался прерогативой JavaScript и Python. Вопрос не в том, последуют ли новые атаки, а в том, насколько быстро сообщество сможет выработать механизмы защиты, адекватные новому уровню угроз. Пока что ответом остаётся только бдительность.

Индикаторы компрометации

URLs

  • https://o4511539639222272.ingest.de.sentry.io/api/4511539669368912/envelope/

Version

  • Onering 1.4.1

DSN public key

  • 8197ee42c4f59c83f4cc6d48f5bae821

Organization id

  • o4511539639222272

Project id

  • 4511539669368912

Комментарии: 0