Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki typu supply chain na ekosystemy programistyczne należą dziś do najgroźniejszych zagrożeń dla bezpieczeństwa oprogramowania. W opisywanym incydencie skompromitowany został pakiet @injectivelabs/sdk-ts publikowany w rejestrze npm, wykorzystywany do budowy aplikacji dla blockchaina Injective. Złośliwa wersja biblioteki została zmodyfikowana w taki sposób, aby przechwytywać prywatne klucze oraz frazy mnemonic seed użytkowników portfeli kryptowalutowych.
W skrócie
Incydent dotyczył przejęcia konta współtwórcy projektu i opublikowania złośliwej wersji pakietu oznaczonej jako 1.20.21. Atakujący powiązali również 17 innych pakietów z tą skompromitowaną zależnością. Malware nie aktywował się podczas samej instalacji, lecz dopiero przy wywołaniu funkcji odpowiedzialnych za generowanie lub importowanie kluczy portfela.
- Złośliwy kod przechwytywał klucze prywatne i seed phrase.
- Dane były kodowane i przygotowywane do eksfiltracji przez HTTP.
- Wkrótce po wykryciu opublikowano czystą wersję
1.20.23. - Część środowisk deweloperskich mogła jednak zostać wcześniej narażona.
Kontekst / historia
Injective SDK to zestaw narzędzi TypeScript i JavaScript używany do tworzenia aplikacji dla ekosystemu DeFi, giełd zdecentralizowanych, botów tradingowych, portfeli oraz rozwiązań płatniczych opartych na blockchainie Injective. Ze względu na charakter zastosowań pakiet operuje na wyjątkowo wrażliwych materiałach kryptograficznych.
Z dostępnych informacji wynika, że pierwszy podejrzany commit pojawił się 8 czerwca 2026 roku po przejęciu konta należącego do legalnego współpracownika projektu. Następnie opublikowano złośliwą wersję biblioteki w npm. Właściciel konta wykrył naruszenie w ciągu kilku minut, wycofał zmiany i udostępnił poprawione wydanie. Mimo szybkiej reakcji zagrożenie było realne, ponieważ złośliwa wersja została pobrana przez część użytkowników, a artefakty powiązane z kompromitacją pozostały dostępne.
Analiza techniczna
Był to precyzyjny atak supply chain wymierzony w proces budowy aplikacji Web3. Złośliwy kod nie zachowywał się jak typowy malware uruchamiany przy instalacji zależności, co ograniczało szansę na szybką detekcję i zmniejszało liczbę sygnałów ostrzegawczych.
Mechanizm aktywacji był związany z użyciem funkcji SDK odpowiedzialnych za obsługę materiału kryptograficznego. Po wywołaniu odpowiednich metod malware przechwytywał pełną frazę seed oraz klucz prywatny, a następnie kodował dane w Base64 i przygotowywał je do eksfiltracji.
- generowanie nowych portfeli,
- import istniejących portfeli,
- obsługa prywatnych kluczy,
- przetwarzanie fraz mnemonic seed.
Badacze wskazali, że próbka nie wysyłała sekretów natychmiast. Zamiast tego kolejkowała wiele wpisów przez krótki czas, a następnie pakowała je do pojedynczego żądania HTTP POST. Dodatkowym elementem maskującym było wykorzystanie punktu infrastruktury powiązanego z projektem, aby ruch wyglądał na uzasadniony operacyjnie.
Na uwagę zasługuje również to, że atak nie ograniczał się do jednego pakietu. Złośliwa wersja została przypięta także do 17 innych paczek związanych z projektem. Oznacza to, że ryzyko objęło nie tylko bezpośrednich użytkowników @injectivelabs/sdk-ts, ale również podmioty korzystające z zależności pośrednich.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem kompromitacji jest możliwość przejęcia środków kryptowalutowych. Posiadanie frazy seed lub klucza prywatnego pozwala atakującemu odtworzyć portfel na własnym urządzeniu i uzyskać pełną kontrolę nad aktywami. W środowiskach produkcyjnych może to oznaczać natychmiastową utratę środków, a także kompromitację kont usługowych lub botów transakcyjnych.
Ryzyko obejmuje również szereg konsekwencji operacyjnych i organizacyjnych.
- kompromitację stacji roboczych deweloperów,
- wyciek sekretów przechowywanych w środowiskach CI/CD,
- utratę integralności aplikacji korzystających z zainfekowanych zależności,
- dalsze rozprzestrzenienie incydentu przez zależności transytywne,
- szkody reputacyjne i potencjalne konsekwencje prawne.
Szczególnym problemem jest fakt, że złośliwe działanie było wyzwalane dopiero podczas obsługi materiału kryptograficznego. Organizacje monitorujące wyłącznie etap instalacji pakietów mogły nie zauważyć kompromitacji we właściwym momencie.
Rekomendacje
Zespoły, które używały pakietów Injective SDK w okresie objętym incydentem, powinny potraktować sprawę jako potencjalne naruszenie bezpieczeństwa wysokiego ryzyka. Konieczne jest zarówno zbadanie śladu kompromitacji, jak i wdrożenie działań ograniczających skutki.
- Natychmiast zidentyfikować wszystkie systemy, które pobrały lub uruchamiały wersję
1.20.21oraz powiązane pakiety zależne. - Zweryfikować lockfile, artefakty buildów, cache menedżerów pakietów i pipeline’y CI/CD.
- Przeprowadzić rotację wszystkich prywatnych kluczy, seed phrase, tokenów API i innych sekretów obecnych w tych środowiskach.
- Przenieść środki kryptowalutowe do nowych portfeli utworzonych w zaufanym, odseparowanym środowisku.
- Przejrzeć logi sieciowe pod kątem nietypowych żądań HTTP związanych z procesami aplikacji lub buildów.
- Wdrożyć pinowanie wersji, formalne zatwierdzanie zależności oraz skanowanie pakietów pod kątem anomalii behawioralnych.
- Monitorować zależności transytywne i korzystać z narzędzi do analizy ryzyka supply chain.
- Ograniczyć uprawnienia kont publikujących pakiety oraz wymusić silne MFA dla maintainerów.
W dłuższej perspektywie warto wdrożyć podpisywanie artefaktów, kontrolę pochodzenia buildów, ochronę kont maintainerów oraz detekcję zmian w krytycznych funkcjach związanych z kryptografią i zarządzaniem sekretami.
Podsumowanie
Incydent z @injectivelabs/sdk-ts pokazuje, że ataki supply chain na ekosystem npm są coraz częściej ukierunkowane na dane o bardzo wysokiej wartości, takie jak klucze prywatne i frazy seed portfeli kryptowalutowych. Złośliwa modyfikacja nie była prymitywna ani głośna, lecz aktywowała się dopiero w odpowiednim kontekście biznesowym, co znacząco zwiększało jej skuteczność.
Dla organizacji rozwijających aplikacje Web3 to wyraźny sygnał, że ochrona łańcucha dostaw oprogramowania nie może kończyć się na etapie instalacji zależności. Równie ważna jest analiza rzeczywistego zachowania bibliotek w czasie wykonywania oraz kontrola dostępu do kont publikujących krytyczne pakiety.