Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem rozszerzeń do edytorów kodu jest dziś istotnym elementem łańcucha dostaw oprogramowania. Każdy dodatek instalowany w środowisku programistycznym uzyskuje dostęp do kontekstu pracy dewelopera, informacji o projekcie oraz metadanych systemowych, dlatego fałszywe rozszerzenia publikowane w otwartych rejestrach mogą stanowić realne zagrożenie operacyjne i wywiadowcze.
W najnowszym incydencie badacze bezpieczeństwa wykryli 77 rozszerzeń opublikowanych w Open VSX, które podszywały się pod legalne narzędzia dla programistów. Kampania nie koncentrowała się na natychmiastowej kradzieży kodu czy poświadczeń, lecz na systematycznym zbieraniu danych o środowiskach developerskich.
W skrócie
- W Open VSX wykryto 77 złośliwych rozszerzeń imitujących legalne dodatki.
- Kampania miała charakter „evil twin”, czyli opierała się na publikowaniu fałszywych pakietów o nazwach i opisach przypominających autentyczne narzędzia.
- 58 próbek zbierało podstawowe informacje o systemie, a 19 prowadziło szerszy rekonesans środowiska deweloperskiego.
- Zbierane dane obejmowały m.in. nazwę hosta, nazwę użytkownika, informacje o workspace, dane z repozytoriów Git oraz ślady użycia platform CI/CD.
- Nie odnotowano bezpośredniej kradzieży kodu źródłowego, tokenów czy kluczy SSH, jednak skala telemetrii wskazuje na poważne ryzyko dla organizacji.
Kontekst / historia
Open VSX to otwarty rejestr rozszerzeń wykorzystywany przez narzędzia zgodne z ekosystemem Visual Studio Code, szczególnie tam, gdzie nie korzysta się z domyślnego marketplace’u Microsoftu. Tego typu platformy są atrakcyjnym celem dla operatorów kampanii supply chain, ponieważ pozwalają dotrzeć bezpośrednio do środowisk pracy programistów.
Fałszywe rozszerzenia pojawiły się pod koniec lipca 2026 roku. Według analizy wszystkie 77 pakietów było powiązanych wspólną infrastrukturą oraz podobnym kodem odpowiedzialnym za zbieranie i przesyłanie danych. Atakujący podszywali się pod różne narzędzia i marki, zwiększając szansę, że użytkownicy zainstalują dodatki bez dokładnej weryfikacji wydawcy.
Na uwagę zasługuje również kontekst regulacyjny samej platformy. Polityki Open VSX formalnie obejmują zgłoszenia dotyczące złośliwych rozszerzeń, nadużyć ze strony wydawców, mylących opisów oraz nieujawnionego zbierania danych. Oznacza to, że problem nie dotyczy wyłącznie pojedynczego incydentu, ale szerszego wyzwania związanego z bezpieczeństwem publikacji i konsumpcji rozszerzeń.
Analiza techniczna
Technicznie kampania opierała się na modelu „evil twin extension”. Cyberprzestępcy tworzyli pakiety naśladujące legalne rozszerzenia, kopiując nazwy, przestrzenie nazw oraz opisy. Zamiast deklarowanej funkcjonalności użytkownik otrzymywał jednak kod odpowiedzialny za telemetrię i rekonesans środowiska.
Wszystkie 77 rozszerzeń komunikowało się ze wspólną domeną kontrolowaną przez operatora kampanii. Każde z nich zawierało indywidualny identyfikator śledzący, co pozwalało przypisać instalację do konkretnego fałszywego dodatku. W praktyce umożliwiało to śledzenie skuteczności kampanii i mapowanie ofiar.
Zakres zbieranych danych różnił się w zależności od wariantu. Prostsze próbki wysyłały głównie nazwę hosta, czasem również nazwę folderu roboczego i wersję edytora. Bardziej rozbudowane warianty aktywowały się po kilku sekundach i gromadziły znacznie szerszy zestaw informacji.
- nazwę użytkownika systemu i nazwę hosta,
- identyfikator maszyny,
- nazwę i wersję edytora,
- architekturę platformy,
- ustawienia regionalne i strefę czasową,
- nazwę oraz pełną ścieżkę otwartego workspace,
- informacje z katalogu .git, w tym hosty zdalne, organizacje, aktywną gałąź i skrót commita HEAD,
- identyfikatory związane z platformami CI/CD oraz środowiskami developerskimi w chmurze.
Szczególnie niepokojące było rozpoznawanie środowisk takich jak GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespaces czy Gitpod. Dane tego typu nie zapewniają od razu dostępu do zasobów, ale pozwalają bardzo precyzyjnie określić profil technologiczny organizacji oraz potencjalne cele kolejnych etapów ataku.
Część rozszerzeń była ponadto przygotowana na problemy z łącznością. Malware potrafił przez wiele dni ponawiać próby transmisji danych, korzystać z alternatywnych punktów końcowych, a nawet pobierać zapasowy adres serwera z rekordów DNS TXT. To sugeruje przemyślaną odporność operacyjną mimo braku destrukcyjnego charakteru samego kodu.
Konsekwencje / ryzyko
Największe zagrożenie w tym przypadku nie wynikało z bezpośredniej kradzieży sekretów, lecz z pozyskiwania metadanych o środowiskach inżynierskich. Dla przeciwnika prowadzącego działania rozpoznawcze takie informacje mają dużą wartość, ponieważ pozwalają zbudować szczegółowy obraz organizacji, jej narzędzi oraz procesów developerskich.
- umożliwiają identyfikację używanych platform i technologii,
- ujawniają nazwy projektów, repozytoriów i struktur katalogów,
- pokazują, jakie środowiska CI/CD są wykorzystywane,
- ułatwiają przygotowanie kampanii phishingowych lub ataków ukierunkowanych,
- mogą stanowić wstęp do dalszych działań przeciwko łańcuchowi dostaw.
Nawet jeśli pojedyncze rozszerzenie nie wykrada kodu źródłowego, zestawienie nazw organizacji, branchy, ścieżek systemowych, domen i identyfikatorów środowisk może ujawnić bardzo wiele o wewnętrznej architekturze przedsiębiorstwa. W praktyce oznacza to wzrost ryzyka ataków precyzyjnie dopasowanych do ofiary.
Rekomendacje
Organizacje powinny potraktować ten incydent jako ostrzeżenie i zaostrzyć polityki bezpieczeństwa dotyczące rozszerzeń instalowanych w IDE. Samo usunięcie złośliwych pakietów z rejestru nie oznacza bowiem, że zniknęły one automatycznie ze stacji roboczych użytkowników.
- przeprowadzić audyt zainstalowanych rozszerzeń w środowiskach korzystających z Open VSX,
- porównać zainstalowane dodatki z listami wskaźników kompromitacji opublikowanymi przez badaczy,
- wprowadzić listę dozwolonych rozszerzeń pochodzących wyłącznie od zweryfikowanych wydawców,
- monitorować ruch sieciowy generowany przez IDE i dodatki,
- blokować znane domeny i podejrzane punkty końcowe,
- ograniczać uprawnienia środowisk deweloperskich do repozytoriów, systemu plików i platform CI/CD,
- wdrożyć ciągłe skanowanie rozszerzeń pod kątem ukrytej telemetrii i podejrzanych zależności,
- rozważyć izolację IDE oraz stosowanie środowisk ephemeral development w projektach o podwyższonych wymaganiach bezpieczeństwa.
Podsumowanie
Incydent z 77 fałszywymi rozszerzeniami Open VSX pokazuje, że zagrożenia supply chain wykraczają daleko poza biblioteki, paczki i obrazy kontenerowe. Coraz większym obszarem ryzyka są dodatki instalowane bezpośrednio w edytorach kodu, ponieważ działają blisko programisty i mają dostęp do cennego kontekstu projektowego.
Choć wykryte rozszerzenia nie kradły bezpośrednio kodu ani poświadczeń, ich możliwości rozpoznawcze były wystarczające, by mapować środowiska inżynierskie, repozytoria i procesy CI/CD. Dla firm to wyraźny sygnał, że marketplace’y rozszerzeń muszą być traktowane jako pełnoprawny element strategii cyberbezpieczeństwa.