Версия 1.20.21 пакета @injectivelabs/sdk-ts на npm оказалась троянизированной: она воровала приватные ключи и seed-фразы криптокошельков. Для русскоязычной IT-аудитории это не очередная страшилка про Web3, а вполне приземлённая атака на npm: один скомпрометированный аккаунт в GitHub, несколько минут до отката, и десятки команд рискуют утянуть вредоносный код в прод, CI или локальные машины разработчиков.
О компрометации, как пишет BleepingComputer, сообщили исследователи Socket, Ox Security и StepSecurity. Речь идёт о TypeScript/JavaScript SDK для работы с блокчейном Injective, который используют разработчики кошельков, торговых ботов, децентрализованных бирж, DeFi-сервисов и платёжных инструментов. По данным npm, у пакета около 50 тысяч загрузок в неделю. Этого более чем достаточно, чтобы инцидент быстро вышел за пределы одного проекта и превратился в проблему цепочки поставок.
Сценарий атаки выглядел неприятно знакомо. По данным исследователей, злоумышленник получил доступ к GitHub-аккаунту легитимного контрибьютора проекта и 8 июня внёс первые подозрительные коммиты. Вскоре после этого на npm вышла вредоносная версия 1.20.21. На этом атакующий не остановился: он опубликовал ту же версию ещё для 17 связанных пакетов проекта и зафиксировал их на скомпрометированном SDK. Владельцы репозитория заметили проблему в течение нескольких минут, откатили изменения и выпустили чистую версию 1.20.23. Но у supply-chain атак неприятная математика: если вредоносный релиз успели подтянуть автоматические обновления, локальные сборки или пайплайны, откат в репозитории уже не отменяет факт заражения.
Известный на текущий момент масштаб выглядит так: вредоносный пакет скачали 310 раз до того, как его пометили deprecated. Не удалили, а именно пометили устаревшим, так что сам артефакт и вредоносные GitHub-релизы оставались доступны. Отдельный риск в том, что у пакета есть 87 прямых зависимостей на npm, а значит след тянется дальше по графу. Ox Security оценила суммарное число загрузок этих зависимых пакетов более чем в 112 тысяч. Это не означает 112 тысяч подтверждённых компрометаций, но хорошо показывает, почему атака на npm давно перестала быть узкой проблемой maintainers: один пакет в центре экосистемы может задеть куда больше компаний, чем кажется по его собственной статистике.
Технически вредонос вел себя не как грубый дроппер, который срабатывает сразу после установки. Это делало инцидент опаснее и менее заметным. По данным исследователей, код активировался только тогда, когда разработчик вызывал функции SDK для генерации или импорта ключей кошелька. В этот момент пакет перехватывал полную mnemonic seed-фразу и приватный ключ, кодировал данные в base64 и готовил к отправке. StepSecurity добавляет важную деталь: секреты не улетали мгновенно, а складывались в очередь примерно на две секунды, после чего отправлялись пачкой в HTTP POST-запросе. Причём для эксфильтрации использовался публичный инфраструктурный endpoint Injective Labs, чтобы трафик выглядел легитимно и не бросался в глаза. Для защитных средств это почти издевательски удобный маскировочный ход: запрос идёт на ожидаемый домен, а вредоносная логика живёт внутри легального сценария работы SDK.
Практический вывод для команд, которые работают с JavaScript и npm, здесь шире крипторынка. Если у вас в проекте есть код, который оперирует кошельками, сид-фразами, API-ключами, токенами доступа или любыми другими секретами, модель угроз должна исходить из того, что компрометирован может быть не только пакет с миллионной аудиторией, но и вполне нишевый SDK. Особенно если он тянется в разработческие утилиты, внутренние CLI, скрипты миграций или тестовые стенды, где контроль обычно слабее, чем в проде. В истории с Injective вредонос не ломал сборку и не устраивал шум. Он делал ровно то, что делает самый неприятный класс supply-chain атак: вёл себя достаточно «нормально», чтобы его успели запустить.
Для разработчиков и security-команд список первоочередных действий здесь довольно прямолинеен. Если инфраструктура или локальные машины могли получить версию 1.20.21, нужно проверить, подтягивался ли пакет напрямую или транзитивно, и не полагаться только на lockfile в текущем состоянии. Если через заражённый SDK создавались или импортировались кошельки, исследователи советуют считать их скомпрометированными: перевести активы в новые кошельки и заменить все связанные секреты в окружении. Для бизнеса это ещё один аргумент в пользу более жёсткой дисциплины вокруг зависимостей: обязательная фиксация версий, контроль обновлений, аудит GitHub-аккаунтов мейнтейнеров, наблюдение за аномалиями в релизах и хотя бы базовая проверка того, какие именно пакеты в проекте умеют читать или генерировать чувствительные данные.
Главный неприятный вопрос после этой истории звучит просто: сколько supply-chain атак уже сидят не в install-скриптах, а в «нормальной» бизнес-логике библиотек и ждут конкретного вызова функции. История с Injective показывает, что следующая атака на npm вполне может не шуметь вообще: она просто дождётся, пока разработчик сам передаст ей самый ценный секрет.