30 січня 2026 року в репозиторії Open VSX зафіксовано показовий інцидент ланцюга постачання програмного забезпечення: чотири розширення, опубліковані розробником під ніком oorzc, отримали шкідливі оновлення з інтегрованим завантажувачем GlassWorm. Ці плагіни протягом понад двох років виглядали повністю легітимними та активно використовувалися спільнотою, що лише підвищило рівень довіри до чергових оновлень.
Інцидент GlassWorm в Open VSX: що саме сталося
За даними дослідників компанії Socket, зловмисникам вдалося скомпрометувати обліковий запис автора розширень і випустити нові версії з вбудованим шкідливим функціоналом. Команда безпеки Open VSX припускає, що доступ до акаунта могли отримати через скомпрометований токен доступу або іншу форму викрадення чи підміни облікових даних.
Компрометовані релізи всіх чотирьох розширень були оперативно вилучені з Open VSX після виявлення підозрілої активності. Однак сам факт успішної публікації злоякісних оновлень від імені довіреного розробника демонструє вразливість екосистем розширень IDE та критичність безпеки ланцюга постачання ПЗ.
Як працює GlassWorm у розширеннях VS Code
Завантажувач GlassWorm і розшифрування пейлоада під час виконання
Шкідливі версії розширень включали лоадер GlassWorm, основне завдання якого — непомітно для користувача розшифрувати та запустити прихований пейлоад. Код атаки зберігається в зашифрованому вигляді й розкривається тільки в рантаймі, що істотно ускладнює статичний аналіз і детекцію засобами класичного антивірусного сканування.
EtherHiding: прихована комунікація з C2-інфраструктурою
Для отримання команд та оновлень GlassWorm застосовує техніку EtherHiding — метод маскування інфраструктури управління (C2) через децентралізовані або важковідстежувані зовнішні джерела. Це дозволяє динамічно змінювати адреси керувальних серверів, підвищує живучість кампанії та ускладнює блокування інфраструктури атаки традиційними мережевими засобами захисту.
Полювання за токенами розробників і криптогаманцями
Після активації GlassWorm переходить до цілеспрямованого збору чутливих даних у середовищі розробника, насамперед на macOS. Пейлоад орієнтований на виявлення та викрадення:
1. Аутентифікаційних даних екосистем розробки. Малвар аналізує конфігурацію npm на предмет наявності параметра _authToken, шукає локальні артефакти аутентифікації GitHub та інші токени доступу. Отримавши такі секрети, зловмисники можуть проникати в приватні репозиторії, CI/CD-пайплайни, менеджери секретів і впливати на процеси релізу, включно з подальшими атаками на ланцюг постачання.
2. Даних криптогаманців. GlassWorm сканує файлову систему в пошуках артефактів, пов’язаних з криптовалютними гаманцями, з метою отримати інформацію, яка дає доступ до коштів або дозволяє ініціювати несанкціоновані транзакції.
Окремо дослідники відзначають механізм профілювання інфікованої машини. Перед активацією шкідливого функціоналу GlassWorm перевіряє параметри середовища, зокрема локаль операційної системи. Якщо виявлено російську мову, шкідлива логіка не запускається. Така гео- та мовно-орієнтована фільтрація відома й за іншими кампаніями малварі й часто використовується для зниження ризику уваги правоохоронців у певних юрисдикціях.
Важлива відмінність цієї хвилі GlassWorm — канал поширення. Якщо раніше оператори покладалися на тайпосквотинг та бренджекинг (створення фальшивих пакетів із назвами, схожими на популярні), то зараз вони використали вже відомий і репутаційно «чистий» акаунт розробника. Для користувача це виглядає як звичайне чергове оновлення улюбленого плагіна, що суттєво знижує ймовірність підозри.
Наслідки для ланцюга постачання ПЗ та екосистеми розробників
Інцидент з GlassWorm в Open VSX переконливо показує, що компрометація одного облікового запису розробника може мати наслідки далеко за межами окремого проєкту. Розширення середовища розробки фактично виконуються в максимально довіреному контексті, де зосереджені ключі, токени, секрети CI/CD та доступ до приватного коду.
Галузеві звіти за 2023–2024 роки від провідних вендорів безпеки фіксують стійке зростання атак на software supply chain: ціллю стають реєстри пакетів (npm, PyPI), маркетплейси розширень IDE, build-системи та CI/CD-сервіси. Скандальні випадки на кшталт атак на бібліотеки з відкритим кодом, компрометації CI-середовищ і кампаній залежнісного конф’южну демонструють спільну тенденцію: атакувальники прагнуть опинитися якомога ближче до вихідного коду та процесів збірки.
Рекомендації з кібербезпеки для розробників і організацій
Розробникам і мейнтейнерам розширень варто вжити таких кроків:
— обов’язково вмикати двохфакторну аутентифікацію (2FA) для всіх акаунтів, через які публікуються пакети та розширення;
— регулярно відкликати та перевипускати токени доступу, обмежуючи їх строк дії та права за принципом найменших привілеїв;
— зберігати секрети в спеціалізованих secret managers, а не в конфігураційних файлах або змінних середовища, доступних стороннім інструментам;
— постійно моніторити історію релізів своїх проєктів і вміст артефактів, оперативно реагуючи на будь-які аномалії.
Командам розробки та DevSecOps доцільно:
— формувати та підтримувати в актуальному стані whitelist довірених розширень VS Code / Open VSX;
— впроваджувати аналіз SBOM (Software Bill of Materials) та відстежувати уразливості й компрометації залежностей;
— використовувати EDR-рішення та засоби моніторингу, здатні виявляти підозрілу поведінку IDE й плагінів (нетипові мережеві з’єднання, доступ до файлів криптогаманців тощо).
Маркетплейсам і репозиторіям розширень варто посилювати як автоматичне, так і ручне рев’ю: застосовувати статичний і динамічний аналіз, поведінкові моделі для виявлення аномальних оновлень, а також впроваджувати жорсткіші механізми верифікації та захисту акаунтів розробників.
Випадок з GlassWorm в Open VSX нагадує, що навіть популярні та багаторічні розширення VS Code можуть за одну-дві версії перетворитися на елемент атакувальної інфраструктури. Організаціям доцільно провести ревізію встановлених плагінів, видалити непотрібні, переконатися в оновленні з довірених джерел і переглянути політику роботи з токенами та секретами. Чим раніше розширення IDE та пакети будуть сприйматися як критичні компоненти ланцюга постачання ПЗ, тим нижчою буде ймовірність успішної компрометації інфраструктури в подібних кампаніях.
