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