Wprowadzenie do problemu / definicja luki
Najnowsza fala kampanii GlassWorm pokazuje, jak niebezpieczny potrafi być łańcuch dostaw w ekosystemie deweloperskim: atakujący nie muszą łamać zabezpieczeń stacji roboczej „od zera”, jeżeli potrafią wstrzyknąć złośliwy kod do popularnego rozszerzenia IDE i poczekać, aż ofiary zaktualizują je automatycznie.
W omawianym incydencie wykorzystano Open VSX (otwarty rejestr rozszerzeń kompatybilnych z VS Code). Napastnik przejął dostęp do zasobów wydawniczych legalnego autora i wypchnął „podmienione” wersje czterech znanych rozszerzeń – łącznie z ponad 22 tys. pobrań – z loaderem GlassWorm, który finalnie celuje w macOS i kradzież danych: hasła, sekrety deweloperskie oraz artefakty portfeli krypto.
W skrócie
- Złośliwe aktualizacje dotknęły 4 rozszerzenia opublikowane przez autora oorzc (m.in. narzędzia do SSH/SFTP, i18n, mindmap, SCSS→CSS).
- Mechanizm infekcji to staged loader: zaszyfrowany blob jest odszyfrowywany w czasie uruchomienia i wykonywany (m.in. eval).
- Łańcuch sterowania (C2) oparto o „dead drop” w memo transakcji na Solanie, co utrudnia blokowanie statycznymi IOC.
- Payload (Stage 2) jest macOS-only, kradnie m.in. dane przeglądarek, Keychain, Apple Notes, konfiguracje VPN, a także sekrety AWS/SSH; tworzy persystencję przez LaunchAgent.
- Operatorzy Open VSX wycofali złośliwe wydania, zdeaktywowali tokeny wydawcy; jedno z rozszerzeń usunięto szerzej ze względu na wiele podejrzanych wersji.
Kontekst / historia / powiązania
GlassWorm jest kojarzony z falami nadużyć w marketplace’ach rozszerzeń (w tym Open VSX) co najmniej od jesieni 2025. Wcześniejsze epizody obejmowały m.in. nadużycia wynikające z wycieków tokenów publikacyjnych po stronie deweloperów (błędy operacyjne autorów), a nie z kompromitacji samej infrastruktury rejestru.
W najnowszym incydencie istotne jest to, iż atakujący nie stawiali wyłącznie na podszywanie się/typosquatting, tylko weszli „frontowymi drzwiami” – przez przejęte uprawnienia wydawnicze istniejącego konta z historią i adopcją, co zwiększa wiarygodność w oczach użytkownika.
Analiza techniczna / szczegóły luki
1) Wektor: przejęte konto wydawcy i złośliwe aktualizacje
Według ustaleń badaczy, 30 stycznia 2026 opublikowano „zatrute” wersje czterech rozszerzeń autora oorzc w Open VSX:
- oorzc.ssh-tools (v0.5.1)
- oorzc.i18n-tools-plus (v1.6.8)
- oorzc.mind-map (v1.0.61)
- oorzc.scss-to-css-compile (v1.3.4)
Z perspektywy obrony najważniejsze jest, iż to nie „nowy, podejrzany” publisher, tylko konto z realnymi pobraniami (sygnały adopcji).
2) Stage 0: loader w extension.js + odszyfrowanie i wykonanie
We wszystkich czterech paczkach .vsix osadzono niemal identyczny loader w pliku extension.js. Ten loader używa AES-256-CBC do odszyfrowania długiego heksowego bloba i natychmiast uruchamia wynik przez eval(). To klasyczny wzorzec „runtime-decryption”, który utrudnia proste skanowanie statyczne.
3) Stage 1: geofencing + dead drop na Solanie
Po odszyfrowaniu kolejny etap:
- wyklucza systemy z rosyjskimi ustawieniami językowymi / strefami czasowymi (operacyjne OPSEC),
- pobiera instrukcję „co dalej” z memo transakcji na Solanie (dead drop), dzięki czemu atakujący mogą rotować infrastrukturę bez ponownego publikowania rozszerzeń.
4) Stage 2: macOS infostealer + persystencja
Stage 2 jest jawnie ukierunkowany na darwin (macOS). Zgodnie z analizą:
- tworzy katalog roboczy w /tmp, pakuje dane do archiwum ZIP i eksfiltruje je na zdalne endpointy (w analizowanej próbce: IP 45.32.150[.]251, ścieżki m.in. /p2p, /2p2).
- kradnie artefakty przeglądarek (cookies, bazy logowań, dane formularzy), portfele krypto (desktop i rozszerzenia), macOS Keychain, Apple Notes, cookies Safari, a choćby konfiguracje FortiClient VPN.
- poluje na sekrety deweloperskie (np. ~/.aws, ~/.ssh) oraz tokeny związane z workflow (np. artefakty uwierzytelnienia używane w ekosystemie npm/GitHub).
- ustanawia persystencję przez LaunchAgent w ~/Library/LaunchAgents (np. plist w stylu com.user.nodestart.plist).
Praktyczne konsekwencje / ryzyko
To nie jest „tylko” kradzież danych lokalnych. W realnym środowisku deweloperskim kompromitacja stacji roboczej przez rozszerzenie może eskalować do:
- przejęcia chmury (skradzione klucze / konfiguracje),
- przejęcia repozytoriów i pipeline’ów CI/CD (tokeny, sekrety, automaty publikacji),
- poisoningu zależności (publikowanie złośliwych paczek / releasów przez skradzione uprawnienia),
- dalszych włamań lateralnych dzięki SSH i artefaktom konfiguracyjnym.
Dodatkowo, użycie Solany jako kanału konfiguracji ogranicza skuteczność prostych blokad domen/IP – obrona przesuwa się w stronę telemetrii behawioralnej i szybkiej reakcji.
Rekomendacje operacyjne / co zrobić teraz
Jeśli w Twojej organizacji używa się Open VSX lub edytorów pobierających stamtąd rozszerzenia, potraktuj ten przypadek jak incydent ekspozycji poświadczeń.
A) Szybka weryfikacja (triage)
- Sprawdź, czy instalowano któreś z rozszerzeń i wersji wskazanych w IOC (patrz wyżej).
- Na macOS zweryfikuj persystencję:
- ~/Library/LaunchAgents pod kątem nieznanych plist (np. podobnych do com.user.nodestart.plist).
- Szukaj artefaktów stagingu/eksfiltracji (np. nietypowe archiwa w /tmp i ślady wywołań curl do zewnętrznych IP).
B) Ograniczenie skutków
- Usuń rozszerzenie i jego artefakty z dysku (nie tylko „disable” w IDE).
- Rotuj sekrety w kolejności „największy blast radius”:
- tokeny GitHub / dostępy do repo + audit zdarzeń,
- tokeny npm / registry,
- klucze chmurowe (np. AWS),
- klucze SSH (zwłaszcza z dostępem do prod/CI).
C) Utwardzenie na przyszłość (supply chain dla rozszerzeń)
- Wprowadź allowlistę rozszerzeń (publisher + identyfikator + dozwolone wersje) i ogranicz auto-update tam, gdzie to możliwe.
- Monitoruj behawior: wykonywanie curl/pobieranie payloadów w kontekście procesu IDE, tworzenie LaunchAgents, masowy odczyt plików z profili przeglądarek, Keychain/Notes itp. (to lepiej łapie staged loader niż IOC z domen).
- Edukuj autorów i zespoły: tokeny publikacyjne nie mogą lądować w publicznych repo; Open VSX wskazywał już wcześniej, iż wycieki tokenów były przyczyną nadużyć.
Różnice / porównania z innymi przypadkami
Co się zmieniło względem wcześniejszych fal GlassWorm?
- Od „ukrytych znaków” do loaderów szyfrowanych w runtime
Wątek „niewidzialnych” znaków Unicode był charakterystyczny dla wcześniejszych odsłon, ale w tej fali widać większy nacisk na staging, szyfrowanie i dynamiczne pobieranie kolejnych etapów. - Od masowego „podszywania się” do przejęć kont z historią
Zatrute aktualizacje zostały opublikowane w ramach istniejącego konta, co z perspektywy użytkownika wygląda bardziej wiarygodnie niż świeży publisher z jedną podejrzaną paczką. - Zmienność infrastruktury przez łańcuch bloków
Dead drop w memo transakcji (Solana) zmniejsza wartość klasycznych IOC i premiuje szybkie wykrycie anomalii na endpointach.
Podsumowanie / najważniejsze wnioski
- To kolejny dowód, iż IDE i ich rozszerzenia stały się atrakcyjnym wektorem do kradzieży sekretów deweloperskich i krypto.
- Incydent łączy trzy trudne dla obrony elementy: kompromitację konta wydawcy, runtime-decryption oraz dynamiczny C2 przez Solanę.
- Jeżeli Twoi developerzy instalowali wskazane wersje rozszerzeń, potraktuj to jak pełną ekspozycję poświadczeń: usuwanie artefaktów + rotacja sekretów + przegląd aktywności w repo/chmurze/CI.
- Długoterminowo warto wdrożyć polityki supply chain także dla rozszerzeń (allowlista, kontrola wersji, monitoring zachowań na endpointach).
Źródła / bibliografia
- BleepingComputer – artykuł autorstwa Bill Toulas o nowej fali GlassWorm na macOS przez Open VSX. (BleepingComputer)
- Socket – analiza techniczna łańcucha infekcji, IOC, persystencji i eksfiltracji. (Socket)
- SecurityWeek – omówienie kampanii, zakresu kradzieży i mechanizmu C2 przez mema transakcji. (SecurityWeek)
- The Hacker News – zestawienie incydentu i lista zainfekowanych rozszerzeń/wariantów. (The Hacker News)
- Blog Mikaël Barbero – tło dot. tokenów i reakcji operatora Open VSX w 2025. (mikael.barbero.tech)
