Open VSX: 77 złośliwych rozszerzeń podszywało się pod narzędzia deweloperskie

W repozytorium Open VSX wykryto 77 rozszerzeń typu evil twin, które naśladowały nazwy, opisy i funkcje popularnych dodatków do edytorów zgodnych z VS Code. Po instalacji zbierały informacje o hoście, użytkowniku, systemie, ścieżkach i środowisku deweloperskim, a następnie wysyłały je do infrastruktury operatora kampanii.

Rozszerzenie edytora nie jest zwykłym motywem graficznym. Może czytać otwarty projekt, uruchamiać kod Node.js, obserwować polecenia, korzystać z sieci i widzieć część sekretów obecnych w procesie IDE. Dlatego kompromitacja marketplace’u lub skuteczne podszycie się pod wydawcę jest atakiem na łańcuch dostaw o zasięgu równym uprawnieniom dewelopera.

Mechanizm kampanii

Operatorzy wykorzystywali podobieństwo nazw i ikon, licząc na instalację z podpowiedzi wyszukiwarki albo instrukcji projektu. Część dodatków prezentowała oczekiwaną funkcję, aby nie wzbudzać podejrzeń. Złośliwy JavaScript działał w tle, profilował system i wykonywał połączenia wychodzące.

Open VSX jest używany przez VSCodium i liczne forki oraz środowiska chmurowe. Nie należy utożsamiać go z oficjalnym Microsoft Marketplace: wydawca i identyfikator dodatku mogą różnić się między rejestrami. Ten sam wizualny tytuł nie oznacza tej samej tożsamości pakietu.

Wcześniejsze badania, m.in. analiza kampanii Count Dooku, pokazały, że napastnicy potrafią publikować wiele wariantów, używać zależności rozszerzeń i aktualizacji oraz szybko odbudowywać usunięte pozycje. Usunięcie pakietu z katalogu nie usuwa go automatycznie ze stacji, a zapisane dane uwierzytelniające pozostają narażone.

Co może zostać przejęte

Najbardziej wrażliwe są stacje z kluczami SSH, poświadczeniami chmurowymi, tokenami npm/PyPI, dostępem do prywatnych repozytoriów i narzędziami produkcyjnymi. Zbieranie nazw katalogów i repozytoriów może wystarczyć do wyboru celu. Jeżeli rozszerzenie odczyta zmienne środowiskowe lub pliki konfiguracyjne, kampania przechodzi z rozpoznania do przejęcia kont i publikowania pakietów.

W organizacji nie wystarczy zapytać użytkowników, czy rozpoznają nazwę dodatku. Trzeba zebrać pełny identyfikator publisher.extension, wersję, źródło instalacji, hash pakietu i czas pierwszego pojawienia się.

Plan dla zespołu DevSecOps

1. Wyeksportuj listę rozszerzeń ze wszystkich edytorów i porównaj ją z zatwierdzonym katalogiem, uwzględniając identyfikator wydawcy.
2. Usuń podejrzane dodatki, zachowując wcześniej pakiet VSIX, logi i telemetrykę sieciową do analizy.
3. Rotuj klucze obecne na stacji od czasu instalacji, szczególnie SSH, Git, chmurę, rejestry pakietów i CI/CD.
4. Przeszukaj DNS, proxy i EDR pod kątem nowych domen kontaktowanych przez procesy edytora i potomne procesy Node.js.
5. Zablokuj instalację spoza firmowej allowlisty albo dostarczaj rozszerzenia przez kontrolowany wewnętrzny rejestr.
6. Weryfikuj podpis, hash, repozytorium źródłowe i historię wydawcy; liczba pobrań nie jest dowodem zaufania.
7. Uruchamiaj środowiska deweloperskie bez stałych sekretów i stosuj krótkotrwałe poświadczenia wydawane dla konkretnej operacji.

Inwentaryzacja musi obejmować więcej niż laptop

Rozszerzenia IDE trafiają także do kontenerów developerskich, zdalnych workspace’ów, obrazów golden image i cache’y używanych do szybkiego odtwarzania środowiska. Usunięcie dodatku z jednej stacji nie wystarczy, jeśli ten sam VSIX pozostaje w szablonie devcontainer albo w katalogu rozszerzeń montowanym do kolejnych sesji. IOC trzeba więc odnieść do artefaktów budowania stacji, nie tylko do listy aktualnie zalogowanych użytkowników.

W telemetryce warto powiązać hash rozszerzenia z procesami potomnymi edytora. Legalny dodatek językowy może uruchamiać kompilator, ale rzadko powinien czytać wiele katalogów z kluczami, enumerować poświadczenia chmurowe i łączyć się z nowo zarejestrowaną domeną. Baseline per identyfikator rozszerzenia pozwala wykryć zmianę zachowania po aktualizacji. Dla krytycznych zespołów aktualizacja powinna przechodzić etap kwarantanny i analizę różnicy uprawnień, zamiast trafiać automatycznie na wszystkie stanowiska.

Fakty źródłowe a analiza

Publiczne raporty potwierdzają znalezienie i usunięcie 77 pozycji oraz zbieranie danych przez złośliwy kod. Nie każda instalacja oznacza kradzież każdego sekretu, a dokładny zasięg zależy od wersji dodatku i uprawnień procesu.

Wniosek Breachroad: marketplace IDE jest repozytorium wykonywalnego kodu, więc wymaga kontroli jak npm czy obrazy kontenerowe. Szkolenia dla deweloperów powinny obejmować weryfikację dodatków, a audyt bezpieczeństwa IT może ocenić allowlistę, EDR, sekrety i zdolność do odtworzenia stacji.