Typosquatting в Rust: finch-rust скрытно крадет учётные данные

Недавнее исследование выявило вредоносный Rust crate под именем finch-rust, созданный в результате typosquatting-атаки. Злоумышленник под псевдонимом «faceless» попытался выдать пакет за законный инструмент биоинформатики finch (оригинальный пакет имел более 67 000 загрузок). На первый взгляд finch-rust выглядел и функционировал как ожидаемый инструмент, но в реальности выступал загрузчиком для скрытой вредоносной зависимости sha-rust, задача которой — credential-stealing.

Что было обнаружено

Ключевые факты инцидента:

• Малварь: пакет finch-rust — typosquatting-имитация легитимного finch.
• Скрытая зависимость: sha-rust внедрён в качестве скрытой зависимости и отвечает за кражу учетных данных.
• Активность разработки: sha-rust претерпел восемь быстрых итераций за две недели, что указывает на активное развитие и усложнение функционала злоумышленника.
• Маскировка: в вредоносный код была вставлена одна строка, требуемая для инициации кражи, а остальной функционал finch-rust работал аналогично оригиналу, чтобы не привлекать внимания.

Механика атаки

Атака реализована через комбинацию методов, предназначенных для скрытного запуска и обеспечения долговременной эксплуатации:

• Основной crate выступает как загрузчик и автоматически подключает скрытую зависимость (sha-rust), которая содержит payload для credential-stealing.
• Техника obfuscation: строки в кодировке base64 и запутанные/неинформативные имена функций используются для затруднения анализа и обхода сигнатурных механизмов детекции.
• Конфигурация зависимостей настроена так, чтобы автоматически обновлять вредоносную нагрузку, что увеличивает масштаб и устойчивость атаки.

Актор и вектор доверия

Злоумышленник использовал комбинацию социальных инженерных приёмов и фальсификаций:

• Актор называл себя «faceless» и успешно выдал себя за заслуживающего доверия пользователя GitHub radioman — реального разработчика Rust с историей вкладов.
• Для укрепления доверия были сфабрикованы адрес электронной почты и URL-адреса хранилища; при этом реальных вредоносных репозиториев нет.

Соответствие методам MITRE ATT&CK

Активность выравнивает ряд тактик и техник из фреймворка MITRE ATT&CK:

• Compromise supply chain — компрометация цепочки поставок через вредоносный пакет.
• Execution with user involvement — выполнение кода через библиотеки, используемые разработчиками.
• Obfuscation — запутывание кода (base64, запутанные имена функций).
• Credential access / Exfiltration — кража и возможная эксфильтрация учетных данных через каналы командования и управления (C2).

Какие данные под угрозой

Целью злоумышленника стали файлы, содержащие конфиденциальную пользовательскую информацию и учетные данные — токены, конфигурации и другие секреты, которые могут находиться в системах разработчиков или CI/CD окружениях. Автоматическое обновление зависимости увеличивает риск массовой компрометации проектов, которые невнимательно принимают внешние пакеты.

«Случай иллюстрирует опасности цепочки поставок и подчеркивает необходимость для разработчиков проявлять осторожность при подключении зависимостей в своих проектах.»

Рекомендации для разработчиков и команд безопасности

Ниже — практические шаги, которые помогут снизить риск подобных атак:

• Тщательно проверяйте авторство пакетов: сверяйте аккаунты, email и URL репозитория; будьте осторожны с пакетами, имитирующими популярные имена.
• Используйте инструменты сканирования зависимостей: cargo-audit, cargo-deny и другие SCA-инструменты для выявления известных уязвимостей и подозрительных пакетов.
• Фиксируйте и пиньте версии зависимостей (используйте Cargo.lock), избегайте автоматического принятия новых мажорных версий без ревью.
• Включите код-ревью для обновлений зависимостей и автоматические проверки в CI (SAST, анализ supply chain provenance, проверки подписи артефактов).
• Если возможно — используйте vendoring (vendoring) зависимостей или внутренние кеши (включая проверку контрольных сумм) для критичных проектов.
• Требуйте двухфакторную аутентификацию для публикации пакетов и следите за активностью аккаунтов, которые имеют доступ к репозиториям/публикации.
• Поддерживайте политику минимальных привилегий для токенов и секретов, используемых в CI/CD, и регулярно вращайте ключи.

Что делать при обнаружении компрометации

• Немедленно удалить/изолировать подозрительный пакет и откатить зависимость на проверенную версию.
• Ревокация и ротация всех затронутых учетных данных и токенов (CI/CD токены, доступы к репозиториям и т.д.).
• Провести аудит систем и логов на предмет эксплойта и исходящих соединений к C2.
• Сообщить о инциденте в сервисы hosting/registry (crates.io, GitHub) и при необходимости — в CERT/команды реагирования.
• Уведомить пользователей/партнёров, если есть риск утечки их данных.

Вывод

Инцидент с finch-rust — наглядное напоминание о том, что цепочки поставок в программном обеспечении остаются одним из самых уязвимых мест современной разработки. Даже пакет, который внешне повторяет функциональность легитимного инструмента, может содержать скрытые механизмы для кражи учетных данных. Разработчикам и DevOps-командам необходимо сочетать автоматические инструменты проверки с внимательным человеческим ревью и строгими политиками управления зависимостями, чтобы снизить риск подобных атак.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.