Ledger предупредила разработчиков и пользователей о кампании в экосистеме NPM, где злоумышленники пытаются встроиться в цепочку поставки зависимостей и впрыснуть код, перехватывающий адреса получателя в кошельках/веб-интерфейсах. Риск сценария прост: вы вводите адрес для вывода или подписываете транзакцию в UI dApp, а вредоносный скрипт незаметно подставляет «свой» адрес. Итог — средства уходят на кошелёк атакующего. Такой класс инцидентов относится к supply-chain атакам, когда компрометируется не ваш ПК напрямую, а цепочка библиотек и инструментов, на которых строится приложение.

Как выглядит эксплуатация

• Зависимость-двойник (typosquatting / dependency confusion): пакет с похожим именем попадает в проект (или в CI-сборку) и исполняет вредоносный postinstall/runtime-скрипт.
• Подмена в рантайме: скрипт добавляет «наблюдатель» за буфером обмена/DOM-полями и замещает адрес получателя, memo/tag, параметры свопа.
• Инжект в расширения/веб-вью: вредонос внедряется в окружение, через которое пользователь подтверждает перевод, и подменяет данные перед подписью.

Кого это затрагивает

Признаки, что что-то не так

• Адрес «сам меняется» после вставки — последние символы уже не те, что копировали.
• В истории клика подтверждения отображается не тот токен/сумма/адрес.
• Кошелёк/сайт внезапно требует дополнительные разрешения (например, широкие allowance перед простым переводом).

Что делать пользователю прямо сейчас

1. Подтверждай глазами. Всегда сверяй первые и последние 6–8 символов адреса на экране аппаратного кошелька перед подписью. Это последняя точка истины.
2. Адресная книга / whitelist. Для частых получателей используй сохранённые адреса; для новых — сначала отправь микроплатёж, затем основную сумму.
3. Минимизируй «копипасту». Вставляй адрес только один раз, не открывая посторонние вкладки. Если замечаешь подмену — перезагрузи страницу, очисти буфер, проверь систему.
4. Гигиена ключей. Никогда не вводи seed-фразу в браузере; держи приватные ключи оффлайн/в аппаратном кошельке. Что это и почему важно — см. базу по seed-фразе.
5. 2FA и почта. На всех биржах/он-рампах включи 2FA (TOTP), резервные коды и дополнительную проверку на вывод. Подробнее о 2FA — в глоссарии здесь.

Что делать разработчикам и командам

Сборка и зависимости

• Lock-файлы и «запертая» сборка: коммить package-lock.json/yarn.lock/pnpm-lock.yaml, собирать прод через npm ci/pnpm i --frozen-lockfile. Запретить mutation зависимостей в CI.
• Отключить опасные скрипты: npm config set ignore-scripts true в CI; whitelisting для пакетов, где скрипты реально нужны.
• Проверка имён: аудит на typosquatting, сравнение списков maintainer’ов, сравнение хэшей бандла/версии.

Поставка фронтенда

• Subresource Integrity (SRI) для внешних скриптов, строгая Content-Security-Policy, запрет unsafe-inline.
• Версионирование и мониторинг: подпись артефактов, алерты на изменение хэшей, двухэтапный деплой (staging→prod) с визуальным снапшот-диффом.
• Kill-switch: быстрый rollback, отключение «свежих» фич, если метрики/алерты срабатывают.

NPM-аккаунты и доступы

• 2FA на NPM, Git, облаке, реестрах. Убери доступы бывших сотрудников; токены — с минимальными правами и коротким TTL.
• Проверка посторонних зависимостей: никакого curl | bash в пайплайне; артефакты — только из доверенных реестров.

Если подозреваешь подмену адреса

FAQ

Аппаратный кошелёк спасает от подмены адреса?

Он не даёт подписать транзакцию «вслепую»: на экране видно адрес, сумму и сеть. Но если пользователь не сверяет данные и подтверждает, риски остаются. Дисциплина подтверждения — критична.

Если адрес в буфере уже подменили — деньги потеряны?

Нет, пока вы не подписали и не отправили транзакцию. Подмена в поле формы — ещё не перевод. Сравнивай адрес на финальном экране и, при сомнении, отменяй операцию.

Достаточно ли антивируса/блокировщика скриптов?

Это полезные слои, но не серебряная пуля. Основная защита — контроль цепочки поставки, дисциплина сборки и проверка данных на экране устройства подписи.

Вывод

Supply-chain атаки на NPM реальны и опасны тем, что бьют по доверенной цепочке сборки и по привычным пользовательским действиям («скопировать/вставить адрес»). Защита складывается из четырёх вещей: дисциплина подтверждения на аппаратном экране, whitelists/микропереводы у пользователей, «запертая» сборка и жёсткая политика скриптов у разработчиков, а также строгий контроль доступа к реестрам и репозиториям. Чем раньше обнаружен «ядовитый» пакет, тем меньше ущерб — держите алерты и откат готовыми к одному клику.

Полезные ссылки

• Хранение у себя vs у провайдера
• Управление рисками: базовая памятка

Обновлено: 23.09.2025, 05:40