Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły luki
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
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) orazdydx-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
- npm:
- 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, że 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śli 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, że 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.31dla@dydxprotocol/v4-client-js. - PyPI: sprawdź, czy zainstalowano
dydx-v4-client==1.1.5.post1(alias1.1.5post1).
- Natychmiastowy rollback / pinning
- GitHub Advisory zaleca odinstalować
1.1.5.post1i wrócić do1.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.siteoraz 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 / kluczowe wnioski
Incydent z lutego 2026 r. pokazuje, że 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)