В офіційному реєстрі npm було виявлено серію з 36 шкідливих пакетів, що маскувалися під плагіни для CMS Strapi. Ці пакети використовувалися для експлуатації Redis та PostgreSQL, розгортання reverse shell, викрадення облікових даних і встановлення постійного імпланта на скомпрометовані системи. Інцидент демонструє, наскільки вразливим стає ланцюг постачання ПЗ (software supply chain), коли інструменти розробки перетворюються на канал доставки шкідливого коду.
Маскування під Strapi плагіни: як працювала схема зловмисників
За інформацією SafeDep, кожен з виявлених npm-пакетів мав однакову мінімалістичну структуру: лише три файли — package.json, index.js та postinstall.js. Опис, посилання на репозиторій і домашню сторінку були відсутні, однак версія штучно встановлювалася на 3.6.8, щоб імітувати «зрілий» плагін для Strapi v3 з екосистеми спільноти.
Імена пакетів слідували єдиному шаблону: префікс “strapi-plugin-“ і далі слово на кшталт «cron», «database» або «server». Така схема створювала ілюзію легітимних розширень функціональності CMS і вводила в оману розробників, які звикли до подібних назв модулів. Водночас офіційні плагіни Strapi публікуються тільки в просторі імен @strapi/, що є критичною ознакою для відмежування справжніх і підроблених пакетів.
Завантаження шкідливих npm-пакетів відбувалося протягом приблизно 13 годин з використанням чотирьох фіктивних акаунтів: “umarbek1233”, “kekylf12”, “tikeqemif26”, “umar_bektembiev1”. Така тактика характерна для масованих supply chain атак, де зловмисники намагаються максимально швидко розповсюдити шкідливий код до моменту виявлення й блокування.
Технічний аналіз: роль postinstall-скриптів і еволюція шкідливого коду
Postinstall як прихований механізм виконання коду
Основна шкідлива логіка концентрувалася у скрипті postinstall, який автоматично запускається під час виконання команди “npm install”. Такий код виконується без прямої участі користувача і з тими самими правами, що й обліковий запис, який встановлює пакет. У середовищах CI/CD, Docker-контейнерах чи при запуску від root це дає зловмисникам дуже високий рівень доступу.
Цей приклад наочно демонструє системний ризик екосистеми npm: будь-який пакет із lifecycle-скриптами здатен виконувати довільний код у момент встановлення, перетворюючи ланцюг постачання ПЗ на привабливий вектор атаки. Подібні підходи вже неодноразово використовувалися в інших інцидентах із open source-пакетами в npm та PyPI.
Вісім варіантів корисного навантаження та зміна тактики
Фахівці SafeDep ідентифікували щонайменше вісім варіантів корисного навантаження, що послідовно змінювалися в ході кампанії. Аналіз свідчить про еволюцію тактики нападника від агресивної експлуатації до прихованого закріплення в інфраструктурі.
На початковому етапі переважали спроби віддаленого виконання коду (RCE) через Redis та escape-атаки на Docker з метою виходу за межі контейнера і захоплення хостової системи. Такий підхід характерний для атак на хмарну інфраструктуру та CI/CD пайплайни.
Далі фокус змістився на розвідку середовища: збір системної інформації, інвентаризацію оточення та аналіз конфігурацій. Це дозволяє нападнику краще розуміти архітектуру цільової системи й обирати оптимальні точки впливу.
У наступних версіях було виявлено жорстко прописані облікові дані та хостнейми для PostgreSQL, що давало змогу напряму підключатися до бази даних, оминаючи додаток. Такий доступ особливо небезпечний для криптобірж, платіжних шлюзів та інших фінтех-сервісів, де у БД зберігаються ключові цифрові активи.
Фінальні варіанти навантаження зосереджувалися на закріпленні в системі та викраденні облікових даних: встановленні постійного імпланта, розгортанні reverse shell і цілеспрямованому зборі чутливих секретів. Поєднання інтересу до баз даних, цифрових активів і використання статичних параметрів підключення вказує на високу ймовірність таргетованої атаки проти криптовалютної або фінтех-платформи.
Supply chain атаки проти open source: ширший контекст загрози
Виявлення шкідливих Strapi-плагінів вписується у зростаючу хвилю атак на ланцюг постачання ПЗ (supply chain attacks) в open source-екосистемах. Згідно з публічними звітами профільних компаній, зловмисники дедалі частіше обирають саме репозиторії пакетів — такі як npm і PyPI — як стартову точку для масштабних компрометацій.
У подібних сценаріях використовуються вкрадені акаунти мейнтейнерів, автоматизовані інструменти для масового зараження бібліотек, а також інтеграція шкідливого коду безпосередньо в процеси збірки CI/CD. У результаті одинична успішна атака здатна швидко набути крос-граничного ефекту, вражаючи сотні організацій по всьому світу через довірених постачальників і розробницькі ланцюги.
Практичні рекомендації для розробників та бізнесу
Командам, які могли встановлювати будь-які з вказаних шкідливих npm-пакетів, доцільно припустити факт компрометації та негайно виконати ротацію всіх облікових даних: паролів до баз даних, API-ключів, секретів CI/CD та токенів доступу. Додатково важливо перевірити журнали подій на предмет підозрілої активності та за можливості повністю перевстановити критичні сервіси з довірених образів.
Щоб знизити ризики подібних supply chain атак у майбутньому, варто впровадити комплексний підхід до безпеки залежностей:
1. Жорстка валідація залежностей. Перевіряти namespace (для Strapi — лише @strapi/), репозиторій, історію версій, кількість завантажень і репутацію автора. Уникати пакетів без опису, документованого походження та прозорої історії змін.
2. Контроль lifecycle-скриптів. У чутливих середовищах використовувати режими встановлення з блокуванням install-скриптів, наприклад npm install –ignore-scripts, та проводити окремий аудит пакетів, що вимагають виконання postinstall чи preinstall.
3. Використання SCA та внутрішніх дзеркал. Застосовувати інструменти Software Composition Analysis для виявлення вразливих і шкідливих компонентів, будувати внутрішні дзеркала npm з політиками allowlist/denylist, а також обмежувати набір дозволених джерел залежностей.
4. Посилення безпеки CI/CD та контейнерів. Мінімізувати використання root у контейнерах, сегментувати права доступу пайплайнів, регулярно оновлювати та ротути секрети в системах оркестрації, а також впроваджувати перевірку артефактів збірки перед деплоєм.
Розповсюдження шкідливих npm-пакетів під виглядом популярних Strapi плагінів вкотре показує, що кожен етап життєвого циклу розробки й доставки ПЗ є потенційною ціллю для атак. Організаціям і незалежним розробникам варто ставитися до вибору open source-залежностей так само суворо, як до захисту продакшн-середовища: перевіряти довіру до джерел, контролювати код, що виконується під час встановлення, і будувати багаторівневу оборону ланцюга постачання ПЗ. Інвестиції в ці практики сьогодні напряму зменшують імовірність того, що наступна supply chain атака пройде непоміченою у вашій інфраструктурі.
