
GlassWorm — niewidzialny kod, który wślizgnął się do 413 repozytoriów
GlassWorm nie pytał o zgodę – po cichu zmienił kierunek i przestał być jedynie problemem Windows. W styczniu zaczął atakować też macOS, a w efekcie kampania objęła co najmniej 413 repozytoriów na npm, w rozszerzeniach VSCode, w OpenVSX i w samym GitHubie – wszystko skierowane tak, jakby za pakowaniem stał pojedynczy, wyrafinowany aktor.
Pod maską dzieje się magia — ale tej magii nie chcesz
Ta kampania nie przypomina klasycznego wirusa z 90. lat – tutaj złośliwość ukrywa się w miejscach, których nigdy nie będziesz szukać. Atakujący używał „niewidzialnych” znaków i subtelnych zmian w plikach, żeby przemycić kod tak, żeby wyglądał obojętnie. Efekt – zależności, które instalujesz automatycznie, mogą zawierać mechanizmy uruchamiające ładunek złośliwy.
Kto to puścił w eter? Jeden aktor czy tłum? – wskazówki mówią jedno
Analizy wskazują na powtarzalne wzorce i wspólne metody — to nie zwykły bałagan. Zbieżność technik i miejsca ataku sugeruje jednego autora kampanii albo grupę działającą według tej samej „księgi”. To ważne, bo jak masz do czynienia z chaosem, reagujesz inaczej niż wtedy, gdy ktoś operuje metodycznie – polowanie na pojedyncze źródło ułatwia blokady i remediację.
Jak to działa – niewidzialny kod i podstępne wejścia
Najczęściej używane triki są proste, ale skuteczne – drobne zmiany w nazwach paczek, wstawki w README, ukryte znaki Unicode. Dla ludzkiego oka nic się nie zmienia – dla systemów automatycznie pobierających zależności to gotowe wejście. Potem zainfekowany pakiet może uruchomić skrypt, zebrać dane, wykradać tokeny CI, albo zaszczepić kolejny łańcuch zależności.
Skala robi wrażenie – 413 repozytoriów i co dalej?
413 to minimum – zasięg tej operacji pokazuje jak bardzo system zależności jest podatny. To nie tylko pojedynczy problem developera, to potencjalne wejście do projektów, które korzystają z bibliotek w całym ekosystemie. Im więcej automatycznych procesów – buildów, instalacji w CI, tym szybsze rozprzestrzenianie.
Co robić teraz — szybka lista działań
- Przejrzyj zależności – szukaj paczek o podejrzanie podobnych nazwach i nietypowych znaków w nazwach lub plikach.
- Pinuj wersje i blokuj aktualizacje – używaj lockfile, określ wersje, aby zapobiec nagłym zmianom w łańcuchu zależności.
- Obejrzyj skrypty instalacyjne – sprawdź, czy pakiety nie uruchamiają postinstallów lub innych skryptów, które mogą wykonywać zewnętrzne polecenia.
- Izoluj środowiska CI – usuń niepotrzebne tokeny z buildów, nadaj minimalne uprawnienia, rotuj klucze jeśli istnieje podejrzenie wycieku.
- Skorzystaj ze skanerów bezpieczeństwa – narzędzia SCA i skanery repozytoriów pomogą zidentyfikować znane sygnatury złośliwego kodu.
- Wprowadź 2FA i ograniczenia dostępu – najmniejsze konto z dostępem do repozytorium powinno mieć jak najmniej uprawnień.
Nie ufaj, sprawdzaj — i zamykaj drzwi, zanim ktoś wejdzie
GlassWorm to przypomnienie, że kod, który wygląda niewinnie, może być furtką – więc sprawdzaj zależności, pilnuj CI i traktuj automatykę jak potencjalne wejście dla złego aktora. A potem idź się napić – lepiej mieć czystą głowę, kiedy trzeba zakasać rękawy.