Wprowadzenie do problemu / definicja luki
Pod koniec października 2025 r. społeczność deweloperów VS Code i kompatybilnych edytorów odnotowała kampanię „GlassWorm”, w której do rejestru Open VSX trafiły złośliwe rozszerzenia kradnące poświadczenia i przejmujące stacje programistów. Zespół Open VSX (Eclipse Foundation) poinformował, iż incydent został opanowany, a narracja o „samorozprzestrzeniającym się robaku” jest przesadzona — to raczej ukierunkowana kampania wykorzystująca wycieki tokenów do publikacji trojanizowanych paczek.
W skrócie
- Zasięg: pierwsza fala objęła co najmniej 7 rozszerzeń w Open VSX; łączna liczba kompromitowanych instalacji była szacowana na ~35,8 tys. (różne źródła).
- Wejście na platformę: atakujący wykorzystali wycieknięte tokeny wydawców, by publikować złośliwe wersje.
- Stan obecny: znane złośliwe rozszerzenia usunięto, tokeny unieważniono, a Open VSX wdraża krótsze TTL tokenów i automatyczne skanowanie przy publikacji.
- Spór o „robaka”: badacze mówili o „self-propagating worm”, ale Eclipse twierdzi, iż to nie był klasyczny robak samoreplikujący, tylko malware dystrybuowane poprzez zaufany kanał.
Kontekst / historia / powiązania
Pierwsze publiczne raporty (20–21 października) opisywały „GlassWorm” jako nową formę ataku na łańcuch dostaw rozszerzeń VS Code i Open VSX; wskazywano m.in. na masowe kradzieże poświadczeń oraz mechanizmy C2 utrudniające wyłączenie infrastruktury. 27–31 października Eclipse opublikowało aktualizacje: unieważnienie tokenów, brak oznak aktywnych złośliwych paczek i planowane wzmocnienia procesu publikacji. 31 października SecurityWeek odnotował, iż Open VSX tonuje przekaz o „robaku” i podkreśla ograniczony wpływ incydentu po działaniach zaradczych.
Analiza techniczna / szczegóły luki
Wektor wejścia: Zgodnie z Eclipse Foundation, atakujący uzyskali dostęp do tokenów wydawniczych (część wyciekła poza ekosystemem), co pozwoliło im publikować lub podmieniać rozszerzenia w Open VSX. Nie ma dowodów na kompromitację samej infrastruktury Open VSX.
Łańcuch ataku w rozszerzeniach:
- ukryte fragmenty kodu (m.in. niewidoczne znaki Unicode) oraz wieloetapowe skrypty instalacyjne;
- exfiltracja poświadczeń (NPM, GitHub, Git), tokenów i haseł;
- komponenty do zdalnej kontroli stacji roboczej (np. ukryty VNC / proxy SOCKS), potencjalne celowanie w portfele krypto;
- szybka dystrybucja dzięki automatycznym aktualizacjom rozszerzeń po stronie użytkowników.
Czy to „robak”? Wczesne raporty badaczy podkreślały cechy samo-rozprzestrzeniania przez aktualizacje rozszerzeń i infekowanie środowisk developerskich. Eclipse odpowiada, iż brakowało klasycznego mechanizmu autonomicznej replikacji w sieci — propagacja następowała przez zaufany kanał publikacji i aktualizacji, a nie poprzez bezpośrednią „kopiarkę” malware’u. W praktyce oznacza to spór semantyczny, ale ryzyko operacyjne pozostaje wysokie.
Praktyczne konsekwencje / ryzyko
- Utrata sekretów: przechwycone tokeny i klucze mogą umożliwić dalsze ataki na CI/CD, rejestry pakietów, repozytoria kodu i konta developerskie.
- Pivot na infrastrukturę firmową: zainfekowana stacja developera to wygodny punkt startu do ruchu bocznego — proxy, VNC/RAT i kradzież sesji.
- Reputacja i łańcuch dostaw: publikacja trojanizowanych rozszerzeń z legalnych kont uderza w zaufanie do marketplace’ów i narzędzi Dev.
Rekomendacje operacyjne / co zrobić teraz
Dla zespołów bezpieczeństwa i platform engineering:
- Inwentaryzacja rozszerzeń w środowiskach developerskich i CI — porównanie z listami kompromitacji z końca października; odinstalowanie, reinstalacja ze zweryfikowanych źródeł.
- Rotacja sekretów: natychmiastowa wymiana tokenów NPM/GitHub/Git, kluczy API, PAT; wdrożenie krótkiego TTL i automatycznego odwoływania. (Zgodnie z kierunkiem zmian ogłoszonym przez Eclipse).
- Higiena publikacji: wymuś 2FA dla kont wydawców, segregację ról, minimalny zakres uprawnień dla tokenów wydawniczych oraz monitorowanie prób publikacji.
- Monitoring endpointów Dev: reguły EDR pod kątem nieoczywistych procesów VS Code, tworzenia serwisów VNC, tuneli SOCKS, anomalii w ruchu do usług blockchain/kalendarzy (jeśli były wykorzystywane w C2 w innych wariantach).
- Skanowanie rozszerzeń przed dopuszczeniem do złotych obrazów deweloperskich; preferuj źródła z automatycznym skanem przy publikacji (Eclipse zapowiedziało wzmocnienia).
Dla indywidualnych developerów:
- Aktualizuj VS Code/edytor i usuń podejrzane rozszerzenia; przejrzyj historię instalacji i uprawnienia.
- Wyczyść menedżer haseł/kluczy (npm, git-credentials), zresetuj tokeny i włącz 2FA.
- Obserwuj aktywność kont i repozytoriów pod kątem nietypowych commitów/publikacji.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Wcześniejsze kampanie przeciwko marketplace’om (np. wrześniowe fale złośliwych wtyczek „WhiteCobra”) bazowały na typowych infostealerach i szybkim odtwarzaniu pakietów po usunięciu. „GlassWorm” wyróżnia się intensywniejszym wykorzystaniem ukrytego kodu i atakiem na łańcuch publikacji (wykorzystanie tokenów), ale — według Eclipse — bez cechy klasycznego, sieciowego self-wormingu. Wniosek: problemem nie jest tylko sama wtyczka, ale proces publikacji i zaufanie do kont wydawców.
Podsumowanie / najważniejsze wnioski
- Incydent opanowano: złośliwe rozszerzenia usunięto, wycieknięte tokeny cofnięto, a kontrolę publikacji w Open VSX zaostrzono.
- Spór o definicję „robaka” nie zmienia faktu, iż środowiska Dev są atrakcyjnym celem i wymagają takiej samej dyscypliny bezpieczeństwa jak produkcja.
- Organizacje powinny traktować rozszerzenia jak kod produkcyjny: wersjonować, skanować, dopuszczać kontrolowanie, a publikacyjne tokeny chronić jak klucze do release pipeline’u.
Źródła / bibliografia
- SecurityWeek: „Open VSX Downplays Impact From GlassWorm Campaign” (31 października 2025). (SecurityWeek)
- Eclipse Foundation — „Open VSX security update, October 2025”. (Eclipse Foundation Staff Blogs)
- Truesec: „GlassWorm — Self-Propagating VSCode Extension Worm” (21 października 2025). (Truesec)
- BleepingComputer: „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
- heise online (EN): „Open VSX: Eclipse Foundation draws consequences from GlassWorm attack” (31 października 2025). (heise online)
