Aktualizacja: 10 kwietnia 2026
Czym jest atak typosquattingowy na rejestr pakietów? To technika, w której atakujący publikuje pakiet o nazwie łudząco podobnej do popularnej, zaufanej biblioteki – licząc na to, że deweloper popełni literówkę lub nie sprawdzi nazwy wystarczająco dokładnie przed instalacją. W lutym 2026 r. zespół badaczy ReversingLabs wykrył na platformie NuGet pakiet o nazwie StripeApi.Net, który podszywał się pod oficjalną bibliotekę Stripe.net (ponad 74 mln pobrań). Złośliwy kod wstrzyknięty w metodę inicjalizacji przechwytywał klucze API Stripe i eksfiltrował je do zewnętrznego serwera – bez żadnego widocznego błędu w działaniu aplikacji.
Atak StripeApi.Net na NuGet – w skrócie:
- Złośliwy pakiet StripeApi.Net opublikowano na NuGet ok. 16 lutego 2026 r. jako podróbkę oficjalnego Stripe.net
- Atak wykorzystał typosquatting – nazwa różni się od oryginału jednym słowem i separatorem (kropka vs myślnik w środku nazwy)
- Złośliwy kod wstrzyknięto wyłącznie w metodę inicjalizacji klasy
StripeClient– obowiązkową przy każdym użyciu biblioteki - Skradziony klucz API był eksfiltrowany przez HTTPS do platformy Supabase wraz z identyfikatorem maszyny dewelopera
- Pakiet miał sztucznie zawyżone liczniki: ponad 180 000 pobrań rozłożonych na 506 wersji, by wyglądać jak dojrzała biblioteka
- Żadne rzeczywiste klucze API nie zostały skradzione – ReversingLabs wykrył i zgłosił pakiet do NuGet zanim doszło do realnych ofiar
- To drugi atak na NuGet w ciągu 3 miesięcy – grudniowa kampania (2025) celowała w pakiety krypto: Coinbase, Binance, Solana
Czym jest typosquatting i dlaczego jest tak skuteczny na platformach pakietów?
Typosquatting to rejestracja nazwy domeny lub – w tym przypadku – pakietu, łudząco podobnej do popularnego oryginału. Różnica bywa minimalna: jedna litera, znak specjalny, kolejność słów. W przypadku StripeApi.Net różnicą względem oficjalnego Stripe.net jest dodatkowe słowo „Api” i separator (myślnik zamiast kropki).
Skuteczność tej techniki wynika z kilku czynników jednocześnie:
- Automatyzacja instalacji – w środowiskach CI/CD pakiety instalowane są na podstawie pliku konfiguracyjnego; jeden błąd w nazwie kopiuje się na wszystkie serwery
- Zaufanie do rejestrów – deweloperzy traktują NuGet, npm czy PyPI jako zaufane źródła; nie weryfikują każdego pakietu z osobna
- Presja czasu – deweloper szukający biblioteki do szybkiej integracji rzadko sprawdza właściciela pakietu czy historię wersji
- Sztuczne uwiarygodnienie – atakujący zawyżyli liczniki pobrań do 180 000 i stworzyli 506 wersji, by pakiet wyglądał jak dojrzały, aktywnie rozwijany projekt
Strona pakietu StripeApi.Net na NuGet była przygotowana starannie: ta sama ikona co oficjalny Stripe.net, niemal identyczny plik README (zmieniono tylko „Stripe.net” na „Stripe-net”), linki do oficjalnych repozytoriów Stripe, identyczne tagi. Jedyna wizualna różnica – brak logo Stripe przy nazwie właściciela konta „StripePayments”.
Jak technicznie działał złośliwy kod w StripeApi.Net?
To najważniejsza część dla każdego CISO i architekta bezpieczeństwa – bo pokazuje, jak precyzyjnie atakujący dobrali punkt wstrzyknięcia złośliwego kodu.
Pakiet StripeApi.Net zawierał kod niemal identyczny z oryginalną biblioteką Stripe.net – wszystkie klasy, metody, logika biznesowa skopiowane bez zmian. Modyfikacja dotyczyła wyłącznie jednej metody: inicjalizacji klasy StripeClient.
Dlaczego akurat ta metoda?
Ponieważ jest obowiązkowa. Każdy deweloper, który chce wywołać cokolwiek przez API Stripe, musi najpierw zainicjować StripeClient podając klucz API. Bez tego kroku biblioteka jest bezużyteczna. Atakujący wstrzyknęli złośliwy kod dokładnie w to miejsce – gwarantując, że klucz zostanie przechwycony przy każdym użyciu biblioteki.
Przepływ ataku krok po kroku:
- Deweloper instaluje StripeApi.Net zamiast Stripe.net – przez literówkę lub nieuwagę
- W kodzie aplikacji inicjalizuje
StripeClientz kluczem API – standardowy, obowiązkowy krok - Złośliwy kod przechwytuje klucz w momencie inicjalizacji i przekazuje go do funkcji
AddApiKeyAsync - Funkcja pakuje klucz API wraz z identyfikatorem maszyny (hash nazwy komputera) i wysyła dane przez HTTPS do instancji Supabase kontrolowanej przez atakującego
- Deweloper nie widzi żadnego błędu – aplikacja kompiluje się poprawnie, płatności są procesowane normalnie
- Klucz API trafia do bazy danych atakującego
Dlaczego to szczególnie niebezpieczne?
Aplikacja działa tak samo jak z legalnym pakietem. Testy przechodzą. Płatności są procesowane. Z perspektywy dewelopera nic nie jest zepsute. Złośliwa logika ukryta jest w jednej metodzie inicjalizacyjnej, reszta kodu jest w 100% legalna i funkcjonalna.
Co atakujący może zrobić z kluczem API Stripe?
Klucz API Stripe (tzw. „secret key”) daje dostęp do pełnego API platformy płatniczej. W zależności od uprawnień klucza atakujący może:
- Inicjować zwroty środków na kontrolowane przez siebie konta
- Pobierać dane klientów: imię, adres e-mail, ostatnie 4 cyfry karty, historia transakcji
- Tworzyć lub modyfikować subskrypcje i plany płatności
- Odczytywać dane webhook i przechwytywać powiadomienia o transakcjach
- W skrajnym przypadku – inicjować wypłaty z salda konta Stripe
Jak atakujący uwiarygodnił pakiet – i co to oznacza dla oceny ryzyka?
ReversingLabs zidentyfikował kilka technik, których atakujący użył, by pakiet wyglądał na legalny:
Zawyżone liczniki pobrań. Pakiet miał ponad 180 000 pobrań rozłożonych na 506 wersji – średnio ok. 300 pobrań na wersję. To celowe rozłożenie, by uniknąć podejrzeń: jeden pakiet z 180 000 pobraniami wyglądałby podejrzanie, bo nowe projekty nie osiągają takich liczb od razu. Wiele wersji z mniejszą liczbą pobrań każda – wygląda jak naturalny, długotrwały wzrost popularności.
Replika strony pakietu. Strona StripeApi.Net na NuGet była praktycznie kopią strony oficjalnego Stripe.net: ta sama ikona, ten sam opis, te same tagi, te same linki do dokumentacji Stripe. Atakujący nie tworzył nowej tożsamości – podrabiał istniejącą.
Nazwa właściciela „StripePayments”. To kolejny element uwiarygodnienia – deweloper widzący tę nazwę mógł pomyśleć, że to oficjalne konto Stripe.
Wniosek dla CISO: liczba pobrań i historia wersji pakietu nie są wiarygodnymi wskaźnikami bezpieczeństwa. Atakujący potrafią je sfabrykować. Jedyna wiarygodna weryfikacja to analiza kodu i kryptograficzna weryfikacja skrótu.
Jak się bronić przed atakami typosquattingowymi na NuGet i npm?
Poniżej konkretne środki techniczne i organizacyjne – nie ogólniki.
1. Software Composition Analysis (SCA) z analizą behawioralną w pipeline CI/CD
Standardowe narzędzia SCA (OWASP Dependency-Check, Snyk, Dependabot) skanują zależności pod kątem znanych CVE. Jednak złośliwy pakiet typosquattingowy nie ma CVE – bo jest nowy. Potrzebujesz narzędzi z analizą behawioralną kodu i reputacyjną pakietu, które wykrywają anomalie w kodzie (np. nieoczekiwane połączenia sieciowe w metodach inicjalizacyjnych).
2. Weryfikacja kryptograficzna skrótu pakietu
Każdy pakiet NuGet ma skrót SHA1 i SHA512. Jeśli Twój pipeline porównuje skrót instalowanego pakietu z listą zatwierdzonych skrótów – typosquatting jest wykryty natychmiast, bo skrót złośliwego pakietu nie będzie na liście. Wymaga to prowadzenia rejestru zatwierdzonych pakietów i ich wersji.
IOC dla StripeApi.Net: SHA1 050bf5d4cf8fb4964e0e67b4cb46dacf89e7a615 (wersja 50.4.1)
3. Polityka dopuszczonych pakietów (allowlist)
Zamiast blokować złe pakiety (lista zagrożeń jest nieznana z góry), zdefiniuj listę pakietów dopuszczonych w projektach produkcyjnych. Każdy nowy pakiet wymaga przeglądu i formalnego zatwierdzenia przed dodaniem do listy. To proces organizacyjny, ale jeden z najbardziej skutecznych.
4. Monitoring ruchu wychodzącego z aplikacji (egress)
Złośliwy kod w StripeApi.Net eksfiltrował dane do Supabase przez HTTPS na porcie 443. Standardowy firewall tego nie zatrzyma – HTTPS wygląda jak normalny ruch. Potrzebujesz analizy SNI (Server Name Indication) lub proxy TLS, które loguje połączenia wychodzące z serwerów aplikacyjnych i alertuje przy połączeniach z nieznanymi domenami.
5. Izolacja uprawnień kluczy API w środowiskach deweloperskich
Klucze API używane lokalnie przez deweloperów powinny mieć ograniczone uprawnienia – np. wyłącznie tryb testowy Stripe, bez dostępu do danych produkcyjnych klientów. W przypadku ataku na środowisko dewelopera skradziony klucz testowy nie daje dostępu do produkcji.
6. Weryfikacja właściciela pakietu przed instalacją
Przed zainstalowaniem pakietu sprawdź: kto jest jego właścicielem na NuGet? Czy właściciel ma logo organizacji? Czy profil istnieje od dawna? Czy inne pakiety tego właściciela są znane? Dla StripeApi.Net właściciel „StripePayments” miał domyślne zdjęcie profilowe NuGet – zamiast logo Stripe.
Jakie są implikacje regulacyjne dla firm używających zewnętrznych bibliotek w środowiskach płatniczych?
Incydent StripeApi.Net to nie tylko problem bezpieczeństwa – to potencjalny problem compliance dla każdej firmy, która przetwarza płatności kartą.
PCI DSS 4.0 – Wymaganie 6: bezpieczne systemy i oprogramowanie
Wymaganie 6.3.3 nakazuje ochronę wszystkich komponentów oprogramowania przed nowymi podatnościami. Wymaganie 6.2.4 zobowiązuje do przeglądów kodu. Wymaganie 12.8 nakłada obowiązek zarządzania ryzykiem dostawców trzecich – a pakiet NuGet to dostawca trzeci w rozumieniu PCI DSS. Jeśli Twój pipeline CI/CD instaluje pakiety bez weryfikacji integralności i bez przeglądu reputacji, możesz nie spełniać tych wymagań.
DORA – Article 28: ryzyko ICT podmiotów trzecich
DORA, obowiązująca instytucje finansowe w UE od stycznia 2025 r., wymaga zarządzania ryzykiem podmiotów trzecich ICT. Biblioteka open source używana w aplikacji przetwarzającej płatności jest dostawcą ICT w rozumieniu DORA. Atak StripeApi.Net to dokładnie scenariusz ryzyka, który DORA każe identyfikować i mitygować.
NIS2 – Article 21: bezpieczeństwo łańcucha dostaw
NIS2 wymaga od podmiotów kluczowych wdrożenia środków zarządzania ryzykiem cyberbezpieczeństwa obejmujących bezpieczeństwo łańcucha dostaw. Obejmuje to weryfikację zależności oprogramowania używanego w systemach operacyjnych.
| Regulacja | Wymaganie | Co sprawdzić |
|---|---|---|
| PCI DSS 4.0 Req. 6.3.3 | Ochrona komponentów przed podatnościami | Czy pipeline weryfikuje skróty pakietów? |
| PCI DSS 4.0 Req. 6.2.4 | Przegląd kodu pod kątem podatności | Czy SCA obejmuje analizę behawioralną? |
| PCI DSS 4.0 Req. 12.8 | Zarządzanie ryzykiem dostawców | Czy pakiety open source są w rejestrze dostawców? |
| DORA Art. 28 | Ryzyko ICT podmiotów trzecich | Czy biblioteki w środowiskach płatniczych mają ocenę ryzyka? |
| NIS2 Art. 21 | Bezpieczeństwo łańcucha dostaw | Czy są udokumentowane procesy weryfikacji zależności? |
FAQ
Czym różni się StripeApi.Net od oficjalnego Stripe.net?
Oficjalny pakiet to Stripe.net (kropka jako separator, bez słowa „Api”) – ponad 74 mln pobrań, właściciel: Stripe Inc. z oficjalnym logo. Złośliwy pakiet to StripeApi.Net (dodane słowo „Api”, wielkie N w „.Net”) – właściciel „StripePayments” bez logo firmowego. Różnica jest minimalna i łatwa do przeoczenia przy szybkiej instalacji.
Czy oficjalny pakiet Stripe.net został skompromitowany?
Nie. Oficjalny Stripe.net nie był atakowany ani modyfikowany. Atakujący stworzyli osobny pakiet z podobną nazwą, zamiast próbować przejąć kontrolę nad oficjalną biblioteką. To celowy wybór – atak na popularny pakiet zarządzany przez dużą firmę jest znacznie trudniejszy.
Czy jakiekolwiek klucze API zostały faktycznie skradzione w tym ataku?
Według analizy ReversingLabs – nie. Baza danych Supabase kontrolowana przez atakującego zawierała wyłącznie testowy wpis. Pakiet został wykryty i usunięty z NuGet stosunkowo szybko po publikacji – zanim trafił do produkcyjnych aplikacji realnych użytkowników.
Jak sprawdzić, czy moja aplikacja .NET używa złośliwego pakietu?
Sprawdź plik packages.config lub sekcje <PackageReference> w plikach .csproj projektu. Szukaj wpisu o nazwie StripeApi.Net (wielkie N, słowo „Api” w środku). Jeśli znajdziesz – usuń pakiet natychmiast, unieważnij wszystkie klucze API Stripe używane przez aplikację i wygeneruj nowe w panelu Stripe Dashboard. IOC do dodania do systemów monitoringu: SHA1 050bf5d4cf8fb4964e0e67b4cb46dacf89e7a615.
Czy podobne ataki zdarzają się na innych platformach poza NuGet?
Tak – regularnie. Analogiczne kampanie są dokumentowane na npm (JavaScript/Node.js), PyPI (Python) i RubyGems (Ruby). W grudniu 2025 r. ReversingLabs ujawnił podobną kampanię typosquattingową na NuGet celującą w pakiety krypto: Coinbase, Binance, Solana i Nethereum. Ataki supply chain przez rejestry pakietów open source to stały, rosnący trend.
Jakie narzędzia pomagają wykryć typosquatting w zależnościach .NET?
Narzędzia z analizą behawioralną i reputacyjną – jak Spectra Assure (ReversingLabs, który wykrył ten pakiet), Socket.dev lub rl-scanner. Standardowe skanery CVE (Dependabot, Snyk w podstawowej konfiguracji) nie wykryją nowego złośliwego pakietu, który nie ma jeszcze przypisanego CVE. Kluczowa jest analiza kodu pakietu, nie tylko jego metadanych.
Bezpieczeństwo łańcucha dostaw oprogramowania – bezpłatna konsultacja
Patronusec wspiera instytucje finansowe, fintechy i firmy e-commerce w analizie ryzyka supply chain w kontekście PCI DSS 4.0, DORA i NIS2 – w tym w ocenie dojrzałości pipeline CI/CD pod kątem weryfikacji zależności oprogramowania. Umów krótką, niezobowiązującą rozmowę z naszym zespołem.
