18 пакетов npm скомпрометированы в крупной атаке на цепочку поставок

Великий компромисс npm: разбор инцидента

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

Это была не «грубая» операция; это была тщательно спланированная атака с использованием социальной инженерии для размещения клиентского финансового инструмента. Это наглядная демонстрация того, почему реактивный подход к безопасности приложений и цепочек поставок уже недостаточен.

Такой уровень угроз требует нового подхода к безопасности: нужно не только находить ошибки, но и предугадывать угрозы, понимая контекст кода и экосистемы.

Но сначала — сама атака.

Атака на цепочку поставок npm: мастер-класс по социальной инженерии

Атака была клиентским компромиссом, начавшимся с фишинговой кампании против мейнтейнера популярных npm-пакетов. Злоумышленники получили контроль над аккаунтом мейнтейнера и использовали доступ для инъекции вредоносного кода в 19 популярных зависимостей, которые вместе имеют более 2 миллиардов загрузок в неделю. Внедрённый полезный код был одинаковым во всех поражённых пакетах и был направлен на тихое похищение информации, связанной с криптоактивами.

Скомпрометированные пакеты и их вредоносные версии:

• ansi-styles @6.2.2
• debug @4.4.2
• chalk @5.6.1
• supports-color @10.2.1
• strip-ansi @7.1.1
• ansi-regex @6.2.1
• wrap-ansi @9.0.1
• color-convert @3.1.1
• color-name @2.0.1
• is-arrayish @0.3.3
• slice-ansi @7.1.1
• color @5.0.1
• color-string @2.1.1
• simple-swizzle @0.2.3
• supports-hyperlinks @4.1.1
• has-ansi @6.0.1
• chalk-template @1.1.1
• backslash @0.2.1
• error-ex @1.3.3

На момент публикации текущее состояние пакетов было следующим:

Как могла произойти компрометация

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

1. Один из скомпрометированных пакетов был установлен впервые, и вредоносная версия оказалась в окружении.

2. Контейнер был пересобран, и при сборке был включён один из уязвимых пакетов. Из-за отсутствия зафиксированных (locked) версий сборка подтянула последние (скомпрометированные) версии из npm, которые затем попали в артефакты.

3. Если была выполнена команда npm update, это могло повысить версии в package.json до последних (скомпрометированных) версий.

Пересборка артефакта после исправления обычно подтянет фиксированные версии и тем самым устраняет проблему.

Технический разбор вектора атаки и полезной нагрузки

Изначальная компрометация началась с продуманного фишингового письма с поддельного домена npmjs.help, имитировавшего официальный реестр (npmjs.com). В сообщении использовалась отлаженная социальная инженерия, чтобы обманом заставить мейнтейнера «обновить» свои 2FA-учётные данные на фейковой странице входа. Учётные данные и токен были затем отправлены на контролируемый злоумышленниками эндпоинт websocket-api2.publicvm.com.

Внедрённый код действовал как «Web3 drainer» — клиентская подмена/атака в браузере, предназначенная для перехвата и манипуляции транзакциями криптокошельков. После активации он тихо отслеживал подключённые кошельки и вмешивался в транзакции, в том числе выполнял подмену адресов.

Полезная нагрузка перехватывала стандартные браузерные API (fetch, XMLHttpRequest) и Web3 API (window.ethereum и API кошельков типа MetaMask / Phantom). Изменяя данные, выводимые на страницах (поля ввода, QR‑коды), вредоносный код мог скрытно заменять адреса и суммы, направляя средства на адреса злоумышленников.

Модуль подмены адресов поддерживал множество сетей: Ethereum, Bitcoin, Solana, Tron, Litecoin и Bitcoin Cash. Он также таргетировал on‑chain вызовы смарт‑контрактов, такие как ERC‑20 трансферы и approvals, чтобы похищать токены и управлять разрешениями. Логика подстановки адресов использовала алгоритм сходства строк (например, расстояние Левенштейна), чтобы находить «близкие по виду» атакующие адреса и делать подмену почти незаметной.

Рекомендации и выводы

Для команд без доступа к автоматизированным средствам безопасности приоритет — ручной аудит проектов. Удалите или понизьте версии скомпрометированных пакетов, пересоберите приложения из чистых исходников и просмотрите развернутые окружения на предмет вставленного кода. Разработчикам и конечным пользователям рекомендуется отозвать существующие токен‑разрешения, поменять секреты и, по возможности, перевести средства в новые кошельки, созданные оффлайн.