Шкідливе програмне забезпечення CanisterWorm

Складна атака на ланцюг поставок, спочатку спрямована на широко використовуваний сканер Trivy, переросла в ширшу компрометацію, яка вразила численні npm-пакети. Зловмисники, що стоять за кампанією, підозрюються у розгортанні раніше недокументованого саморозповсюджувального черв'яка, відомого як CanisterWorm, що значно збільшило масштаби та вплив вторгнення.

Зловмисне програмне забезпечення отримало свою назву від використання контейнера Інтернет-комп'ютерного протоколу (ICP) – захищених від несанкціонованого доступу смарт-контрактів, розміщених на децентралізованому блокчейні, як частини своєї командної інфраструктури. Це перший публічно задокументований випадок використання контейнерів ICP для отримання кінцевих точок системи командування та управління (C2), що представляє нову та стійку тактику, яка ускладнює традиційні зусилля щодо пом'якшення наслідків.

Скомпрометовані пакети та вектор початкового доступу

Атака вплинула на кілька npm-пакетів різних сфер застосування, демонструючи широкий радіус ураження в ланцюжку постачання програмного забезпечення:

• 28 пакетів у сфері @EmilGroup
• 16 пакетів у сфері @opengov
• Додаткові пакети, включаючи @teale.io/eslint-config, @airtm/uuid-base32 та @pypestream/floating-ui-dom

Ця кампанія здійснилася одразу після компрометації облікових даних, яка дозволила зловмисникам публікувати шкідливі версії інструментів, пов'язаних з Trivy, зокрема trivy, trivy-action та setup-trivy, які містили вбудовану функцію крадіжки облікових даних. Вважається, що операція пов'язана з хмарно-орієнтованою кіберзлочинною групою TeamPCP.

Робочий процес інфекції та децентралізована командна інфраструктура

Ланцюг зараження починається під час процесу встановлення npm-пакета, де пост-інсталяційний скрипт виконує завантажувач. Цей завантажувач розгортає бекдор на основі Python, призначений для зв'язку з ICP-контейнером. Контейнер діє як розпізнавач мертвих папок, повертаючи URL-адресу, яка спрямовує заражену систему на завантаження та виконання наступного корисного навантаження.

Децентралізований характер інфраструктури ICP надає значну перевагу зловмисникам. Оскільки контейнер може динамічно оновлювати URL-адресу корисного навантаження, зловмисники можуть поширювати нові шкідливі бінарні файли по всіх заражених системах, не змінюючи саме розгорнуте шкідливе програмне забезпечення. Така архітектура також значно ускладнює зусилля з його видалення.

Механізм наполегливості та методи приховування

Збереження шкідливого процесу досягається шляхом створення користувацького сервісу systemd, налаштованого на автоматичний перезапуск. Ключові характеристики включають:

• Автоматичний перезапуск, що забезпечується директивою Restart=always
• 5-секундна затримка перед повторним запуском бекдора у разі його завершення
• Маскування сервісу під легітимне програмне забезпечення для моніторингу PostgreSQL під назвою «pgmon»

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

Адаптивна доставка корисного навантаження та поведінка вимикача зупинки

Бекдор періодично зв'язується з ICP-контейнером кожні 50 хвилин, використовуючи підроблений User-Agent браузера, щоб уникнути підозр. Повернена URL-адреса визначає наступну дію:

• Якщо URL-адреса вказує на дійсне корисне навантаження, шкідливе програмне забезпечення завантажує та виконує його
• Якщо URL-адреса містить «youtube.com», шкідливе програмне забезпечення переходить у стан спокою.

Цей механізм фактично служить віддаленим аварійним вимикачем. Перемикаючи URL-адресу контейнера між безпечним посиланням YouTube та шкідливим корисним навантаженням, зловмисник може активувати або деактивувати шкідливе програмне забезпечення на всіх заражених системах. Примітно, що раніше виконані корисні навантаження продовжують працювати у фоновому режимі, оскільки шкідливе програмне забезпечення не завершує попередні процеси.

Подібний аварійний вимикач на основі YouTube також спостерігався у зараженому трояном бінарному файлі Trivy (версія 0.69.4), який взаємодіє з тією ж інфраструктурою ICP через окремий дроппер Python.

Можливості черв'яків та їх автоматизоване поширення

Спочатку поширення спиралося на вручну виконаний скрипт під назвою deploy.js, який використовував викрадені токени автентифікації npm для впровадження шкідливого коду в доступні пакети. Цей скрипт не запускався під час встановлення, а служив окремим інструментом для розширення охоплення атаки.

Наступні варіанти CanisterWorm значно еволюціонували. У новіших версіях, таких як ті, що знаходяться в @teale.io/eslint-config (версії 1.8.11 та 1.8.12), черв'як включає самопоширення безпосередньо в процес встановлення пакета. Оновлений механізм включає:

• Вилучення токенів автентифікації npm із зараженого середовища
• Негайне виконання процедури поширення як окремого фонового процесу
• Автоматизована публікація скомпрометованих пакетів з використанням зібраних облікових даних

Цей перехід перетворює атаку з ручної кампанії на повністю автономну систему поширення.

Переростання в загрозу самодостатнього ланцюга поставок

Впровадження автоматизованого збору та самопоширення токенів знаменує собою критичну ескалацію. Будь-яка робоча станція розробника або конвеєр CI/CD, який встановлює скомпрометований пакет і містить доступні облікові дані npm, стає активним вузлом поширення. Це створює каскадний ефект, коли заражені пакети призводять до подальших заражень у залежностях нижче за течією.

На цьому етапі загроза еволюціонує за межі ізольованого компрометування облікового запису та перетворюється на самопідтримувану екосистему поширення шкідливого програмного забезпечення. Кожне нове заражене середовище сприяє поширенню, забезпечуючи експоненціальне зростання та значно ускладнюючи стримування.

Погіршує занепокоєння те, що тестування артефактів, таких як заповнювач корисного навантаження ('hello123'), вказує на те, що зловмисники активно вдосконалюють та перевіряють ланцюжок атаки перед розгортанням повністю функціональних шкідливих бінарних файлів.