В репозитории пакетов для Rust crates.io обнаружены сразу четыре вредоносных компонента: finch-rust, sha-rust, evm-units и uniswap-utils. Разработчики Rust официально подтвердили инцидент и удалили эти пакеты, однако к моменту блокировки часть из них уже успела разойтись по проектам и попасть в сборочные цепочки.
Главная цель злоумышленников — кража криптовалюты и конфиденциальных данных разработчиков, включая токены доступа и настройки окружения, которые часто используются для деплоя и управления инфраструктурой.
Вредоносные evm-units и uniswap-utils: атака на криптовалютные проекты
Пакет evm-units был опубликован в апреле 2025 года и за время присутствия в репозитории набрал 7257 загрузок. В его составе находился код-загрузчик, предназначенный для подтягивания сторонних вредоносных компонентов, нацеленных на криптовалютные кошельки и инфраструктуру, работающую с Ethereum и совместимыми сетями.
Связанный с ним пакет uniswap-utils, также появившийся в апреле и скачанный 7441 раз, использовал evm-units как зависимость. Таким образом, разработчики, подключавшие, на первый взгляд, безобидный утилитный модуль для работы с Uniswap и EVM-параметрами, автоматически втягивали в свои проекты и вредоносный код из evm-units.
Активировался вредонос при вызове функции `get_evm_version()`. Вместо того чтобы просто вернуть данные о версии, он инициировал загрузку внешнего кода с атакующей стороны. В зависимости от операционной системы происходила подгрузка и выполнение различных скриптов:
- в Linux и macOS загружался и запускался скрипт с именем `init`;
- в Windows — скрипт PowerShell `init.ps1`.
Такая схема позволяла злоумышленникам получать удалённый доступ к системе или выполнять произвольные действия, не ограничиваясь исходными возможностями пакета. Особенно опасно это для сервисов, работающих на серверах с доступом к криптокошелькам, нодам блокчейна или приватным ключам.
sha-rust: кража конфиденциальных данных
Пакет sha-rust появился в каталоге 20 ноября и был загружен 153 раза. На первый взгляд он мог выглядеть как реализация хеш-функций или вспомогательных операций с криптографией (что логично по названию), однако внутри находился шпионский функционал.
Вредоносный код в sha-rust занимался поиском конфиденциальной информации в системе и её отправкой на внешний сервер злоумышленников. Под удар попадали:
- содержимое определённых конфигурационных файлов;
- данные окружения, которые часто содержат ключи, пароли, токены;
- иная чувствительная информация, которую можно использовать для дальнейших атак или прямого доступа к сервисам.
По сути, sha-rust был специализированным модулем для сбора и утечки данных разработчиков и окружений сборки.
finch-rust: подмена легитимного пакета и скрытая интеграция шпионажа
Особо примечательную роль в этой истории сыграл пакет finch-rust. Он был опубликован 25 ноября и использовал sha-rust как зависимость. При этом был оформлен таким образом, чтобы как можно ближе напоминать популярный легитимный пакет finch. Это классическая атака типа typosquatting: злоумышленники рассчитывали, что кто-то по ошибке установит именно finch-rust, не заметив дополнительный суффикс в названии.
Внутри finch-rust находился исходный код оригинального finch, но с добавленным вызовом функции `sha_rust::from_str()`. При её выполнении активировался обфусцированный обработчик, который:
- собирал сведения о системе;
- считывал переменные окружения;
- извлекал содержимое конфигурационных файлов `config.toml` и `id.json`;
- искал и выгружал файлы с расширением `.env` (например, `production.env`, `staging.env`, `dev.env`), где часто хранятся токены доступа, пароли к базам данных, ключи API и другие критически важные секреты.
Вся собранная информация отправлялась на удалённый сервер злоумышленников. Таким образом, finch-rust превращал разработческую машину или CI/CD-окружение в источник ценных секретов, которыми можно воспользоваться для последующих компрометаций сервисов.
Typosquatting как основной вектор атаки
Случай с finch-rust наглядно демонстрирует, что атаки через typosquatting — не абстрактная угроза, а уже регулярный инструмент киберпреступников. Схема проста:
1. Берётся название существующего популярного пакета.
2. В него вносится незначительное изменение: добавляется суффикс, префикс, дефис, меняется одна буква.
3. Создаётся вредоносный клон, который по описанию и структуре максимально похож на оригинал.
4. Атакующий рассчитывает на человеческий фактор — опечатку при установке или невнимательный выбор пакета из списка.
В связке с тем, что многие разработчики автоматически доверяют коду из публичных репозиториев, это делает подобные атаки крайне эффективными. Особенно если пакет замаскирован под популярную библиотеку, часто упоминаемую в руководствах или примерах.
Почему это серьёзно, даже при «небольшом» числе загрузок
На первый взгляд, цифры в десятки сотен или тысяч загрузок могут показаться не столь значительными по меркам крупных экосистем. Но в случае с инфраструктурными и криптовалютными библиотеками каждая установка может означать:
- компрометацию продакшн-сервера;
- утечку приватных ключей;
- доступ к платёжным системам, кошелькам, биржевым аккаунтам;
- возможность незаметно модифицировать код и бэкэнды для дальнейших атак на конечных пользователей.
Кроме того, вредоносный пакет, будучи зависимостью популярного проекта, автоматически попадает во множество других приложений, даже если конечный разработчик никогда напрямую его не подключал. В случае с uniswap-utils и evm-units удар приходится в первую очередь по финансовым и DeFi‑сервисам, что делает риски особенно высокими.
Уроки для разработчиков Rust и не только
Этот инцидент показывает: даже языки, ориентированные на безопасную работу с памятью, никак не защищают от вредоносного кода на уровне логики приложения. Rust снижает класс целых категорий уязвимостей (use-after-free, переполнения буфера и т.п.), но:
- не может помешать разработчику (или злоумышленнику под видом разработчика) написать бэкдор;
- не защищает от утечки данных, если библиотека намеренно реализует их отправку на сторонний сервер;
- не отменяет необходимости проверять происхождение и репутацию зависимостей.
Безопасность цепочки поставок (supply chain security) сегодня становится не менее важной, чем безопасность самого языка и рантайма.
Как снизить риск при работе с crates.io
Разработчикам имеет смысл выстроить хотя бы базовую гигиену работы с зависимостями:
1. Проверять автора и активность проекта
Обращать внимание на количество скачиваний, историю версий, репутацию автора, наличие осмысленного описания и документации.
2. Буднично относиться к «почти одинаковым» именам пакетов
Любое подозрительное отличие в названии популярной библиотеки — повод остановиться и проверить, не установлен ли поддельный пакет.
3. Использовать lock-файлы и фиксировать версии
Это снижает риск внезапного получения вредоносной версии через автоматическое обновление зависимостей.
4. Периодически анализировать зависимости
Использовать статический анализ, поиск подозрительных сетевых запросов, обращений к файловой системе, сбору системной информации в сторонних библиотеках.
5. Минимизировать количество секретов в сборочной среде
Хранить токены и ключи по принципу минимально необходимого доступа, использовать отдельные учётные записи и сегрегацию прав.
Что делать, если вы использовали указанные пакеты
Если в вашем проекте когда-либо подключались finch-rust, sha-rust, evm-units или uniswap-utils, необходимо:
- немедленно удалить их из зависимостей и заменить безопасными аналогами;
- пересобрать приложение с «чистым» набором библиотек;
- провести ревизию системы:
- проверить наличие неизвестных скриптов `init` или `init.ps1`;
- изучить журналы сетевой активности на предмет подозрительных исходящих соединений;
- сменить все токены, пароли и ключи, которые могли храниться в `.env`, `config.toml`, `id.json` и переменных окружения;
- проверить CI/CD‑окружение, если сборка осуществлялась на выделенном сервере или в облаке.
Особое внимание стоит уделить сервисам, работающим с криптовалютой или финансовыми транзакциями: в этом случае целесообразно считать все потенциально скомпрометированными и действовать по процедуре инцидент-реакции.
Почему подобные случаи будут повторяться
Инцидент с Rust‑пакетами — не уникален. В разных языковых экосистемах (Python, JavaScript, PHP, Java и других) уже неоднократно находили:
- библиотеки, отправляющие пользовательские данные на сторонние серверы;
- модули с закладками в криптографических функциях;
- компоненты, которые встраивают в систему майнеры или подключают машину к ботнету.
Причина проста: центр тяжести безопасности давно сместился в сторону цепочек поставок. Взломать одну библиотеку или завести поддельный пакет зачастую проще и выгоднее, чем искать уязвимость в хорошо защищённом приложении.
Итог: Rust безопасен как язык, но не как гарантия
Ситуация с finch-rust, sha-rust, evm-units и uniswap-utils ещё раз подчёркивает: выбор безопасного языка — важный, но не единственный шаг. Даже идеальная модель работы с памятью не спасёт от того, что вам поставят «легитимный на вид» пакет, который:
- собирает конфиденциальные данные;
- загружает и запускает сторонние скрипты;
- передаёт секреты третьим лицам.
Ответственность за безопасность кода всё больше ложится на процессы: проверку зависимостей, контроль изменений, аудит, автоматизированный анализ и аккуратное обращение с секретами. И чем популярнее становится та или иная экосистема, тем привлекательнее она для атакующих — а значит, подобные инциденты с Rust, к сожалению, будут возникать и дальше.
