Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem rozszerzeń do środowisk programistycznych odgrywa dziś istotną rolę w codziennej pracy deweloperów, ale jednocześnie stał się atrakcyjnym celem ataków na łańcuch dostaw oprogramowania. Najnowsze ustalenia badaczy wskazują, że w repozytorium Open VSX wykryto 73 fałszywe rozszerzenia Visual Studio Code, które podszywały się pod legalne pakiety i były powiązane z kampanią GlassWorm v2.
To zagrożenie pokazuje, że zaufanie do marketplace’ów i dodatków IDE może zostać łatwo wykorzystane przez cyberprzestępców. W praktyce pojedyncza instalacja złośliwego lub uśpionego rozszerzenia może otworzyć drogę do kradzieży danych, przejęcia poświadczeń oraz dalszej kompromitacji środowiska deweloperskiego.
W skrócie
Kampania objęła 73 rozszerzenia opublikowane jako klony legalnych odpowiedników. Co najmniej sześć z nich zostało zidentyfikowanych jako aktywne nośniki złośliwego oprogramowania, natomiast pozostałe działały jako pakiety typu sleeper, przygotowane do późniejszego uzbrojenia.
- Fałszywe rozszerzenia imitowały nazwy, opisy i ikony legalnych pakietów.
- Część z nich początkowo wyglądała na nieszkodliwe.
- Łańcuch ataku mógł prowadzić do instalacji dodatkowego malware i narzędzi zdalnego dostępu.
- Zagrożenie obejmowało nie tylko VS Code, ale również inne kompatybilne środowiska IDE na tej samej stacji roboczej.
Kontekst / historia
GlassWorm jest już rozpoznawalnym elementem krajobrazu zagrożeń wymierzonych w rozszerzenia deweloperskie i repozytoria pakietów. Wcześniejsze odsłony kampanii wiązano z nadużyciami w Open VSX, podejrzewanymi przejęciami kont deweloperów oraz wykorzystywaniem zależności pośrednich do ukrywania właściwego ładunku.
W najnowszej odsłonie operatorzy kampanii rozwinęli stosowane taktyki. Zamiast natychmiast publikować jednoznacznie złośliwe komponenty, tworzyli rozszerzenia wyglądające wiarygodnie i budujące pozory reputacji. Dopiero później mogły być aktualizowane lub wykorzystywane jako punkt wejścia do pobrania kolejnych etapów infekcji.
Szczególnie niebezpieczny jest aspekt socjotechniczny. Fałszywe wpisy potrafiły niemal idealnie odwzorowywać warstwę wizualną prawdziwych rozszerzeń, co znacząco zwiększało szansę, że użytkownik nie zauważy różnic w nazwie wydawcy albo identyfikatorze pakietu.
Analiza techniczna
Z technicznego punktu widzenia kampania wykorzystywała model cienkiego loadera. Oznacza to, że samo rozszerzenie instalowane przez użytkownika nie musiało zawierać pełnej logiki ataku. Zamiast tego pełniło rolę elementu pośredniego, który pobierał lub aktywował dodatkowy etap infekcji.
Badacze wskazali, że w części przypadków złośliwy komponent był dostarczany jako dodatkowy pakiet VSIX hostowany poza listingiem samego rozszerzenia. Następnie mógł być lokalnie instalowany także w innych wykrytych środowiskach programistycznych znajdujących się na tej samej maszynie. Taki mechanizm zwiększał skalę kompromitacji i utrudniał detekcję.
Istotnym elementem kampanii było również przenoszenie logiki ataku poza łatwo analizowalny kod JavaScript. Operatorzy wykorzystywali zewnętrzne komponenty, zależności przechodnie oraz natywne moduły binarne, które uruchamiały właściwe działania po stronie ofiary. Takie podejście ogranicza skuteczność prostych mechanizmów bezpieczeństwa opartych wyłącznie na analizie statycznej paczki.
Charakterystyczne było także nadużywanie procesu aktualizacji. Rozszerzenie mogło zostać opublikowane jako pozornie niegroźne, zdobyć instalacje i zaufanie użytkowników, a dopiero w kolejnej wersji zostać zmienione w nośnik malware. To szczególnie groźne w organizacjach korzystających z automatycznych aktualizacji dodatków bez ścisłej kontroli wydawców.
Według opisu badaczy końcowy łańcuch ataku mógł prowadzić do wdrożenia malware zdolnego do kradzieży danych, instalacji trojana zdalnego dostępu oraz osadzenia złośliwego rozszerzenia opartego na Chromium. Taki komponent mógł następnie pozyskiwać poświadczenia, zakładki i inne informacje zapisane w przeglądarce użytkownika.
Konsekwencje / ryzyko
Najbardziej narażeni są deweloperzy, zespoły DevOps oraz administratorzy środowisk CI/CD, szczególnie tam, gdzie dopuszcza się instalację rozszerzeń z zewnętrznych źródeł bez centralnej kontroli. Kompromitacja dodatku IDE może oznaczać utratę tokenów dostępowych, kluczy API, danych logowania do repozytoriów i sekretów środowiskowych.
Ryzyko wykracza jednak poza pojedynczą stację roboczą. Środowisko deweloperskie zwykle ma dostęp do kodu źródłowego, systemów build, rejestrów pakietów, chmury oraz narzędzi wdrożeniowych. W efekcie incydent może rozszerzyć się na cały łańcuch dostaw organizacji i doprowadzić do wstrzyknięcia złośliwego kodu do procesów produkcyjnych.
Dodatkowym problemem są pakiety sleeper, które przez długi czas mogą wyglądać całkowicie legalnie. To oznacza, że tradycyjna kontrola w momencie dopuszczenia rozszerzenia może nie wykazać zagrożenia, a faktyczna aktywacja nastąpi dopiero po aktualizacji lub pobraniu kolejnego ładunku.
Rekomendacje
Organizacje powinny traktować rozszerzenia IDE jako pełnoprawny element ryzyka supply chain. Ich instalacja nie powinna być pozostawiona wyłącznie decyzji użytkowników, lecz objęta centralnym nadzorem, polityką dopuszczeń oraz regularnym audytem.
- Utrzymuj listę dozwolonych rozszerzeń i ograniczaj ją do zweryfikowanych wydawców.
- Kontroluj nazwę wydawcy, identyfikator pakietu oraz historię wersji każdego dodatku.
- Monitoruj nietypowe zależności, relacje extension pack i extensionDependencies.
- Wykrywaj próby pobierania zewnętrznych pakietów po instalacji rozszerzenia.
- Analizuj uruchamianie natywnych modułów binarnych i komend systemowych przez IDE.
Z perspektywy operacyjnej warto wdrożyć monitorowanie stacji deweloperskich pod kątem nietypowej komunikacji sieciowej inicjowanej przez procesy IDE, dostępu do magazynów sekretów oraz modyfikacji przeglądarek i ich rozszerzeń. Dobrą praktyką jest także separacja środowisk deweloperskich od najbardziej wrażliwych poświadczeń.
W razie podejrzenia kompromitacji należy natychmiast odinstalować podejrzane rozszerzenia, przeanalizować artefakty VSIX i logi IDE, sprawdzić integralność repozytoriów oraz pipeline’ów CI/CD, a także zresetować hasła i tokeny używane na zainfekowanej stacji. Konieczne może być również skontrolowanie przeglądarek pod kątem nieautoryzowanych dodatków oraz objęcie ruchem wychodzącym wzmożonym monitoringiem.
Podsumowanie
Kampania GlassWorm v2 potwierdza, że rozszerzenia do środowisk programistycznych pozostają skutecznym i trudnym do wykrycia wektorem ataku. Wykrycie 73 fałszywych rozszerzeń w Open VSX pokazuje, że cyberprzestępcy coraz sprawniej łączą socjotechnikę, pakiety uśpione, zależności pośrednie i zewnętrzne ładunki.
Dla organizacji oznacza to konieczność objęcia dodatków IDE takimi samymi procedurami bezpieczeństwa jak biblioteki, kontenery czy artefakty build. Brak kontroli nad tym obszarem może doprowadzić do przejęcia środowisk deweloperskich i dalszej kompromitacji całego łańcucha dostaw oprogramowania.
Źródła
- The Hacker News — https://thehackernews.com/2026/04/researchers-uncover-73-fake-vs-code.html
- Socket — 73 Open VSX Sleeper Extensions Linked to GlassWorm Show New Malware Activations — https://socket.dev/blog/73-open-vsx-sleeper-extensions-glassworm
- Socket — 72 Malicious Open VSX Extensions Linked to GlassWorm Campaign Now Using Transitive Dependencies — https://socket.dev/blog/open-vsx-transitive-glassworm-campaign
- Socket — GlassWorm Loader Hits Open VSX via Suspected Developer Account Compromise — https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise