Дослідники Koi Security задокументували масштабну атаку на ланцюг постачання в екосистемі розширень Visual Studio Code. Шкідливий код, який отримав назву GlassWorm, був виявлений у репозиторіях OpenVSX та офіційному Visual Studio Code Marketplace. За оцінкою фахівців, скомпрометовані пакети завантажили щонайменше 35 800 разів, що робить інцидент суттєвим для розробників і команд безпеки в усьому світі.
Що сталося: supply chain-атака та «тихі» автооновлення
GlassWorm — це саморозповсюджуваний шкідник, який маскує вставки коду за допомогою невидимих Unicode-символів (зокрема символів нульової ширини) і поширюється, використовуючи викрадені облікові дані розробників. Отримавши доступ до облікового запису видавця, зловмисники випускають заражені версії легітимних розширень. Особливо небезпечним фактором є автоматичне оновлення у VS Code: користувачі отримують шкідливі релізи у фоновому режимі без попереджень, що призводить до «тихого» компрометаційного ланцюга.
Кого зачепило: перелік уражених розширень
За даними Koi Security, виявлено щонайменше 11 скомпрометованих пакетів в OpenVSX і один у Visual Studio Code Marketplace:
- [email protected], 1.8.4
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected], 1.0.91
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected] (VS Code Marketplace)
На момент публікації звіту щонайменше чотири шкідливі пакети все ще були доступні в OpenVSX. Microsoft оперативно видалила скомпрометоване розширення зі свого маркетплейса. Автори vscode-theme-seti-folder і git-worktree-menu випустили оновлення, що усувають шкідливі вставки.
Як працює GlassWorm: викрадення доступів і багатоканальне C2
Крадіжка токенів і закріплення у системі
Після інсталяції GlassWorm полює на токени та паролі для GitHub, npm і OpenVSX, а також намагається ексфільтрувати дані криптогаманців із 49 різних розширень. Для прихованої присутності використовується SOCKS-проксі і HVNC (hidden VNC), що забезпечує віддалений доступ без помітної активності на екрані жертви.
Командно-контрольна інфраструктура (C2)
Основний канал управління — блокчейн Solana: у транзакціях на зазначеній в коді адресі зберігаються base64-посилання на наступні стадії атаки. Резервний канал — Google Calendar, де в назвах подій сховано base64-URL. Додатково застосовується пряме підключення до IP 217.69.3[.]218 і механізми BitTorrent DHT для стійкості та децентралізованої доставки команд.
Фінальний пейлоад
Останній етап, позначений як ZOMBI, — сильно обфускований JavaScript, що перетворює інфіковані хости на вузли ботнету з можливістю подальшого розгортання шкідливих дій.
Ризики для команд розробки та AppSec
Ключова загроза — перерозподіл довіри у ланцюгу постачання. Викрадені токени публікації дозволяють випускати оновлення від імені легітимних авторів, а невидимі символи ускладнюють код-рев’ю. Автоматичні оновлення мінімізують шанс раннього виявлення. Подібні риси притаманні відомим інцидентам у ланцюгах постачання, що підкреслює потребу в багаторівневих контролях і принципі найменших привілеїв для токенів і CI/CD.
Рекомендації: як зменшити ризики та наслідки
- Негайно видаліть/перевстановіть перелічені версії розширень і перевірте оновлення від перевірених видавців.
- Ревокуйте та ротируйте токени GitHub/npm/OpenVSX, увімкніть 2FA, обмежте скоупи й термін дії доступів.
- Перевірте робочі станції на наявність підозрілих проксі, HVNC-процесів і з’єднань до IP 217.69.3[.]218; увімкніть моніторинг вихідного трафіку.
- Тимчасово вимкніть автооновлення розширень у критичних середовищах; впровадьте allowlist схвалених плагінів.
- Усиліть код-рев’ю: скануйте на zero-width символи та інші ознаки обфускації у вихідному коді розширень і скриптів встановлення.
- Сегментуйте середовища розробки і використовуйте ізоляцію (sandbox, devcontainers) для зменшення впливу компрометації.
Інцидент із GlassWorm демонструє, наскільки вразливими можуть бути ланцюги постачання навіть у звичних інструментах розробника. Регулярний аудит розширень, суворі політики токенів, мережевий моніторинг і дисципліна оновлень здатні переламати сценарій «тихого зараження». Командам варто переглянути підходи до довіри в екосистемі плагінів і впровадити контрольований процес прийому оновлень, щоби знизити площу атаки та підвищити стійкість до подібних кампаній.
