LINUX.ORG.RU

Новый червь ChainDrop поразил более 400 NPM-пакетов

 , , , ,


0

1

Зафиксирована массовая атака на пакеты в репозитории NPM, проводимая с использованием нового самораспространяющегося червя ChainDrop, подставляющего вредоносное ПО в зависимости. В результате атаки опубликовано 2212 вредоносных выпусков для 444 пакетов. Наиболее популярные из скомпрометированных пакетов keyv, flat-cache и file-entry-cache насчитывают 154, 149.9 и 147.6 миллионов загрузок в неделю.

Загрузчик червя размещался в файлах setup.mjs и Math_Symbol.js, которые запускались при помощи preinstall-обработчика ("preinstall": "node setup.mjs"), вызываемого при установке поражённого пакета. Указанные скрипты загружали легитимный Bun runtime и обфусцированный код червя, размером 710 Кб. После активации червь выполнял поиск в системе и в переменных окружения токенов к NPM, PyPI, CircleCI, AWS, GCP, Docker, Azure, HashiCorp, KubernetesK8s и другим сервисам (всего анализировалось более 140 файловых путей, типа ~/.npmrc), а также анализировал память (через /proc/<pid>/mem) окружения GitHub Actions на предмет токенов и учётных данных.

В случае обнаружения токена для подключения к каталогу NPM червь автоматически публиковал новые вредоносные релизы для разрабатываемых в текущем окружении пакетов, поражая дерево зависимостей. В отличие от ранее выявленного червя Shai-Hulud 2.0 в ChainDrop была реализована техника EtherHiding для получения управляющих команд через публичный блокчейн Ethereum, задействовано шифрование для скрытия передаваемых на сервер атакующих конфиденциальных данных и обеспечено внедрение в файлы конфигурации Claude Code, VS Code и GitHub Copilot для закрепления присутствия в системе.

Атака началась с компрометации процесса формирования релизов на базе GitHub Actions для пакета keyv, насчитывающего 154 млн загрузок в неделю и используемого как зависимость в 1703 пакетах. Атакующие сформировали новую версию 6.0.0, подставив в неё вредоносный код, и опубликовали её с использованием механизма «Trusted Publishers» и корректной SLSA-аттестацией. После публикации червь поразил многие зависимые от keyv пакеты и по цепочке стал поражать непрямые зависимости.

Среди наиболее популярных пакетов, которые оказались поражены червём, опубликовавшим для них вредоносные релизы:

  • flat-cache 6.1.24 (149.8 млн загрузок в неделю);
  • file-entry-cache 11.1.6 (147.5 млн);
  • cacheable-request 13.0.20 (33.9 млн);
  • @cacheable/utils 2.5.1 (8.7 млн);
  • cacheable 2.5.1 (7.8 млн);
  • @cacheable/memory 2.2.1 (7.1 млн);
  • cache-manager 7.2.10 (4.2 млн);
  • @cacheable/node-cache 3.1.2 (1.5 млн).

>>> Источник: OpenNET

★★★★★

Проверено: Dimez ()
Последнее исправление: dataman (всего исправлений: 1)

Claude Code, VS Code и GitHub Copilot

Какая восхитительная поверхность атаки. :) Молодцы.

Stanson ★★★★★
()

вот только недавно в теме про AUR вспоминали npm-щиков...

Sylvia ★★★★★
()

насчитывают 154, 149.9 и 147.6 миллионов загрузок в неделю.

А представьте, что будет, когда left-pad заразят.

Last updated: August 4, 2026 at 18:10 UTC. Active investigation. Every package and version count in this post is as of this timestamp, and the number of compromised packages is still increasing as the worm keeps republishing itself.

Из-за любителей тащить себе left-pad от школьников теперь будут страдать нормальные люди.

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

Из-за любителей тащить себе left-pad от школьников

Лефтпад не лефтпад, но нода позволяет прописать четкие версии зависимостей.

ya-betmen ★★★★★
()

Вот бы запилить скриптик или софтину, которая автоматом бы проверяла новые пакеты на такие зловреды.. Хм..

LightDiver ★★★★★
()
Ответ на: комментарий от Aceler

Подозреваю это у кого-то докеросборщики каждый раз (при коммите в использующий всю эту чушь проект) заново всё скачивают т.к. состояние не хранят.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Допустим. Но существует факт, что механизмом блокировки версий никто не пользуется, потому что считается, что новые версии это обязательно исправление ошибок и никак иначе. Да и думать и проверять ничего не надо.

Aceler ★★★★★
()

Да кому эти пакеты сдались, нафига тратить время? Корпоративные структуры что ли так ими активно пользуются)?

REDDERa
()
Ответ на: комментарий от PPP328

Из-за любителей тащить себе left-pad от школьников теперь будут страдать нормальные люди.

К сожалению часто такую срань получаешь транзитивно, и особенно повлиять на неё не можешь. У меня это касается ещё и php composer, и python pip

skyman ★★★★★
()
Ответ на: комментарий от ya-betmen

Дырявость npm прямое следствие того что авторы абсолютно не умеют в систем дизайн

нода позволяет прописать четкие версии зависимостей

А должна по дефолту это делать. Еще в идеале нечеткие версии должны максимально неудобно прописываться, чтобы не было соблазна без нужны их использовать

«preinstall»: «node setup.mjs»

Pre-install и post-install скриптов в пакете не должно быть в принципе

заново всё скачивают т.к. состояние не хранят. Должен быть вендоринг пакетов по дефолту

В идеале еще не должно быть вложенных зависимостей, только peer-зависимости. Тогда юзеру будет их неудобно ставить, и при разработке пакета придется думать и сокращать колво зависимостей до минимума. В итоге в худшем случае будет 1-2 крупных зависимости типа тулкитов, а left-pad’оф не будет совсем.

Иделаный пакетник для разработки это качалка пакетов, которая их в vendor папку в репе проекта складывает и не больше

В текущем виде npm это хитросделанное решето из швейцарского сыра

Ali_Tycsan
()
Ответ на: комментарий от PPP328

Из-за любителей тащить себе left-pad

Проблема не в них, такие будут всегда, а в дебилах-авторах npm которые это поощряют и провоцируют дизайном пакетника

Ali_Tycsan
()
Ответ на: комментарий от Aceler

«было бы величайшей ошибкой думать» ПСС ВИЛ, т.42, с. 74

mumpster ★★★★★
()

обфусцированный код червя, размером 710 Кб

Джаваскриптисты такие Джаваскриптисты, скоро черви гигабайтные пойдут, чтоб их собрать надо будет 40 минут либы по дереву тянуть

pihter ★★★★★
()
Ответ на: комментарий от skyman

Вроде как в питоне версии принято указывать. И для косвенных пакетов тоже можно. Раньше было что-то типа pip list > requirements.txt

bbc69
()

для получения управляющих команд через публичный блокчейн Ethereum

Кем надо быть и на кого работать, чтобы это всё понаписать?
КНДР-ские программисты по заказу китайской разведки?

Saakx
()

Абсолютно все эти пользовательские репы - решето и небезопасный кал

mskrasnov
()
Ответ на: комментарий от bbc69

Вроде как в питоне версии принято указывать. И для косвенных пакетов тоже можно. Раньше было что-то типа pip list > requirements.txt

В питоне та же поверхность. Мне тут давеча мобила ночью какие-то звуки начала издавать. Через полчаса выяснил, что это тг просил пароль. И раз я быстро не сообразил, то тг-серверы сами все решили и моей помощи как бы не требовалось.

Еще через пару часов я вспомнил, что днем ранее обновлял харнес вокруг старых нейронок, и там подозрительно много возни было вокруг питона 3.10. Похоже, тг сработал как safety canary. Не будь в системе десктопного тг-клиента, я бы ничего не почувствовал.

Форматнул диск к херам. На новой системе расставил ханипоты.

sarumeister
()
Ответ на: комментарий от sarumeister

В питоне та же поверхность.

Я про правила хорошего тона, так сказать. Версии надо столбить хотя бы для того, чтобы потом не удивляться, почему на компе работает, а на сервере - нет. Ну а дальше зависит от мейнтейнера пакета. Если он свободно к версиям относится, то тут только руками развести.

Впрочем, надо признать, версии часто ограничивают в формате >=1.5.0,<2.0.0. При таких раскладах поймать болячку в целом возможно.

bbc69
()
Ответ на: комментарий от PPP328

Нормальные люди не таскают мусор с помойки. Да и само по себе увлечение жопоскриптами уже тревожный симптом. Надо сразу лечиться, не запускать это дело.

bread
()
Ответ на: комментарий от Ali_Tycsan

при разработке пакета придется думать

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

bread
()
Ответ на: комментарий от bread

Тут в соседней теме попадалась ссылка на популярность языков. Посмотрел я, что там по жс. Боюсь, у меня для тебя плохие новости…

bbc69
()
Ответ на: комментарий от Saakx

Та не, то окучивают кровавый энтерпрайз, жабокодеров на мороз, покупайте наших ииниипацапогромистовчугунных :)

Morin ★★★★★
()
Ответ на: комментарий от Ali_Tycsan

Это что значит? Вместо использования готовых пакетов, делать свой велосипед аналог?

PeleWin
()
Ответ на: комментарий от REDDERa

Корпоративные структуры что ли так ими активно пользуются)?

Да.

question4 ★★★★★
()
Ответ на: комментарий от Aceler

Но так и есть. Зловред может и в старом пакете быть. И так и будет жить хоть там трижды его почистят.

usermod
()

должны страдать

thunar ★★★★★
()
Ответ на: комментарий от Saakx

Надо быть всего лишь тем, кто понимает что вся эта вебная похабень - натурально угроза для человечества и лютое дерьмо. Люди которые добровольно соглашаются в это всё вляпаться и использовать - либо враги человечества, либо говноеды.

Ни тех ни других вообще ни капли не жалко. Если при этом удаётся поживиться всякими приватными данными этих недоумков и/или вредителей - в этом нет ничего зазорного вообще. Ибо все эти вебмакаки без единого исключения делают всё возможное для расширения тотального воровства приватных данных как ими самими, так и их хозяевами, либо напрямую, внедряя, например, возможности для фингерпиринтинга или там сбора информации о пользователе в свою веб-блоатварь, либо как минимум, вынуждая пользователя апгрейдить браузерные движки в которых количество зондов и огораживаний контроля пользователя над своим компом растёт с каждой версией, приводя к тому же самому результату - расширению воровства приватных данных. Можно, конечно пофилософствовать о том, насколько этично воровать приватные данные у тех, кто напрямую участвует в воровстве приватных данных у населения Земли в промышленных масштабах, но это будет не более чем очередное «анасзащо?».

Блокчейн Ethereum - отличное решение для использования против этого контингента. Вебмакаки по некоторым причинам ( это отдельная но не менее интересная тема :) ) предпочитают именно ETH для выпрашивания донатов или получения оплаты за свою вредительскую деятельность другой крипте. соответственно, даже если вебмакака озаботилась всякими фаерволами и пр, сеть ETH скорее всего будет доступна с компа «прошаренной в безопасности» вебмакаки без ограничений.

Stanson ★★★★★
()
Ответ на: комментарий от Ali_Tycsan

А как без них быть? Велосипедить каждую либу самому?!

«Теперь в мире стало на один бесполезный фреймворк больше.»

Ukka
()
Ответ на: комментарий от ya-betmen

В сях и плюсах пакетников нет и пользуются же както

И кто ж будет этим пользоваться?

Жрите трояны полной ложкой тогда, что ж поделать

Ali_Tycsan
()
Ответ на: комментарий от Ukka

Зло не сторонние либы, а концепция зависимостей. Из-за синдрома утенка это может быть сложновато понять.

Когда ты взял сторонню либу, кинул ее в папку с проектом и используешь - это ок

А когда ты прописал в манифесте что твоему проекту нужна такая то либа как зависимость, а пакетник автоматом это както разрулил - это уже не ок

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

Ali_Tycsan
()
Ответ на: комментарий от Ali_Tycsan

В сях и плюсах пакетников нет и пользуются же както

Вот именно что

както

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

В идеале еще не должно быть вложенных зависимостей, только peer-зависимости

Я непонятно написал, разверну мысль. Когда могут быть только peer-зависимости получается такая схема:

  • Если у пакета нет зависимостей, то юзер пишет install randompackage и он ставится
  • Если у пакета 1-2 крупных зависимости то юзер пишет install randompackage gtk pygtk и он ставится
  • А если у пакета как сейчас, 100 зависимостей и еще 1000 вложеных, то ему чтобы поставиь пакет придется вручную всю тыщу left-pad’оф прописать install randompackage left-pad dependency2 .... dependency1000

И кто ж будет этим пользоваться?

Поэтому в этом и смысл, пакетами у которых 100 left-pad’оф в зависимостях никто пользоваться не будет

Ali_Tycsan
()
Ответ на: комментарий от Ali_Tycsan

Да нет же, всей этой системой никто пользоваться не будет. Это ж чтобы налабать быстро и отдать, не думая о поддержке.

Кому надо самому там с зависимостями долбаться.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Если сервера npm отключить, то будут. Админ-серверы троянов же отключают, чем npm от них отличается?

Ali_Tycsan
()
Ответ на: комментарий от Ali_Tycsan

В чём преимущество установки кучи пакетов вручную по сравнению с автоматической, если каждый из этой кучи пакетов необходим для работы проекта?

Автоматическая установка не скачает ведь лишние пакеты просто потому что она автоматическая.

PeleWin
()
Ответ на: комментарий от PeleWin

Автоматическая установка не скачает ведь лишние пакеты просто потому что она автоматическая.

Если разрешить вложенные зависимости и их автоматическую установку, то для юзера нет разницы в использовании пакета без завимосистей и пакета с деревом из 1000 вложенных зависимостей

Нет особой проблемы в автоматической скачке и установке жестко прописанного списка зависимостей, проблемы начинаются когда появляются вложенные зависимости.

если каждый из этой кучи пакетов необходим для работы проекта? В том то и дело что не необходим, 80% пакетов в npm это мусор, такой как leftpad, в нормальной среде leftpad был бы функцией в проекте или std либе, а не сторонним пакетом.

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

Npm же поощряет плодить пакеты на каждый чих и делать говно, и говна уже столько что вам в миску потоком льется.

Думать при добавлении зависимостей это нормально, это вообще достаточно серьезный вопрос, оно и не должно быть удобным.

Ali_Tycsan
()
Ответ на: комментарий от anonymous_sama

С --ignore-scripts не получится массово трояны пихать, а значит не будет предлога ввести публикацию пакетов по паспорту в качестве защиты от мошенников

Ali_Tycsan
()
Ответ на: комментарий от Ali_Tycsan

Если у какого-либо пакета есть неиспользумые зависимости - их можно удалить в следующей версии пакета. И так - рекурсивно. По-видимому, Вы пытаетесь найти проблему там, где её нет.

В чём принципиальное отличие между библиотекой в Си++ и пакетом в Node.js? Библиотека не может зависеть от других библиотек? Вроде может. Библиотеки и пакеты и переиспользуемый код вообще «не нужны»? Вроде нужны.

Проблема, описанная в заголовке темы, конечно, есть, но она, по-моему, не связана с идеей использования внешних пакетов, вложенных пакетов и чужого кода в целом.

PeleWin
()
Ответ на: комментарий от Ukka

Контейнеры в принципе по себе рассадники дырявого и устарелого софта, если там что-то не популярное где авторы или сообщество регулярно его обновляют. Ибо самый простой способ запустить софт мамонта, не засирая хост, запустить его в контейнере.

anonymous_sama ★★★★★
()
Ответ на: комментарий от PeleWin

Вы пытаетесь найти проблему там, где её нет.

Проблема концептуальная, и я предупреждал что ее понять может быть сложно из-за синдрома утенка

В чём принципиальное отличие между библиотекой в Си++ и пакетом в Node.js?

В том что в плюсах нету пакетника. Любая зависимость кладется в проект руками и соответсвенно подключить либу у кототорой даже 10 своих зависимостей это геморой. В результате большинство либ имеют 0 зависимостей, редкие 1. И даже в крупных проектах зависимостей максимум десятка два.

Не 100, не 1000, не дерево из 100 уровней вложенности, а плоский граф из десятка сторонних либ.

И плюс зависимости принято вендорить, т.е хранить в репе проекта. И никто не будет обновлять зависимости на каждый чих, потому что это требует усилий, а на бессмысленные вещи силы тратить никому не хочется.

В итоге поверхность атаки в 1000 раз уже.

Какой iq надо иметь, чтобы думать что когда npm регулярно тянет из интернета дерево из 1000 пакетов, 970 из которых транзитивные, т.е вложенные это нормальная ситуация? Версии пакетов по дефолту не фиксированы, в каждом пакете можнет лежать install скрипт для ноды, а у ноды есть доступ к fs и к сети. Достаточно ОДНОЙ зависимости из 1000, для которой не зафиксировали версию, чтобы она стала потенциальной дырой размером с планету.

Ali_Tycsan
()
Ответ на: комментарий от anonymous_sama

Пакетник в системе ровно такой же источник зла, как и npm. И контейнеры прямое следствие этой проблемы.

не засирая хост

В системах без пакетников, от установки большиства софта хост не засирается

Ali_Tycsan
()
Ответ на: комментарий от Ali_Tycsan

Тогда вообще обновить можно будет только в ручную и вскоре вообще забудется что такая служба или сервис весит на таком-то порту пока не хакнут, тут же опять же одинаковые сервисы разных версий весящие на разных портах, остатки исходников распакованные в непредсказуемых местах и т.д.

В системах без пакетников, от установки большинства софта хост не засирается

Только лишь потому-что юзеров слаки (хотя там уже сейчас тоже pkgs есть) и LFS очень мало, и критических сервисов тем более сложных на контейнерах или из нескольких сервисов сразу на таких системах тоже очень мало, так что это ошибка выжившего. Тоже самое что и с OpenBSD, просто неуловимый джо, был неуловимым потому-что никому по существу он не был и нужен.

anonymous_sama ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.