Wprowadzenie do problemu / definicja luki
Atak typu software supply chain ponownie uderzył w ekosystemy rejestrów pakietów – tym razem w oficjalne biblioteki klienckie powiązane z dYdX v4. Złośliwe aktualizacje opublikowane do npm i PyPI podszywały się pod legalne wydania, a ich celem była kradzież danych portfela (m.in. seed phrase) oraz zdalne wykonywanie komend na maszynie ofiary.
W skrócie
- Dotknięte zostały pakiety: @dydxprotocol/v4-client-js (npm) oraz dydx-v4-client (PyPI).
- Złośliwe wersje wskazane przez badaczy:
- npm: 3.4.1, 1.22.1, 1.15.2, 1.0.31
- PyPI: 1.1.5post1 / 1.1.5.post1
- Pythonowy wariant zawierał silnie zaciemniony, wieloetapowy loader, którego skutkiem jest uruchomienie złośliwego kodu i kontakt z domeną dydx[.]priceoracle[.]site/py.
- Wskazywany wektor: kompromitacja konta/poświadczeń maintenera (publikacja „legalnymi” danymi).
Kontekst / historia / powiązania
To nie pierwszy raz, gdy komponenty dYdX są celem ataków łańcucha dostaw. W 2022 r. opisywano incydent, w którym przejęcie konta w npm umożliwiło wypchnięcie złośliwych wersji pakietów powiązanych z dYdX.
Wspólny mianownik takich kampanii to uderzenie w zaufane kanały dystrybucji (registry), co daje atakującym skalę i „naturalną” ścieżkę dotarcia do środowisk deweloperskich, CI/CD i botów tradingowych.
Analiza techniczna / szczegóły luki
1) Co robił złośliwy kod w npm?
W przypadku npm, badacze opisują wallet stealera wykradającego m.in. seed phrase oraz informacje o urządzeniu (fingerprinting). Co istotne, implant miał być osadzony w plikach wykonywanych w typowym przepływie użycia biblioteki (nie „martwy” kod).
2) Co robił złośliwy kod w PyPI?
Wersja dydx-v4-client oznaczona jako 1.1.5.post1 została sklasyfikowana jako krytyczna w bazie GitHub Advisory Database: zawierała „highly obfuscated multi-stage loader”, a warstwowe kodowanie (wskazywane jako ~100 warstw) utrudniało analizę końcowego payloadu.
Kluczowy artefakt behawioralny: łańcuch dekompresji/rekurencji zakończony exec() i komunikacja z hxxps://dydx[.]priceoracle[.]site/py w celu pobrania i uruchomienia kolejnych etapów.
3) Kiedy następowała egzekucja?
THN wskazuje, iż komponent RAT w wariancie Python uruchamiał się przy imporcie pakietu, co jest szczególnie groźne dla środowisk automatyzacji (np. boty/worker’y), gdzie import jest częścią standardowego startu aplikacji.
Praktyczne konsekwencje / ryzyko
Najważniejsze ryzyka dla zespołów budujących narzędzia tradingowe, integracje DeFi i automaty:
- Kompromitacja portfeli (seed phrase / klucze / tokeny) → nieodwracalna kradzież środków.
- Remote Code Execution poprzez RAT/loader → przejęcie stacji deweloperskiej, runnera CI, serwera bota, a dalej pivot do repozytoriów i sekretów (np. API keys giełd, klucze do chmur).
- Ryzyko rozlania w łańcuchu dostaw: jeżeli skażony komponent trafi do obrazu kontenera lub artefaktu wydania, infekcja może dotknąć wielu użytkowników downstream.
Rekomendacje operacyjne / co zrobić teraz
Jeśli istnieje choć cień szansy, iż pobrano zainfekowane wersje:
- Zidentyfikuj i usuń skażone wersje
- npm: wyszukaj, czy w lockfile / cache / artifactach pojawiają się wersje: 3.4.1, 1.22.1, 1.15.2, 1.0.31 dla @dydxprotocol/v4-client-js.
- PyPI: sprawdź, czy zainstalowano dydx-v4-client==1.1.5.post1 (alias 1.1.5post1).
- Natychmiastowy rollback / pinning
- GitHub Advisory zaleca odinstalować 1.1.5.post1 i wrócić do 1.1.5 (wersja „patched”).
- Zweryfikuj, jakie wersje są publikowane w PyPI i trzymaj się znanych dobrych wydań (na stronie projektu jako „Latest” widnieje 1.1.5).
- Zakładaj kompromitację sekretów
- Rotuj API keys, tokeny, hasła, a w kontekście krypto: przenieś środki na nowy portfel wygenerowany na czystej maszynie (to podejście komunikował też ekosystem dYdX wg relacji THN).
- Izolacja i triage hostów
- Odłącz podejrzane hosty (workstation/runner/bot) od sieci, zbierz logi procesu/Python importów/Node runtime, poszukaj komunikacji do dydx.priceoracle.site oraz nietypowych procesów potomnych.
- Wzmocnij pipeline (na przyszłość)
- Wymuś 2FA dla kont maintenerskich, ogranicz uprawnienia tokenów publikacyjnych, rozdziel konta do publikacji od kont osobistych. (To kluczowe, gdy źródłem jest przejęcie poświadczeń).
- W CI/CD stosuj allowlistę rejestrów, skanowanie zależności (SCA), kontrolę integralności (lockfiles), oraz polityki blokujące niespodziewane aktualizacje w krytycznych komponentach.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- 2022 (npm): podobny motyw – przejęcie i publikacja złośliwych wersji w ekosystemie dYdX.
- 2026 (npm + PyPI równolegle): uderza skoordynowanie „cross-ecosystem” (JS i Python) oraz nacisk na wieloetapowy loader i RCE w Pythonie, co zwiększa potencjał do przejęć infrastruktury, nie tylko portfeli.
Podsumowanie / najważniejsze wnioski
Incydent z lutego 2026 r. pokazuje, iż w projektach obsługujących operacje kryptograficzne i portfele (podpisywanie transakcji, zarządzanie kluczami, boty tradingowe) zależności z npm/PyPI są celem najwyższej wartości. Skażone wydania @dydxprotocol/v4-client-js oraz dydx-v4-client==1.1.5.post1 łączą kradzież danych portfela z możliwością zdalnego sterowania hostem, co czyni ten przypadek wyjątkowo groźnym dla środowisk produkcyjnych i CI.
Źródła / bibliografia
- The Hacker News – opis incydentu, listy wersji, zachowanie RAT/stealera. (The Hacker News)
- Socket – analiza ataku i kontekst kompromitacji maintenera. (Socket)
- GitHub Advisory Database (GHSA-4f84-67cv-qrv3) – krytyczny advisory dla dydx-v4-client==1.1.5.post1, opis loadera i domeny C2. (GitHub)
- PyPI – strona projektu dydx-v4-client (referencja do wersji i historii wydań). (PyPI)
- Mend (2022) – tło historyczne wcześniejszego kompromisu npm powiązanego z dYdX. (Mend.io)