Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Kampania GlassWorm to zaawansowany przykład ataku na łańcuch dostaw oprogramowania, ukierunkowanego bezpośrednio na programistów i ich środowiska pracy. W najnowszej odsłonie zagrożenia napastnicy wykorzystali złośliwe rozszerzenie dla ekosystemu zgodnego z Visual Studio Code, które podszywa się pod znane narzędzie telemetryczne. Kluczowym elementem ataku jest natywny dropper skompilowany w języku Zig, działający poza typową piaskownicą kodu rozszerzeń i mający szeroki dostęp do systemu operacyjnego.
To podejście znacząco zwiększa skuteczność operacji, ponieważ atak nie kończy się na pojedynczym edytorze. Zainfekowany komponent może rozpoznać inne środowiska programistyczne obecne na tej samej stacji roboczej i rozszerzyć infekcję na kolejne aplikacje wykorzystywane przez dewelopera.
W skrócie
Badacze wykryli nowy wariant kampanii GlassWorm, w którym złośliwe rozszerzenie instaluje natywny komponent na systemach Windows i macOS. Następnie malware skanuje system w poszukiwaniu edytorów i IDE obsługujących rozszerzenia kompatybilne z VS Code, pobiera kolejny etap infekcji i instaluje go w sposób cichy.
- Złośliwe rozszerzenie podszywa się pod legalne narzędzie dla programistów.
- Dropper napisany w Zig działa jako natywny komponent z szerokimi uprawnieniami.
- Malware propaguje się do wielu środowisk IDE obecnych na jednej stacji.
- Drugi etap infekcji odpowiada za kradzież danych, komunikację z serwerami sterowania i instalację kolejnych komponentów.
- Atak może prowadzić do naruszenia kont deweloperskich, kodu źródłowego i infrastruktury CI/CD.
Kontekst / historia
GlassWorm nie jest nowym zagrożeniem, lecz rozwijającą się kampanią wymierzoną w środowiska deweloperskie i zaufane mechanizmy dystrybucji rozszerzeń. Wcześniejsze warianty również koncentrowały się na kompromitacji narzędzi używanych przez programistów, jednak obecna wersja wyróżnia się bardziej dyskretnym i wieloetapowym łańcuchem infekcji.
W opisywanym przypadku zidentyfikowano rozszerzenie opublikowane w Open VSX pod nazwą przypominającą popularne rozwiązanie telemetryczne dla deweloperów. Podobieństwo nazwy i funkcji miało zwiększyć wiarygodność pakietu oraz skłonić ofiary do jego instalacji. Nawet jeśli złośliwy pakiet został już usunięty z repozytorium, ryzyko pozostaje realne dla użytkowników, którzy wcześniej zainstalowali komponent i uruchomili pełny łańcuch infekcji.
Analiza techniczna
Atak rozpoczyna się od instalacji rozszerzenia, które wizualnie i funkcjonalnie przypomina legalny odpowiednik. Różnica kryje się w mechanizmie aktywacji, który uruchamia dodatkowy natywny moduł binarny. Na Windows malware zapisuje plik o nazwie sugerującej komponent Node.js, natomiast na macOS wdrażany jest plik binarny w formacie Mach-O.
Z perspektywy operacyjnej jest to bardzo istotne. Zamiast ograniczać się do kodu JavaScript lub TypeScript wykonywanego w ramach rozszerzenia, napastnicy wykorzystali natywny moduł ładowany bezpośrednio przez środowisko Node.js. Dzięki temu złośliwy kod działa poza klasycznymi ograniczeniami rozszerzeń i może wykonywać operacje systemowe, zapisywać pliki, uruchamiać polecenia oraz komunikować się z zasobami zewnętrznymi z dużo większą swobodą.
Po uruchomieniu dropper skanuje stację roboczą w poszukiwaniu wszystkich środowisk obsługujących rozszerzenia kompatybilne z VS Code. Obejmuje to nie tylko standardowe wydania Visual Studio Code i VS Code Insiders, ale również forki i inne narzędzia programistyczne oparte na tym samym modelu rozszerzeń. W praktyce pojedyncza instalacja złośliwego dodatku może stać się punktem wejścia do kompromitacji wielu środowisk pracy działających równolegle na jednym urządzeniu.
Kolejny etap polega na pobraniu złośliwego pakietu .VSIX z repozytorium kontrolowanego przez atakujących. Pakiet podszywa się pod znane rozszerzenie związane z automatycznym importem, co zmniejsza ryzyko wzbudzenia podejrzeń. Następnie plik jest zapisywany w katalogu tymczasowym i instalowany po cichu do wszystkich wykrytych IDE przy użyciu mechanizmów wiersza poleceń dostępnych w poszczególnych edytorach.
Drugi etap infekcji odpowiada za właściwe działania operacyjne. Zgodnie z analizą badaczy komponent unika uruchamiania na systemach rosyjskich, wykorzystuje blockchain Solana do pozyskiwania informacji o infrastrukturze sterowania, wykrada dane, a następnie wdraża trojana zdalnego dostępu. W dalszej fazie może zostać zainstalowane również złośliwe rozszerzenie dla przeglądarki Google Chrome o charakterze infostealera, co rozszerza zakres kradzieży o dane sesyjne, tokeny i inne informacje przechowywane w przeglądarce.
Konsekwencje / ryzyko
Ryzyko związane z kampanią GlassWorm jest szczególnie wysokie dla programistów, zespołów DevOps, inżynierów platformowych oraz organizacji rozwijających oprogramowanie w złożonych środowiskach narzędziowych. Kompromitacja IDE nie kończy się na samym edytorze kodu. Taki punkt wejścia może umożliwić dostęp do repozytoriów, lokalnych kopii projektów, kluczy API, sekretów środowiskowych, tokenów dostępowych do CI/CD, poświadczeń chmurowych oraz materiałów kryptograficznych.
- kradzież kodu źródłowego i własności intelektualnej,
- przejęcie kont deweloperskich oraz zasobów CI/CD,
- dalsze rozprzestrzenianie się malware w organizacji,
- wstrzyknięcie złośliwego kodu do legalnych projektów,
- eskalację do incydentu obejmującego klientów i partnerów biznesowych.
Szczególnie groźny jest mechanizm wielośrodowiskowej propagacji. Użytkownik może zainstalować złośliwe rozszerzenie tylko raz, a malware samodzielnie rozprzestrzeni się na pozostałe zgodne narzędzia obecne w systemie. Taka taktyka zwiększa trwałość infekcji i utrudnia jej pełne usunięcie.
Rekomendacje
Organizacje powinny traktować instalację wskazanych rozszerzeń jako potencjalne pełne naruszenie stacji roboczej. Reakcja nie powinna ograniczać się do odinstalowania dodatku z jednego edytora, lecz objąć cały endpoint, wszystkie sekrety oraz aktywne sesje użytkownika.
- Odinstalować podejrzane rozszerzenia ze wszystkich zgodnych środowisk IDE.
- Przyjąć założenie kompromitacji hosta i przeprowadzić pełne dochodzenie na poziomie endpointu.
- Rotować tokeny Git, klucze SSH, poświadczenia chmurowe, dane dostępu do CI/CD, klucze API oraz sesje przeglądarkowe.
- Sprawdzić historię instalacji rozszerzeń i logi uruchamiania CLI w edytorach opartych na VS Code.
- Zweryfikować obecność nieautoryzowanych pakietów .VSIX, podejrzanych plików binarnych i artefaktów w katalogach tymczasowych.
- Monitorować ruch sieciowy związany z pobieraniem rozszerzeń i komunikacją z infrastrukturą pośrednią.
- Ograniczyć możliwość instalowania pluginów z niezweryfikowanych źródeł i wdrożyć listy dozwolonych rozszerzeń.
- Wzmocnić telemetrykę EDR dla procesów uruchamianych przez edytory kodu.
- Rozważyć separację stacji deweloperskich od codziennej pracy biurowej i przeglądania Internetu.
- Szkoleniowo uświadamiać zespoły techniczne o ryzykach związanych z rozszerzeniami marketplace i pakietami podszywającymi się pod znane narzędzia.
Dodatkowo warto wdrożyć polityki bezpieczeństwa software supply chain obejmujące ocenę reputacji wydawców, kontrolę integralności środowisk deweloperskich, podpisywanie komponentów oraz automatyczne skanowanie instalowanych artefaktów.
Podsumowanie
Najnowsza odsłona GlassWorm pokazuje, że środowiska IDE stały się pełnoprawnym celem zaawansowanych kampanii malware. Wykorzystanie natywnego droppera napisanego w Zig, wieloetapowej instalacji .VSIX oraz mechanizmów ukrywających infrastrukturę sterowania świadczy o rosnącej dojrzałości technicznej napastników.
Najważniejszy wniosek dla organizacji jest prosty: kompromitacja rozszerzenia deweloperskiego może bardzo szybko przerodzić się w naruszenie stacji roboczej, kont inżynierskich i całego łańcucha dostaw oprogramowania. Z tego względu rozszerzenia IDE powinny być zarządzane z taką samą ostrożnością jak inne uprzywilejowane komponenty środowiska pracy.