Co znajdziesz w tym artykule?
Wprowadzenie do problemu
Ekosystem rozszerzeń do edytorów kodu jest dziś integralną częścią procesu tworzenia oprogramowania, ale jednocześnie stanowi atrakcyjny cel dla cyberprzestępców. Incydent wykryty w repozytorium Open VSX pokazuje, że ataki typu „evil twin”, polegające na publikowaniu fałszywych odpowiedników legalnych dodatków, mogą służyć do cichego rozpoznania środowiska deweloperskiego i pozyskiwania cennych danych operacyjnych.
W praktyce oznacza to, że pozornie niegroźne rozszerzenie może stać się punktem wejścia do zbierania informacji o stacji roboczej, konfiguracji projektów, narzędziach CI/CD oraz relacjach między repozytoriami i organizacją.
W skrócie
W Open VSX wykryto i usunięto 77 złośliwych rozszerzeń podszywających się pod legalne narzędzia dla programistów. Pakiety były publikowane między 26 lipca a 1 sierpnia 2026 roku, a ich usunięcie nastąpiło 3 sierpnia 2026 roku.
Część próbek ograniczała się do podstawowego zbierania informacji, takich jak nazwa hosta. Bardziej zaawansowane warianty pozyskiwały jednak znacznie szerszy zestaw danych, obejmujący użytkownika systemu, otwarte repozytorium, ścieżki robocze, listę rozszerzeń oraz markery środowisk CI.
Kontekst i historia
Open VSX to otwarty rejestr rozszerzeń używany przez edytory i platformy zgodne z ekosystemem Visual Studio Code. Rosnąca popularność otwartych alternatyw dla komercyjnych marketplace’ów sprawia, że wzrasta również atrakcyjność tego typu platform dla napastników.
W analizowanej kampanii cyberprzestępcy kopiowali nazwy, opisy i przestrzenie nazw istniejących rozszerzeń, tworząc ich fałszywe odpowiedniki. Charakterystycznym elementem było publikowanie pakietów z niskimi numerami wersji, co mogło utrudniać szybkie wykrycie oszustwa przez użytkowników lub uproszczone procesy weryfikacyjne.
To klasyczny przykład ataku na łańcuch dostaw oprogramowania. Nie dochodzi tu do przejęcia oryginalnego dostawcy, lecz do wprowadzenia wiarygodnej imitacji do zaufanego kanału dystrybucji.
Analiza techniczna
Analiza wskazuje na istnienie dwóch głównych klas złośliwych rozszerzeń. Pierwsza grupa odpowiadała za prostą eksfiltrację podstawowych danych, takich jak nazwa hosta, katalog roboczy czy wersja edytora. Druga miała charakter rozpoznawczy i zbierała znacznie bardziej szczegółowe informacje o środowisku ofiary.
Po instalacji rozszerzenia nie dostarczały funkcji deklarowanych w opisach. Zamiast tego uruchamiały prosty element interfejsu, który miał sprawiać wrażenie poprawnego działania, a następnie wykonywały kod odpowiedzialny za telemetrykę i przesyłanie danych.
Bardziej zaawansowane próbki zbierały między innymi:
- lokalną nazwę hosta i nazwę użytkownika systemu,
- nazwę edytora, jego wersję oraz identyfikator maszyny,
- platformę systemową, architekturę, ustawienia regionalne i strefę czasową,
- nazwę oraz pełną ścieżkę otwartego katalogu roboczego,
- listę zainstalowanych rozszerzeń,
- informacje o konfiguracji proxy i wybranych zmiennych środowiskowych.
Szczególnie istotne było przeszukiwanie katalogu .git w celu identyfikacji zdalnych hostów Git, organizacji, domeny adresu e-mail, bieżącej gałęzi oraz identyfikatora commita HEAD. To wskazuje, że napastnikom zależało nie tylko na identyfikacji urządzenia, lecz także na mapowaniu środowiska projektowego i zależności organizacyjnych.
Rozszerzenia sprawdzały także obecność markerów środowisk CI/CD i pobierały wybrane zmienne charakterystyczne dla platform automatyzacji. Dzięki temu atakujący mogli ocenić wartość środowiska i potencjalnie przygotować kolejne etapy operacji wymierzone w pipeline budowania oraz wdrażania kodu.
Na uwagę zasługuje również mechanizm awaryjny oparty na zapytaniach DNS TXT, który umożliwiał pobranie alternatywnego adresu eksfiltracji w razie blokady podstawowej infrastruktury. Warianty rekonesansowe wykorzystywały też ponawianie prób w kolejnych odstępach czasu, co zwiększało ich skuteczność w środowiskach filtrowanych lub czasowo odłączonych od sieci.
Konsekwencje i ryzyko
Ryzyko wynikające z tego incydentu wykracza poza sam wyciek pojedynczych metadanych. Zebrane informacje mogą posłużyć do bardzo dokładnego profilowania środowiska deweloperskiego i identyfikacji najbardziej wartościowych celów w organizacji.
- Ułatwiają rozpoznanie używanych organizacji i repozytoriów.
- Pozwalają określić stosowane narzędzia i platformy CI/CD.
- Pomagają odtworzyć strukturę katalogów i schematy pracy zespołów.
- Umożliwiają ocenę, czy ofiara pracuje lokalnie, w kontenerze lub w środowisku zdalnym.
- Wspierają planowanie kolejnych etapów ataku, w tym spear-phishingu i prób kradzieży poświadczeń.
Tego typu kampanie są szczególnie groźne z perspektywy DevSecOps, ponieważ dostarczają napastnikom wiedzy o relacjach między kodem, infrastrukturą i procesem dostarczania oprogramowania. To może prowadzić do dalszej kompromitacji repozytoriów, tokenów deweloperskich lub środowisk build i deployment.
Rekomendacje
Organizacje korzystające z Open VSX lub kompatybilnych edytorów powinny potraktować ten incydent jako sygnał do przeglądu polityk bezpieczeństwa dotyczących rozszerzeń.
- Ograniczyć instalację dodatków wyłącznie do zatwierdzonych list i zaufanych wydawców.
- Weryfikować nazwę pakietu, identyfikator wydawcy oraz historię wersji przed wdrożeniem.
- Monitorować ruch wychodzący ze stacji deweloperskich i środowisk CI pod kątem nietypowych połączeń generowanych przez rozszerzenia.
- Regularnie audytować listę zainstalowanych dodatków w stacjach roboczych, kontenerach i obrazach bazowych.
- Izolować środowiska programistyczne od wrażliwych sekretów, tokenów i poświadczeń.
- Włączyć analizę behawioralną rozszerzeń przed dopuszczeniem ich do użytku.
- Kontrolować pliki konfiguracyjne, takie jak
.vscode/extensions.jsonidevcontainer.json, aby wykrywać nieautoryzowane rekomendacje instalacji. - Zintegrować nadzór nad rozszerzeniami z procesami SBOM, SCA oraz politykami ochrony software supply chain.
Jeśli istnieje podejrzenie instalacji jednego z fałszywych rozszerzeń, należy przeprowadzić analizę hosta, zweryfikować historię połączeń wychodzących, sprawdzić ekspozycję danych repozytoryjnych oraz rozważyć rotację tokenów i poświadczeń używanych przez dewelopera i powiązane systemy CI/CD.
Podsumowanie
Usunięcie 77 złośliwych rozszerzeń z Open VSX pokazuje, że edytory kodu i ich marketplace’y stały się pełnoprawnym polem działań w atakach na łańcuch dostaw oprogramowania. W tym przypadku celem nie był bezpośredni sabotaż, lecz ciche rozpoznanie środowisk deweloperskich i zbieranie danych o wysokiej wartości operacyjnej.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona środowisk developerskich nie może kończyć się na repozytoriach i pipeline’ach. Równie ważna staje się kontrola zaufania do rozszerzeń, ich wydawców oraz rzeczywistego zachowania po instalacji.