Осенью 2025 года крупная атака на цепочку поставок NPM показала, насколько хрупкими могут стать современные зависимости программного обеспечения — особенно для пользователей и разработчиков криптовалют.
Целью атаки стал экосистема JavaScript, где миллионы веб- и программных проектов полагаются на сторонние пакеты. Некоторые вредоносные пакеты были созданы для вмешательства в транзакции с криптовалютой, включая мониторинг или замену адресов кошельков в браузерных потоках. Позже, в виде червь-подобной кампании, известной как Shai-Hulud, злоумышленники украли учетные данные разработчиков и CI/CD, а также распространялись через взломанные аккаунты поддерживающих пакеты.
Непосредственный инцидент прошел, но риск остался. По мере ускорения разработки с помощью ИИ и автоматического обнаружения уязвимостей злоумышленники могут быстрее сканировать, использовать и злоупотреблять слабостями цепочки поставок программного обеспечения, чем раньше.
Не все криптокошельки пострадали. Некоторые кошельки, ориентированные на Bitcoin, в частности Nunchuk и Blockstream (жесткий кошелек Jade), публично заявили, что их приложения не были подвержены этой конкретной атаке NPM.
Один из возможных выводов — что давно существующий компромисс между безопасностью и функциональностью может стать все более актуальным. Кошельки, которые ставят безопасность выше поддержки как можно большего числа активов, интеграций и зависимостей, обычно работают с меньшей сложностью и меньшей атакуемой поверхностью.
По мере ускорения разработки программного обеспечения и обнаружения уязвимостей с помощью ИИ, минимизация сложности может стать одной из самых эффективных стратегий безопасности для пользователей, разработчиков и поставщиков услуг.
Что произошло?
Осенью 2025 года серия компрометаций цепочки поставок затронула экосистему JavaScript и её реестр пакетов NPM. Злоумышленники получили доступ к доверенным аккаунтам поддерживающих пакеты и выпустили вредоносные обновления для библиотек программного обеспечения, используемых тысячами приложений.
После установки эти взломанные пакеты могли выполнять различные вредоносные действия, включая кражу учетных данных, компрометацию сред разработчиков или манипуляции с транзакциями, связанными с криптовалютой.
Некоторые характеристики делали эти инциденты особенно тревожными:
- Популярные пакеты NPM часто скачиваются миллионы раз в неделю.
- Современные приложения часто зависят от сотен или даже тысяч сторонних библиотек.
- Компрометация одного доверенного компонента может быстро распространиться по крупной экосистеме программного обеспечения.
- Некоторые вредоносные пакеты специально нацелены на пользователей криптовалюты, пытаясь изменить адреса кошельков или данные транзакций.
Урок прост: сложность стоит денег с точки зрения безопасности. Каждая дополнительная зависимость, интеграция и функция добавляют еще один кусок кода, которому нужно доверять, его нужно обслуживать и защищать.
По мере того как злоумышленники всё чаще используют автоматизацию и инструменты с поддержкой ИИ, снижение сложности может стать одним из самых сильных преимуществ безопасности, доступных пользователям, разработчикам и поставщикам услуг.
Почему экосистема JavaScript — такая привлекательная цель?
Современная разработка на JavaScript сильно зависит от NPM — реестра пакетов, используемого многими веб-приложениями, инструментами разработчика и программными проектами.
Один проект может зависеть от:
- сотен прямых пакетов
- тысяч косвенных зависимостей
Многие разработчики не знают все библиотеки, которые их приложение в конечном итоге загружает. В слабых инженерных средах некоторые могут просто не обращать внимания, пока что-то не сломается.
Это создает три основные риска:
- Слишком много зависимостей для ручного обзора: дерево зависимостей зачастую слишком большое для реалистичного построчного анализа.
- Доверие по репутации: популярные пакеты часто предполагаются безопасными, потому что «их все используют».
- Автоматизированные сборочные системы: системы CI/CD могут быстро внедрить взломанные пакеты, если обновления зависимостей не закреплены, не проверены или не мониторятся.
Именно это делает атаки на цепочку поставок NPM особенно опасными. Злоумышленнику не нужно взламывать каждый целевой объект напрямую.
Взлом одного доверенного пакета может быть достаточным, чтобы затронуть множество проектов ниже по цепочке.
Почему это так опасно?
Пользователи могут делать всё правильно — и всё равно оказаться под угрозой
Большинство кибератак требуют, чтобы жертва совершила ошибку. Кликнула по вредоносной ссылке. Установила зараженное ПО. Посетила фальшивый сайт.
Атаки через цепочку поставок — другое дело.
Пользователь может соблюдать все рекомендуемые меры безопасности и всё равно стать жертвой, потому что само приложение незаметно загружает взломанный код из доверенного источника.
Доверие становится вектором атаки
Традиционные модели безопасности предполагают, что программное обеспечение, скачанное из официальных источников, более надежно, чем полученное из других мест.
Атаки через цепочку поставок используют именно это предположение.
Вредоносный код поступает через легитимные механизмы обновления, доверенные репозитории пакетов и компоненты программного обеспечения, которые разработчики используют ежедневно.
Обнаружение — сложная задача
Взломанные пакеты часто выглядят легитимными:
- Они скачиваются из официальных репозиториев.
- Могут быть подписаны или опубликованы доверенными поддерживающими.
- Вредоносный код часто скрыт, зашифрован или обфусцирован.
- Пострадавшее ПО может продолжать работать нормально.
В результате такие компрометации могут оставаться незамеченными достаточно долго, чтобы затронуть большое число пользователей и систем.
Последствия выходят за рамки одного приложения
Когда широко используемая зависимость становится взломанной, последствия могут распространиться далеко за пределы исходной цели.
Один вредоносный пакет в конечном итоге может затронуть:
- веб-сайты
- расширения браузеров
- приложения кошельков
- инструменты разработчика
- внутренние бизнес-системы
- бэкэнд-сервисы и API
Это делает атаки через цепочку поставок системной угрозой, а не отдельным инцидентом безопасности.
Как взломанный пакет может повлиять на пользователей криптовалют?
- Приложение загружает взломанный зависимый компонент
Доверенный пакет NPM получает вредоносное обновление и становится частью программного стека приложения.
- Вредоносный код выполняется внутри доверенного приложения
Поскольку код загружается самим приложением, он наследует те же разрешения и уровень доверия, что и остальное программное обеспечение.
- Данные транзакций могут быть мониторингованы или изменены
Некоторые вредоносные пакеты были созданы для мониторинга транзакций с криптовалютой и, при определенных условиях, попытки заменить адреса кошельков или данные транзакций на адреса, контролируемые злоумышленником.
- Пользователь одобряет транзакцию
Если манипуляция останется незамеченной и транзакция будет одобрена, средства могут быть отправлены на адрес злоумышленника вместо предполагаемого получателя.
- Проверка на доверенном экране прерывает атаку
Пользователи, проверяющие адреса на экране аппаратного кошелька, имеют возможность обнаружить манипуляцию перед одобрением транзакции.
Почему проверка на аппаратном кошельке все еще важна
Одна из причин, почему этот инцидент привлек внимание широкой криптосообщества — это то, что некоторые вредоносные пакеты пытались изменить данные транзакций, отображаемые на экране компьютера.
Именно этого типа угрозы предназначены для снижения аппаратными кошельками.
Аппаратные кошельки предоставляют независимый экран для проверки
- Приватные ключи остаются внутри устройства.
- Транзакции требуют подтверждения непосредственно на аппаратном кошельке.
- Адреса назначения можно проверить на отдельном доверенном экране.
Если компьютер, браузер или приложение кошелька окажутся взломанными, аппаратный кошелек все равно сможет показать реальные детали транзакции, которые собираются подписывать.
Оставшийся риск — человеческое поведение
Аппаратный кошелек может защитить только то, что пользователь проверяет. Если устройство отображает адрес злоумышленника и пользователь одобряет его без проверки, механизм защиты фактически обойден.
Почему программные кошельки подвержены большему риску
Программные кошельки обычно работают на том же устройстве с подключением к интернету, что и браузер, операционная система и программный код, которые могут быть затронуты взломанным компонентом.
Во многих случаях интерфейс кошелька и код, отвечающий за формирование или отображение деталей транзакции, делят одну и ту же границу доверия.
Это не означает, что все программные кошельки автоматически небезопасны. Но без независимого экрана для проверки, обнаружить манипуляции с транзакциями сложнее для пользователя.
Это особенно актуально для браузерных кошельков, Web3-приложений и сложных взаимодействий с умными контрактами, где пользователь часто должен доверять тому, что показывает интерфейс приложения.
Как снизить риски атак через цепочку поставок
Полностью избежать атак через цепочку поставок не всегда возможно для конечных пользователей. Но они все равно могут ограничить ущерб, предполагая, что любое устройство с подключением к интернету или интерфейс кошелька в конечном итоге будет подвержено рискам — особенно в эпоху, когда злоумышленники, использующие ИИ, могут обнаруживать, использовать и эксплуатировать уязвимости с беспрецедентной скоростью.
Относитесь к горячим кошелькам как к расходным
Любое устройство, подключенное к интернету, следует считать потенциально взломанным.
Это не значит, что не стоит использовать мобильные кошельки, расширения браузеров или настольные приложения. Они полезные инструменты. Но их следует использовать для удобства и повседневных транзакций, а не как долгосрочные хранилища для значительных сумм.
Разделяйте удобство и безопасность
Самая эффективная защита — разделение подтверждения транзакции и устройства с подключением к интернету.
Аппаратные кошельки, такие как Blockstream Jade и Coldcard, созданы именно по этому принципу. Даже если компьютер, браузер или приложение кошелька окажутся взломанными, пользователь все равно сможет проверить детали транзакции на независимом устройстве перед их подтверждением.
Проверяйте то, что подписываете
В конечном итоге, устройства безопасности не могут заменить внимательность пользователя.
Аппаратный кошелек может защитить только то, что пользователь действительно проверяет. Если адрес злоумышленника появляется на экране устройства и одобряется без проверки, механизм защиты фактически обойден.
Тщательно проверяйте транзакции
Один из самых опасных аспектов вредоносного ПО для изменения транзакций — это то, что оно может менять то, что вы видите на экране компьютера, не изменяя фактическое происходящее в фоновом режиме.
Перед одобрением любой транзакции:
- Проверьте адрес на экране кошелька: Если используете аппаратный кошелек, всегда сравнивайте адрес назначения, отображаемый на устройстве, с тем, куда вы собираетесь отправить средства.
- Проверьте больше первых и последних символов: Сложные злоумышленники могут создавать адреса, намеренно похожие на целевой, включая совпадение первых и последних нескольких символов. Быстрый визуальный осмотр часто недостаточен. Проверьте начало, середину и конец адреса перед подтверждением.
- Используйте второй канал проверки для крупных переводов: Для значительных сумм подтвердите адрес назначения независимо с получателем через другой канал связи перед отправкой средств.
Несколько дополнительных секунд проверки деталей транзакции могут предотвратить дорогостоящую ошибку, которую невозможно будет исправить.
Самостоятельное хранение vs. мультиподпись с помощью помощи
Самостоятельное хранение отлично подходит для тех, кто понимает риски, готов вкладывать время («доказательство работы») и может создать дисциплинированную систему. Это самый высокий уровень самоуправления и наш предпочтительный совет для пользователей, способных управлять этим правильно.
При этом мы понимаем, что не у всех есть время, уверенность или навыки кибербезопасности для самостоятельной настройки — особенно если активы могут составлять значительную часть сбережений.
Избегать ошибок — обязательно. Они должны и могут быть предотвращены.
Для крупных личных активов, семейных фондов или бизнес-казначейств мультиподписи помогают устранить единственные точки отказа, распределяя полномочия на одобрение между несколькими устройствами, локациями или лицами. Многие опытные пользователи создают и управляют такими системами самостоятельно, другие предпочитают консультации при настройке или постоянную поддержку.
Для крупных личных активов, желающих получить помощь опытных специалистов, наша внутренняя команда консультантов готова помочь вам создать устойчивую систему и избежать распространенных ошибок.
Наша компания работает в этой сфере более десяти лет. За это время мы видели и пережили всё: мошенничество с «заготовками свиней», государственные киберпреступные группы, неправильные бэкапы, фишинг, потерянные ключи, взломанные устройства и всё более изощренную киберпреступность. Мы считаем, что наш опыт выживания — это уже сам по себе показатель.
Сегодня мы тесно сотрудничаем с экспертами по киберугрозам и вмешательствам по делам, связанным с украденными или находящимися под угрозой цифровыми активами, а также продолжаем отслеживать новые модели атак на границе индустрии.
Хотя вполне возможно самостоятельно создать такую систему благодаря безразличной природе Bitcoin, есть и категория личных активов, семейных фондов и бизнес-казначейств, для которых подходит поддерживаемая мультиподпись.
Цель — снизить избегаемые риски и устранить единственные точки отказа там, где это возможно.
Одна неосторожная ошибка, сломанное устройство или взломанный компьютер не должны стать причиной потери доступа к межпоколенческому богатству.
Заключение
Инциденты с NPM со временем забудутся. Уроки — нет.
Долгие годы пользователей учили избегать подозрительных загрузок, фейковых сайтов и очевидных мошенничеств. Атаки через цепочку поставок так опасны, потому что обходят очевидные признаки опасности. ПО может быть легитимным. Источник — официальный. Разработчики — жертвы.
В все более сложном мире программного обеспечения безопасность уже не сводится только к избеганию злоумышленников. Это снижение ненужного доверия, минимизация сложности и независимая проверка критических действий.
В Bitcoin «не доверяй, проверяй» также применимо к программному обеспечению.
