Популярний пакет jscrambler, який використовується для обфускації та захисту JavaScript-коду, зазнав серйозної атаки на ланцюжок постачання (supply chain attack). Зловмисникам вдалося скомпрометувати репозиторій та опублікувати шкідливу версію 8.14.0 в офіційному реєстрі npm. Проста інсталяція цієї версії або запуск процесу збирання проєкту призводить до автоматичного виконання шкідливого інструменту для викрадення конфіденційних даних (infostealer) безпосередньо на робочій станції розробника або на CI/CD-сервері.

Шкідлива версія jscrambler 8.14.0 в npm заражає розробників інфостілером

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

Технічні деталі компрометації та вектор атаки

Головна небезпека скомпрометованої версії jscrambler полягає в механізмі її встановлення. Зловмисники впровадили шкідливий скрипт через спеціальний хук preinstall, який автоматично запускається менеджером пакетів npm перед безпосереднім розгортанням коду бібліотеки в директорію node_modules. Це означає, що розробнику чи адміністратору збірки навіть не потрібно імпортувати чи викликати функції jscrambler у своєму власному коді — для зараження системи достатньо виконати банальну команду npm install.

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

  • Windows (виконуваний файл .exe);
  • macOS (спеціальна збірка під архітектури Intel та Apple Silicon);
  • Linux (ELF-бінарник для серверних середовищ та робочих станцій).

Після активації бінарний файл діє як класичний інфостілер (інструмент для крадіжки інформації). Його основна мета — сканування локальних сховищ операційної системи та популярного програмного забезпечення для збору конфіденційних даних розробника. Шкідливий агент шукає збережені паролі, сесійні файли cookie браузерів, токени автентифікації до хмарних сервісів, приватні ключі SSH, файли конфігурації .env із секретами проєктів, а також облікові дані для доступу до Git-сервісів (таких як GitHub чи GitLab). Отримані дані пакуються та непомітно відправляються на підконтрольний зловмисникам сервер управління (C2).

Ризики для процесів розробки та CI/CD

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

У разі компрометації локального комп'ютера розробника атака може призвести до повного витоку облікових даних компанії, що відкриває шлях до внутрішньої інфраструктури організації. Якщо ж скомпрометована версія потрапляє на сервер безперервної інтеграції (CI/CD-пайплайн), під загрозою опиняються API-ключі та паролі доступу до продуктових середовищ (Production), які зазвичай зберігаються як змінні оточення у процесі автоматичного розгортання.

Що це означає на практиці

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

  • Терміновий аудит залежностей: Перевірте всі локальні та серверні конфігураційні файли package.json і файли фіксації версій package-lock.json чи yarn.lock на наявність пакета jscrambler версії 8.14.0. У разі виявлення негайно видаліть цю версію та відкотіться до безпечної стабільної збірки (наприклад, 8.13.x або попередніх перевірених релізів).
  • Аналіз логів CI/CD та аудит секретів: Перевірте журнали виконання ваших збірників у CI/CD (GitHub Actions, GitLab CI, Jenkins тощо), які запускалися в період потенційної компрометації. Якщо під час збірок відбувалося завантаження пакета jscrambler 8.14.0, вважайте всі секрети та API-ключі, до яких мав доступ цей пайплайн, скомпрометованими. Їх необхідно негайно відкликати та згенерувати заново.
  • Блокування підозрілих мережевих з'єднань: Налаштуйте правила корпоративного фаєрвола або EDR-систем для моніторингу та блокування несанкціонованих вихідних з'єднань, що ініціюються процесами Node.js або невідомими бінарними файлами з папки node_modules. Робочі станції розробників та сервери збірки не повинні мати безконтрольного доступу до зовнішнього інтернету.
  • Обмеження виконання скриптів npm: Для запобігання запуску прихованого шкідливого коду під час звичайного встановлення бібліотек, використовуйте прапорець --ignore-scripts під час виконання команд інсталяції (npm install --ignore-scripts або yarn install --ignore-scripts). Це заблокує виконання будь-яких хуків preinstall та postinstall без вашого явного дозволу.
  • Впровадження локальних проксі-репозиторіїв: Використовуйте локальні менеджери репозиторіїв типу Sonatype Nexus або JFrog Artifactory для кешування та попередньої перевірки сторонніх пакетів перед тим, як вони стануть доступними для завантаження розробниками вашої компанії. Налаштуйте автоматичне сканування вразливостей (наприклад, за допомогою Snyk або Trivy) для кожної нової залежності.