Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystemy open source, takie jak npm i PyPI, są dziś jednym z fundamentów nowoczesnego procesu tworzenia oprogramowania. Jednocześnie publiczne rejestry pakietów pozostają atrakcyjnym celem dla cyberprzestępców, którzy publikują biblioteki podszywające się pod legalne komponenty, aby infekować środowiska programistyczne i przechwytywać wrażliwe dane.
Najnowsza kampania pokazuje, że atakujący wykorzystują rozpoznawalne marki z sektora płatności, takie jak Paysafe, Skrill i Neteller, aby skłonić deweloperów do instalacji złośliwych SDK. Tego typu operacje wpisują się w szerszy trend ataków na łańcuch dostaw oprogramowania, w których zaufanie do pozornie wiarygodnej zależności staje się głównym wektorem kompromitacji.
W skrócie
- Wykryto co najmniej 17 złośliwych pakietów opublikowanych w npm i PyPI.
- Pakiety podszywały się pod biblioteki integracyjne dla usług płatniczych i portfeli cyfrowych.
- Ich celem była kradzież kluczy API, tokenów dostępu, danych środowiskowych oraz poświadczeń developerskich.
- Kampania była wymierzona przede wszystkim w deweloperów i organizacje integrujące płatności online.
- Warianty PyPI działały bardziej agresywnie niż odpowiedniki w npm, ponieważ aktywowały eksfiltrację automatycznie.
Kontekst / historia
Ataki na software supply chain nie są nowym zjawiskiem, ale ich skuteczność rośnie wraz z automatyzacją pipeline’ów CI/CD i powszechnym wykorzystywaniem zewnętrznych bibliotek. Publiczne rejestry pakietów od lat są wykorzystywane do publikowania komponentów o nazwach sugerujących związek z popularnymi frameworkami, usługami chmurowymi lub znanymi dostawcami technologii.
W tym przypadku szczególnie istotny był dobór nazw pakietów. Atakujący odwołali się do marek obecnych w środowiskach e-commerce, fintech, zakładów online, platform tradingowych i giełd kryptowalut. Taki zabieg zwiększa prawdopodobieństwo, że biblioteka zostanie uznana za autentyczną, zwłaszcza podczas szybkiej implementacji integracji płatniczej pod presją czasu.
Analiza techniczna
Zidentyfikowane pakiety imitowały legalne SDK dla Paysafe, Skrill i Neteller, zachowując pozory poprawnego działania interfejsów programistycznych. Z punktu widzenia dewelopera mogły wyglądać jak zwykłe biblioteki integracyjne, jednak zamiast realizować prawidłową komunikację z usługami backendowymi zwracały fałszywe odpowiedzi sukcesu lub uruchamiały złośliwą logikę.
Kampania objęła 13 pakietów opublikowanych w npm oraz 4 w PyPI. Warianty npm pojawiały się w kilku wersjach, od 1.0.0 do 1.0.3, natomiast pakiety w PyPI zostały udostępnione jako wersja 1.0.0. Taki model publikacji mógł zwiększać wiarygodność projektu i utrudniać szybką identyfikację zagrożenia.
Główną funkcją złośliwego kodu była eksfiltracja danych uwierzytelniających i sekretów ze środowiska uruchomieniowego. Malware wyszukiwał między innymi:
- klucze API powiązane z usługami płatniczymi,
- klucze dostępowe do AWS,
- tokeny GitHub,
- tokeny npm,
- nazwę hosta i nazwę użytkownika,
- metadane związane z użyciem API.
Istotna była różnica w zachowaniu między pakietami npm i PyPI. Warianty npm aktywowały mechanizm eksfiltracji dopiero w momencie użycia fałszywego SDK i próbowały kraść dane tylko wtedy, gdy wykryły w środowisku klucz API powiązany z Paysafe. Z kolei pakiety z PyPI uruchamiały procedurę kradzieży automatycznie podczas inicjalizacji i nie wymagały obecności konkretnego klucza, co czyniło je bardziej agresywnymi oraz potencjalnie skuteczniejszymi.
Badacze zaobserwowali także proste mechanizmy utrudniające analizę. Złośliwy kod mógł przerywać działanie po wykryciu cech typowych dla środowisk analitycznych lub sandboxów, takich jak niewielka liczba rdzeni CPU albo nazwa hosta czy użytkownika sugerująca maszynę wirtualną. Choć nie są to zaawansowane techniki antyanalityczne, mogą ograniczać skuteczność części automatycznych systemów detekcyjnych.
Operacyjnie istotne jest również to, że kampania objęła dwa różne ekosystemy pakietów. Taka taktyka zwiększa zasięg ataku i utrudnia obronę organizacjom, które monitorują tylko jeden rejestr albo tylko jeden stos technologiczny.
Konsekwencje / ryzyko
Najpoważniejszym zagrożeniem pozostaje kompromitacja sekretów wykorzystywanych w procesie wytwarzania i utrzymania aplikacji. Utrata kluczy API, tokenów repozytoryjnych i poświadczeń chmurowych może prowadzić do dalszej eskalacji incydentu oraz rozszerzenia zasięgu ataku.
- przejęcie repozytoriów kodu,
- publikacja kolejnych złośliwych artefaktów,
- nieautoryzowany dostęp do zasobów chmurowych,
- nadużycia finansowe w systemach płatniczych,
- kompromitacja pipeline’ów CI/CD,
- wtórne ataki na klientów końcowych.
Dla organizacji z sektorów fintech, e-commerce i SaaS ryzyko ma nie tylko wymiar techniczny, ale również regulacyjny oraz reputacyjny. Jeżeli zainfekowane środowisko zawierało dostęp do systemów testowych lub produkcyjnych, incydent może wymagać rotacji kluczy, przeglądu logów, audytu zależności i formalnej oceny wpływu na bezpieczeństwo danych.
Atak stanowi również przykład zagrożeń związanych z typosquattingiem i podszywaniem się pod dostawców usług finansowych. W praktyce oznacza to, że sama walidacja funkcjonalna biblioteki nie wystarcza, jeśli zespół nie weryfikuje pochodzenia pakietu, historii publikacji i reputacji maintainera.
Rekomendacje
Organizacje powinny potraktować ten incydent jako sygnał do wzmocnienia ochrony łańcucha dostaw oprogramowania. Najważniejsze działania obejmują:
- natychmiastowe sprawdzenie, czy podejrzane pakiety zostały pobrane, zainstalowane lub uruchomione w środowiskach developerskich, testowych albo produkcyjnych,
- rotację wszystkich sekretów obecnych na maszynach, które importowały lub wykonywały złośliwe biblioteki,
- przegląd drzewa zależności pod kątem bezpośrednich i pośrednich odwołań do wskazanych pakietów,
- analizę logów CI/CD, build serverów i stacji roboczych pod kątem nietypowych prób odczytu zmiennych środowiskowych i podejrzanego ruchu wychodzącego,
- wdrożenie polityk allowlist dla zależności oraz korzystanie z prywatnych proxy rejestrów pakietów,
- stosowanie narzędzi do skanowania zależności i wykrywania ryzykownych pakietów jeszcze przed ich wdrożeniem,
- weryfikację autentyczności bibliotek na podstawie dokumentacji producenta, historii wersji oraz wiarygodności maintainerów,
- ograniczanie uprawnień sekretów zgodnie z zasadą najmniejszych uprawnień,
- segmentację środowisk developerskich i ograniczenie dostępu stacji roboczych do zasobów produkcyjnych,
- regularne szkolenie zespołów programistycznych w zakresie zagrożeń związanych z publicznymi rejestrami pakietów.
Podsumowanie
Fałszywe pakiety podszywające się pod SDK Paysafe, Skrill i Neteller potwierdzają, że publiczne rejestry zależności pozostają jednym z kluczowych wektorów ataku na łańcuch dostaw oprogramowania. Kampania była wyraźnie ukierunkowana na deweloperów i koncentrowała się na przechwytywaniu wartościowych sekretów, które mogą otworzyć drogę do dalszej kompromitacji środowisk chmurowych, repozytoriów kodu i systemów płatniczych.
Z perspektywy zespołów bezpieczeństwa oraz DevSecOps najważniejszy wniosek jest jednoznaczny: kontrola zależności, monitoring sekretów i rygorystyczna walidacja pakietów muszą być traktowane jako podstawowy element ochrony środowiska developerskiego.
Źródła
- BleepingComputer — Fake Paysafe, Skrill SDKs on NPM and PyPi steal credentials — https://www.bleepingcomputer.com/news/security/fake-paysafe-skrill-sdks-on-npm-and-pypi-steal-credentials/