Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
GlassWorm to kampania malware typu supply chain, wymierzona w środowiska programistyczne, repozytoria kodu oraz rejestry pakietów i rozszerzeń. W najnowszej odsłonie zagrożenie zostało powiązane z setkami skompromitowanych komponentów opublikowanych lub zmodyfikowanych w ekosystemach GitHub, npm, Visual Studio Code Marketplace oraz OpenVSX.
To szczególnie niebezpieczny scenariusz, ponieważ atak wykorzystuje zaufane kanały dystrybucji używane codziennie przez deweloperów, administratorów i zespoły DevOps. W praktyce oznacza to, że złośliwy kod może zostać pobrany wraz z pozornie legalnym rozszerzeniem, pakietem lub repozytorium.
W skrócie
Badacze bezpieczeństwa powiązali najnowszą falę GlassWorm z co najmniej 433 skompromitowanymi komponentami. Wśród nich znalazło się około 200 repozytoriów Pythona na GitHub, 151 repozytoriów JavaScript i TypeScript, 72 rozszerzenia VS Code i OpenVSX oraz 10 pakietów npm.
- atak obejmuje wiele kanałów dystrybucji jednocześnie,
- operatorzy mieli przejmować konta deweloperów i publikować trojanizowane komponenty,
- złośliwy kod był maskowany przy użyciu niewidocznych znaków Unicode,
- malware wykorzystywał blockchain Solana do pobierania instrukcji i dalszych ładunków,
- celem kampanii była kradzież poświadczeń, tokenów, kluczy SSH i danych środowisk deweloperskich.
Kontekst / historia
GlassWorm był obserwowany już wcześniej jako zagrożenie skierowane przeciwko ekosystemowi open source oraz narzędziom używanym przez programistów. W poprzednich kampaniach złośliwe działania wiązano między innymi z infekowaniem rozszerzeń dla VS Code oraz próbami kradzieży danych z portfeli kryptowalutowych, poświadczeń i tokenów dostępowych.
Z czasem aktywność grupy rozszerzyła się poza pojedyncze rozszerzenia i zaczęła obejmować różne warstwy łańcucha dostaw oprogramowania. Obecna fala ataków pokazuje wyraźną eskalację skali oraz dojrzałości operacyjnej. Zamiast pojedynczych incydentów mamy do czynienia z kampanią wielokanałową, w której podobne techniki, wspólna infrastruktura i zbliżone ładunki wskazują na jednego aktora lub silnie skoordynowaną grupę.
Analiza techniczna
Łańcuch ataku rozpoczyna się od kompromitacji kont deweloperskich lub przejęcia dostępu do projektów. W przypadku GitHub skutkiem są złośliwe commity wprowadzane metodą force-push, co pozwala nadpisywać historię i utrudnia szybkie wykrycie manipulacji. Następnie zainfekowany kod trafia do kolejnych kanałów dystrybucji, w tym do pakietów npm oraz rozszerzeń publikowanych dla VS Code i OpenVSX.
Jedną z najbardziej charakterystycznych technik stosowanych przez GlassWorm jest użycie niewidocznych znaków Unicode do ukrywania złośliwej logiki. Tego typu obfuskacja utrudnia analizę zmian podczas code review, ponieważ elementy odpowiedzialne za infekcję mogą wyglądać jak niegroźne różnice formatowania lub pozostać praktycznie niewidoczne dla recenzenta.
Kampania korzysta również z nietypowego kanału sterowania i aktualizacji. Zamiast polegać wyłącznie na klasycznej infrastrukturze C2 opartej na domenach i serwerach HTTP, malware odpytuje adres w blockchainie Solana, aby odczytać instrukcje zapisane w memo transakcji. Na tej podstawie pobierany jest właściwy payload, w tym środowisko uruchomieniowe Node.js oraz skryptowy infostealer.
Taka architektura zwiększa odporność operatorów na działania obronne, ponieważ utrudnia tradycyjne blokowanie serwerów dowodzenia. Po uruchomieniu GlassWorm koncentruje się na kradzieży danych wysokiej wartości operacyjnej, takich jak poświadczenia, tokeny dostępu, klucze SSH, dane środowisk deweloperskich oraz informacje związane z portfelami kryptowalutowymi.
W analizach wskazano także artefakty mogące pomóc w detekcji incydentu. W kodzie projektów warto szukać markera „lzcdrtfxyqiplpd”, a na systemach końcowych sprawdzać obecność pliku ~/init.json, podejrzanych instalacji Node.js w katalogu użytkownika oraz nietypowych plików JavaScript, takich jak i.js, w świeżo sklonowanych repozytoriach. Sygnałem ostrzegawczym mogą być też anomalie w historii commitów, zwłaszcza rozbieżności między datą autora a datą committera.
Konsekwencje / ryzyko
Ryzyko związane z GlassWorm wykracza daleko poza pojedynczą infekcję stacji roboczej. To zagrożenie dla całego łańcucha dostaw oprogramowania, ponieważ skompromitowany deweloper może nieświadomie stać się punktem wejścia do kolejnych organizacji, klientów i środowisk CI/CD.
W praktyce jeden przejęty token, klucz SSH lub dostęp do konta publikującego pakiety może umożliwić modyfikację kodu źródłowego, publikację złośliwych zależności oraz dalsze rozprzestrzenianie malware między projektami. Dla zespołów inżynierskich oznacza to ryzyko utraty integralności kodu, wycieku sekretów, kompromitacji pipeline’ów budowania oraz potencjalnego wdrożenia backdoora do środowisk produkcyjnych.
Dodatkowym problemem jest wysoka trudność wykrycia. Połączenie przejętych kont, zaufanych kanałów publikacji, obfuskacji Unicode oraz nietypowego modelu C2 powoduje, że standardowe kontrole oparte wyłącznie na reputacji źródła lub prostym skanowaniu sygnaturowym mogą okazać się niewystarczające.
Rekomendacje
Organizacje powinny potraktować ten incydent jako wyraźny sygnał do wzmocnienia ochrony łańcucha dostaw oprogramowania. W pierwszej kolejności warto przeprowadzić przegląd wszystkich niedawno pobranych pakietów, rozszerzeń i sklonowanych repozytoriów, szczególnie tych pochodzących z GitHub, npm, VS Code Marketplace i OpenVSX.
- zweryfikować historię commitów pod kątem force-pushy, nietypowych autorów i anomalii czasowych,
- skanować repozytoria pod kątem wskaźników kompromitacji, markerów i podejrzanych plików JavaScript,
- sprawdzić obecność nieautoryzowanych instalacji Node.js w katalogach użytkowników,
- przeprowadzić rotację tokenów GitHub, npm, kluczy SSH i innych sekretów używanych przez deweloperów,
- wymusić MFA na kontach deweloperskich i kontach publikujących pakiety,
- ograniczyć uprawnienia tokenów oraz stosować poświadczenia o krótkim czasie życia,
- wdrożyć monitoring publikacji pakietów i zmian w rozszerzeniach,
- uruchamiać analizę SCA, skanowanie sekretów i weryfikację integralności zależności w CI/CD.
Dobrą praktyką jest również ograniczenie instalacji rozszerzeń i pakietów do zaufanych, zatwierdzonych źródeł oraz budowanie wewnętrznych list dopuszczonych komponentów. W środowiskach wysokiego ryzyka warto rozważyć izolację maszyn deweloperskich, sandboxing narzędzi oraz dodatkowy monitoring dostępu do portfeli kryptowalutowych i magazynów sekretów.
Podsumowanie
GlassWorm to przykład nowoczesnego ataku na software supply chain, który łączy kompromitację kont, złośliwe aktualizacje, ukrywanie kodu i odporną na zakłócenia komunikację C2. Skala najnowszej kampanii pokazuje, że zagrożenia wymierzone w deweloperów i ekosystem open source stają się coraz bardziej skoordynowane, wielowarstwowe i trudniejsze do zatrzymania.
Dla organizacji oznacza to konieczność traktowania repozytoriów, pakietów i rozszerzeń jako krytycznej powierzchni ataku. Skuteczna obrona wymaga dziś nie tylko zabezpieczenia endpointów, ale również pełnej kontroli nad procesem tworzenia, publikacji i dostarczania oprogramowania.
Źródła
- BleepingComputer — https://www.bleepingcomputer.com/news/security/glassworm-malware-hits-400-plus-code-repos-on-github-npm-vscode-openvsx/
- 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
- Koi Security — First Self-Propagating Worm Using Invisible Code Hits OpenVSX Marketplace — https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace
- SecurityWeek — GlassWorm Malware Returns to Open VSX, Emerges on GitHub — https://www.securityweek.com/glassworm-malware-returns-to-open-vsx-emerges-on-github/