Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla firm rozwijających aplikacje i usługi cyfrowe. Najnowsza kampania pokazuje, że cyberprzestępcy coraz skuteczniej wykorzystują publiczne rejestry pakietów do podszywania się pod wiarygodne biblioteki, które na pierwszy rzut oka wyglądają jak legalne narzędzia integracyjne.
W tym przypadku wykryto złośliwe pakiety opublikowane w npm i PyPI, udające SDK związane z usługami płatniczymi Paysafe, Skrill i Neteller. Ich rzeczywistym celem była kradzież sekretów środowiskowych, tokenów i kluczy API z maszyn deweloperskich oraz środowisk CI/CD.
W skrócie
W publicznych repozytoriach odnaleziono co najmniej 17 złośliwych pakietów imitujących legalne biblioteki płatnicze. Kampania obejmowała zarówno ekosystem JavaScript, jak i Python, co zwiększało szanse na dotarcie do zespołów tworzących aplikacje webowe, backendy oraz platformy e-commerce.
- Pakiety udawały działające SDK i wystawiały oczekiwane interfejsy API.
- W tle przechwytywały poświadczenia i dane środowiskowe.
- Celem były m.in. klucze API Paysafe, dane AWS, tokeny GitHub i npm.
- Fałszywe odpowiedzi sukcesu mogły opóźniać wykrycie incydentu.
Kontekst / historia
Repozytoria open source od lat pozostają atrakcyjnym celem dla napastników, ponieważ stanowią naturalny punkt wejścia do środowisk deweloperskich i procesów wydawniczych oprogramowania. Wystarczy pobranie biblioteki o wiarygodnej nazwie, aby złośliwy kod trafił do lokalnego środowiska pracy, pipeline’u testowego lub nawet produkcji.
W opisywanej kampanii wykorzystano nazwy nawiązujące do rozpoznawalnych usług płatniczych. To podejście było szczególnie niebezpieczne, ponieważ mogło zainteresować zespoły wdrażające integracje finansowe w systemach sprzedażowych, fintechowych i SaaS. Atak nie był więc przypadkowy, lecz dobrze dopasowany do realnych potrzeb programistów.
Analiza techniczna
Zidentyfikowane pakiety zostały opublikowane równolegle w npm i PyPI, co wskazuje na przemyślaną kampanię wieloekosystemową. W npm wykryto 13 pakietów oraz kilka złośliwych wersji, a w PyPI 4 pakiety zawierające pojedyncze wersje z malware.
Istotnym elementem tej operacji było to, że pakiety nie zachowywały się jak proste droppery. Zamiast natychmiast wzbudzać podejrzenia, implementowały oczekiwane funkcje i zwracały odpowiedzi sugerujące prawidłowe działanie integracji. Deweloper mógł więc uznać, że biblioteka działa poprawnie, mimo że w rzeczywistości nie komunikowała się z prawdziwym backendem usługodawcy.
Warstwa złośliwa pełniła rolę infostealera. Kod przeszukiwał środowisko uruchomieniowe i próbował pozyskać różne sekrety oraz informacje systemowe.
- klucze API Paysafe,
- klucze dostępowe AWS,
- tokeny GitHub,
- tokeny npm,
- nazwę hosta,
- nazwę użytkownika,
- informacje o użyciu API.
Warianty npm aktywowały eksfiltrację po użyciu fałszywego SDK i koncentrowały się głównie na sytuacjach, w których wykryto obecność klucza API Paysafe. Z kolei pakiety dla PyPI uruchamiały procedurę kradzieży już podczas inicjalizacji, bez konieczności znalezienia takiego klucza, co czyniło je bardziej agresywnymi.
Złośliwe biblioteki zawierały również podstawowe mechanizmy anti-analysis. Kod mógł kończyć działanie, gdy środowisko wyglądało na maszynę wirtualną, sandbox lub system badawczy, na przykład przy zbyt małej liczbie rdzeni CPU albo nazwach hosta i użytkownika sugerujących analizę bezpieczeństwa.
Konsekwencje / ryzyko
Skutki takiego incydentu mogą wykraczać daleko poza samą kradzież pojedynczych poświadczeń. Jeśli napastnik uzyska tokeny GitHub, npm lub klucze chmurowe, może wykorzystać je do dalszej kompromitacji procesów i zasobów organizacji.
- przejęcie repozytoriów kodu,
- publikacja kolejnych złośliwych pakietów,
- dostęp do zasobów chmurowych,
- manipulacja pipeline’ami CI/CD,
- wyciek danych klientów i sekretów aplikacyjnych,
- dalsze rozprzestrzenianie się ataku w łańcuchu dostaw.
Szczególnie narażone są organizacje budujące integracje płatnicze, firmy e-commerce, operatorzy usług cyfrowych oraz podmioty z sektora fintech. Dodatkowym problemem jest to, że pakiety mogły sprawiać wrażenie poprawnie działających, co zwiększało ryzyko cichego i długotrwałego wycieku danych bez widocznych objawów awarii.
Rekomendacje
Firmy, które mogły pobrać lub uruchomić wskazane pakiety, powinny traktować ten incydent jako potencjalne naruszenie bezpieczeństwa środowiska deweloperskiego. Reakcja powinna obejmować zarówno działania natychmiastowe, jak i długofalowe zmiany w polityce zarządzania zależnościami.
- Natychmiast zidentyfikować obecność podejrzanych pakietów w kodzie, lockfile’ach, obrazach kontenerów i artefaktach buildów.
- Przeprowadzić rotację wszystkich sekretów dostępnych na hostach, które importowały lub uruchamiały te biblioteki.
- Zweryfikować logi CI/CD pod kątem użycia podejrzanych zależności i zmiennych środowiskowych.
- Zablokować wskazane nazwy pakietów w proxy rejestrów i wewnętrznych politykach dopuszczania komponentów.
- Sprawdzić zależności pośrednie oraz historię publikacji pakietów pod kątem możliwego rozprzestrzenienia zagrożenia.
- Wdrożyć skanowanie ryzyka pakietów, analizę behawioralną i kontrolę zaufanych źródeł.
- Ograniczyć uprawnienia sekretów zgodnie z zasadą najmniejszych uprawnień.
- Segmentować środowiska deweloperskie i CI, aby utrudnić lateral movement po kompromitacji pojedynczego systemu.
W dłuższej perspektywie organizacje powinny rozwijać politykę bezpiecznego korzystania z open source, obejmującą zatwierdzanie nowych zależności, pinning wersji, wewnętrzne mirrorowanie rejestrów oraz ciągły monitoring anomalii w software supply chain.
Podsumowanie
Fałszywe pakiety podszywające się pod SDK Paysafe, Skrill i Neteller pokazują, że cyberprzestępcy coraz lepiej rozumieją procesy deweloperskie oraz specyfikę integracji płatniczych. Kampania została zaprojektowana tak, aby wyglądać wiarygodnie i jak najdłużej pozostać niezauważona.
Największym zagrożeniem nie była sama obecność malware, lecz możliwość przejęcia sekretów otwierających drogę do dalszej kompromitacji kodu, infrastruktury i procesów wydawniczych. To kolejny sygnał, że bezpieczeństwo łańcucha dostaw musi obejmować nie tylko własny kod, ale również każdą zależność pobieraną z publicznych repozytoriów.
Źródła
- https://www.bleepingcomputer.com/news/security/fake-paysafe-skrill-sdks-on-npm-and-pypi-steal-credentials/
- https://socket.dev/blog/fake-paysafe-skrill-neteller-sdk-packages-target-developers-across-npm-and-pypi