Fałszywe rozszerzenie „Solidity” w Open VSX z trojanem SleepyDuck. Jak atakowało i jak się bronić

Wprowadzenie do problemu / definicja luki

W rejestrze Open VSX wykryto fałszywe rozszerzenie dla języka Solidity: juan-bianco.solidity-vlang. Początkowo niewinne wydanie z 31 października 2025 r. zostało dzień później zaktualizowane o złośliwe możliwości — już po zdobyciu dużej liczby pobrań. Rozszerzenie zawierało trojana zdalnego dostępu SleepyDuck, który komunikuje się z serwerem dowodzenia m.in. poprzez kontrakt na blockchainie Ethereum, co utrudnia neutralizację infrastruktury C2. Z pakietu skorzystały dziesiątki tysięcy użytkowników Open VSX, w tym popularnych forków VS Code (Cursor, Windsurf).

W skrócie

• Wejście: fałszywe rozszerzenie „Solidity” w Open VSX.
• Ładunek: RAT SleepyDuck z mechanizmem C2 opartym na kontrakcie Ethereum (odporność na wyłączenie domeny).
• Aktywacja: start edytora, otwarcie pliku .sol lub kompilacja.
• Cel: kradzież danych systemowych i wykonywanie poleceń; ryzyko dalszej eskalacji.
• Reakcja: Open VSX rotuje tokeny wydawnicze i wdraża dodatkowe kontrole po serii incydentów łańcucha dostaw.

Kontekst / historia / powiązania

Ostatnie miesiące przyniosły presję na ekosystemy rozszerzeń edytorów. Wiz Research ujawnił >550 wyciekłych sekretów, w tym dostępy wydawnicze do marketplace’ów, co umożliwia przestępcom wpychanie złośliwych aktualizacji do już popularnych rozszerzeń (autoupdate robi resztę). Open VSX jest szczególnie atrakcyjny dla użytkowników Cursor/Windsurf, bo nie mogą oni korzystać z oficjalnego Microsoft Visual Studio Marketplace.

Open VSX/Eclipse poinformował następnie, że incydenty zostały opanowane do 21 października 2025 r. oraz zapowiedział krótsze TTL tokenów, łatwiejsze unieważnianie, skany przy publikacji i wymianę informacji z innymi platformami.

Warto pamiętać, że Solidity-devowie są celem od dawna: w lipcu 2025 r. opisano przypadek kradzieży ~500 000 USD po instalacji fałszywego rozszerzenia z Open VSX/Cursor.

Analiza techniczna / szczegóły luki

• Wejście i maskowanie: wydanie 0.0.7 było „czyste”; 0.0.8 (1 listopada) dołożyło komponenty złośliwe. Zanim to nastąpiło, rozszerzenie zdążyło nabić ~14 tys. pobrań, co zwiększyło bazę ofiar na starcie. Twórcy złośliwego pakietu stosowali też taktyki pozycjonowania (aktualność, pobrania) typowe dla ataków na marketplace’y.
• Warunki aktywacji: start IDE, otwarcie pliku .sol lub wywołanie komendy kompilacji Solidity.
• Ładunek i telemetria: komponent inicjalizujący podszywa się pod webpack.init() i ładuje payload, który zbiera hostname, username, MAC, strefę czasową oraz uruchamia sandbox wykonywania komend.
• C2 i odporność: moduł wybiera najszybszego dostawcę Ethereum RPC, odczytuje kontrakt zawierający bieżącą konfigurację (np. nowy adres C2, interwały), a gdy domena C2 padnie, polecenia i aktualizacje są pobierane prosto z łańcucha. To zapewnia przetrwanie kampanii mimo blokad DNS/hostingu.

Praktyczne konsekwencje / ryzyko

• Ryzyko operacyjne: zdalne wykonywanie poleceń w środowisku deweloperskim → kradzież sekretów (tokeny, klucze), modyfikacja repozytoriów, dołączanie do kolejnych ataków łańcucha dostaw.
• Ryzyko finansowe: historycznie ataki na rozszerzenia „Solidity” prowadziły do utracenia środków z portfeli krypto i kompromitacji stacji roboczych.
• Ryzyko systemowe: wycieki tokenów wydawniczych tworzą masowy punkt zapalny — atakujący może wypchnąć złośliwą AKTUALIZACJĘ do całej bazy instalacji rozszerzenia.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa / dev platform:

1. Inwentaryzacja i blokady: utrzymujcie listę dozwolonych rozszerzeń (allowlist) i centralną dystrybucję rozszerzeń. Wyłączcie instalacje spoza zaufanych wydawców.
2. Zarządzanie aktualizacjami: rozważcie opóźnione autoupdate rozszerzeń + promowanie wersji po skanowaniu (staging).
3. Monitoring IDE: detekcje na uruchamianie skryptów z katalogów rozszerzeń (~/.vscode/extensions, %USERPROFILE%\.vscode\extensions) i nietypowe wywołania PowerShell/cmd przez procesy VS Code/Cursor.
4. Skany IOCs: blokujcie znane wskaźniki (domeny typu sleepyduck[.]xyz, adresy kontraktów, nietypowe zapytania RPC). (Wg materiałów badawczych, C2 i kontrakt są częścią TTP tej kampanii).
5. Higiena sekretów: skanowanie repozytoriów i paczek .vsix pod kątem sekretów; rotacja tokenów publikacyjnych; krótkie TTL i prefiksy ułatwiające detekcję. (To też kierunek zmian po stronie Open VSX).

Dla pojedynczych deweloperów:

• Instaluj rozszerzenia wyłącznie od znanych wydawców; weryfikuj historię, kod źródłowy i różnicę między podobnie nazwanymi pakietami (popularna technika podszywania się).
• Zredukuj liczbę rozszerzeń do niezbędnego minimum; każde to nowa powierzchnia ataku.
• Włącz monitorowanie EDR/XDR na stacjach dev i segregację portfeli krypto (oddzielne hosty/przeglądarki, sprzętowe klucze, brak kluczy na maszynach dev). (Rekomendacje wynikają z analizy incydentów krypto-kradzieży na tle fałszywych rozszerzeń).

Różnice / porównania z innymi przypadkami

• SleepyDuck vs. wcześniejsze kampanie (Cursor/Open VSX 2025): wcześniejsze przypadki częściej stawiały na klasyczny zdalny dostęp (np. ScreenConnect) i kradzież seedów; SleepyDuck wprowadza C2 przez kontrakt Ethereum, co utrudnia wyłączenie kampanii i sprzyja długowieczności złośliwych konfiguracji.
• GlassWorm / wycieki tokenów: równoległe kampanie wykorzystywały wycieknięte tokeny wydawnicze do publikowania/zamiany wersji rozszerzeń na złośliwe. Odpowiedzią były rotacje tokenów i skrócenie czasu życia po stronie Open VSX.

Podsumowanie / kluczowe wnioski

• Zaufanie do marketplace’ów IDE nie może zastąpić kontroli bezpieczeństwa po stronie organizacji.
• Atakujący coraz częściej używają łańcucha bloków jako kanału C2 (odporność na zdejmowanie domen).
• Operatory rejestrów (Open VSX) wzmacniają kontrole — rotują tokeny, skracają TTL, dodają skany — ale higiena po stronie wydawców i użytkowników jest równie kluczowa.

Źródła / bibliografia

1. BleepingComputer — „Fake Solidity VSCode extension on Open VSX backdoors developers” (03.11.2025). (BleepingComputer)
2. Eclipse Foundation — „Open VSX security update, October 2025” (27.10.2025). (Eclipse Foundation Staff Blogs)
3. Wiz Research — „Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (15.10.2025). (wiz.io)
4. BleepingComputer — „Open VSX rotates access tokens used in supply-chain malware attack” (02.11.2025). (BleepingComputer)
5. Kaspersky — „How installing a fake extension from Open VSX led to cryptocurrency theft” (10.07.2025). (Kaspersky)