Atak łańcuchowy na rozszerzenia VS Code z malware „GlassWorm”. Niewidzialny kod, C2 na blockchainie i samopropagacja

Wprowadzenie do problemu / definicja luki

W połowie października 2025 r. wykryto wysoce zaawansowany atak łańcuchowy na ekosystem rozszerzeń dla VS Code. Kampania, nazwana GlassWorm, infekuje rozszerzenia publikowane w OpenVSX (alternatywny, otwarty rejestr) i w pojedynczych przypadkach w Visual Studio Code Marketplace. Celem jest kradzież tokenów NPM/GitHub/Git (i innych), drenaż środków z 49 wtyczek kryptowalutowych, a także przejęcie stacji roboczych deweloperów jako węzłów infrastruktury przestępczej (SOCKS proxy, ukryty VNC). Atak rozpowszechnia się sam — używa przejętych poświadczeń do kompromitowania kolejnych rozszerzeń/pakietów. Pierwsze zainfekowane wydania w OpenVSX pojawiły się 17 października 2025 r.; do 20–21 października potwierdzono ok. 35,8 tys. instalacji złośliwych wersji.

W skrócie

• Wejście: zainfekowane rozszerzenia VS Code w OpenVSX (i jeden przypadek w oficjalnym marketplace Microsoftu).
• Technika ukrycia: „niewidzialny kod” oparty o Unicode variation selectors – złośliwy JS nie renderuje się w edytorze i znika w diffach.
• C2: łańcuch Solana (memo w transakcjach zawiera wskaźnik do ładunku) + Google Calendar jako zapasowy kanał + bezpośrednie IP.
• Zdolności: exfiltracja sekretów (NPM, GitHub, OpenVSX, Git), drenaż portfeli krypto (49 rozszerzeń), SOCKS proxy, HVNC, P2P (WebRTC), DHT, samopropagacja.
• Skala: min. 35,8 tys. instalacji; co najmniej 7 rozszerzeń w OpenVSX na starcie, kolejne dołączane w toku.

Kontekst / historia / powiązania

GlassWorm pojawia się miesiąc po kampanii Shai Hulud (samopropagujący się robak w ekosystemie npm), również opisanej przez Koi Security. Wcześniej w 2025 r. społeczność zwracała uwagę na ryzyka marketplace’ów VS Code/OpenVSX (m.in. wycieki sekretów i słabe procesy publikacji). Choć podatność procesu publikacji w OpenVSX zgłoszona w maju i załatana w czerwcu nie miała potwierdzonego nadużycia, łańcuch dostaw rozszerzeń pozostaje atrakcyjny dla atakujących. GlassWorm pokazuje kolejny krok — połączenie samopropagacji z infrastrukturą C2 odporną na „takedown”.

Analiza techniczna / szczegóły luki

Niewidzialny kod (Unicode):
Złośliwe fragmenty są wstrzykiwane z użyciem Unicode variation selectors, które nie generują widocznego znaku. W efekcie w edytorze i w przeglądarce diffów widać „puste” linie; interpreter JS przez cały czas wykonuje payload. To znacząco obniża skuteczność przeglądu kodu i części narzędzi SAST.

1. Solana – malware wyszukuje transakcje z określonego portfela i odczytuje memo z zaszytym (base64) linkiem do kolejnego etapu; zmiana ładunku to publikacja nowej transakcji (tani, dynamiczny i odporny na usunięcie kanał).
2. Google Calendar – tytuł wydarzenia zawiera kolejny wskaźnik URL (backup C2).
3. Bezpośrednie IP – serwer serwujący zaszyfrowane ładunki, z kluczem AES przekazywanym w nagłówkach HTTP.

Łańcuch infekcji i moduły:

• Etap kradzieży: pozyskanie tokenów NPM/GitHub/Git/OpenVSX + dane z 49 rozszerzeń portfeli kryptowalut.
• Samopropagacja: użycie skradzionych poświadczeń do publikacji zainfekowanych wersji pakietów/rozszerzeń.
• „ZOMBI”: aktywacja SOCKS proxy, WebRTC P2P, BitTorrent DHT do dystrybucji komend oraz HVNC (ukryty zdalny pulpit) — pełny, niewidoczny dostęp do stacji roboczej.

Skala i czas:

• Start: 17 października 2025 – 7 rozszerzeń OpenVSX.
• 18–21 października: ~35,8 tys. instalacji, kolejne rozszerzenia aktywnie serwowały malware; wykryto też pojedyncze zainfekowane rozszerzenie w Microsoft VS Code Marketplace (usunięte po zgłoszeniu).

Praktyczne konsekwencje / ryzyko

• Kompromitacja łańcucha dostaw: każdy zainfekowany deweloper staje się wektorem do przejęcia następnych rozszerzeń i repozytoriów.
• Utrata sekretów i eskalacja: wyciek tokenów repozytoryjnych i rejestrów pakietów = możliwość publikacji trojanizowanych wersji oprogramowania.
• Pivot do sieci wewnętrznej: HVNC + SOCKS czynią z laptopów deweloperów ukryte backdoory i węzły pośredniczące.
• Trwałość i odporność na wyłączenie: C2 oparte na blockchainie i usługach chmurowych utrudnia neutralizację i blokowanie.

Rekomendacje operacyjne / co zrobić teraz

Traktuj to jako aktywny incydent, nie tylko „podatność”. Poniżej lista działań priorytetowych:

1. Natychmiastowa higiena i izolacja

• Odłącz stacje deweloperskie od sieci firmowej; zablokuj wyjścia do: znanych IoC (np. 217.69.3.218, 140.82.52.31), RPC Solany i wskazanego wydarzenia Google Calendar (blok domenowy/aplikacyjny).
• Tymczasowo wyłącz auto-aktualizacje rozszerzeń w IDE; wstrzymaj instalacje z OpenVSX i niezweryfikowanych marketplace’ów.

2. Łańcuch tożsamości i sekretów

• Rotacja wszystkich sekretów używanych na stacjach deweloperskich: tokeny NPM/GitHub/Git/OpenVSX/VS Code, hasła, klucze SSH; unieważnij sesje.
• Wymuś re-login po rotacji, włącz obowiązkowo MFA i zasady urządzeń zaufanych.

3. Triaga i detekcja

• Przeskanuj hosty pod kątem: procesów HVNC, uruchomionych SOCKS proxy, komponentów WebRTC P2P, wpisów autostartu HKCU/HKLM...\Run, artefaktów z listy IoC Koi.
• Monitoruj nietypowe połączenia wychodzące (Solana RPC, kalendarz Google, nietypowe IP HTTP z nagłówkami niestandardowymi).

4. Remediacja hostów

• Pełny reimage zaufanym obrazem → odtworzenie środowiska developerskiego → dopiero potem przywracanie dostępu do repozytoriów/registrów. (Rekomendowane przez badaczy w związku z HVNC i trwałością modułów).

5. Zarządzanie ryzykiem marketplace’ów

• Wprowadź allow-listę rozszerzeń (zarządzanie katalogiem dopuszczonych dodatków), SBOM dla pluginów oraz cykliczny przegląd autorów/łańcucha wydawniczego.
• Rozważ blokadę OpenVSX w sieci korporacyjnej do czasu pełnego wyjaśnienia; zezwalaj wyłącznie na oficjalny marketplace i/lub wewnętrzne mirrory z walidacją.

6. Długofalowo

• Włącz skanery sekretów i SCA dla rozszerzeń i pakietów developerskich; egzekwuj zasady „no tokens in builds”.
• Edukuj dev-teamy o wektorach „niewidzialnego kodu” (Unicode), kontroluj diffy w trybie view raw bytes lub z narzędziami wykrywającymi znaki kontrolne.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Shai Hulud (npm, IX 2025) – pierwszy robak samopropagujący w ekosystemie npm (kradł tokeny i publikował zainfekowane wersje). GlassWorm adaptuje ten model do OpenVSX/VS Code i dodaje niewidzialny kod + C2 na blockchainie + HVNC (większa odporność i wpływ na hosta).
• WhiteCobra / fale złośliwych rozszerzeń – wcześniejsze kampanie (stealery) bazowały głównie na exfiltracji; GlassWorm tworzy żyjący ekosystem z P2P/DHT/HVNC i realnym „przejęciem” stacji. (Wskazuje to trend eskalacji w marketplace’ach IDE).

Podsumowanie / najważniejsze wnioski

GlassWorm to punkt zwrotny dla bezpieczeństwa rozszerzeń IDE: łączy trik steganograficzny (Unicode), C2 odporny na likwidację (Solana/Google Calendar) i robakową samopropagację. Organizacje korzystające z VS Code i pochodnych narzędzi powinny potraktować sprawę jak incydent średnio-/wysokiego ryzyka, nie czekać na listy „złych rozszerzeń” i wdrożyć rotację sekretów + reimage najbardziej narażonych hostów developerskich.

Źródła / bibliografia

• SecurityWeek: „Supply Chain Attack Targets VS Code Extensions With ‘GlassWorm’ Malware”, 21 października 2025. (SecurityWeek)
• Koi Security (analiza techniczna), 18 października 2025. (koi.ai)
• Koi Security (strona incydentu z IoC i aktualizacjami), 20 października 2025. (koi.ai)
• Dark Reading: „Self-Propagating GlassWorm Attacks VS Code Supply Chain”, 20 października 2025. (Dark Reading)
• CSO Online/InfoWorld: „Self-propagating worm found in marketplaces for VS Code extensions”, 21 października 2025. (CSO Online)