Złośliwa paczka w NuGet podszywała się pod Stripe i kradła klucze API

Badacze z ReversingLabs odkryli złośliwą paczkę w NuGet (menedżer pakietów do .NET), która podszywa się pod Stripe[.]net – oryginalny pakiet, który został pobrany ponad 70 milionów razy.

TLDR:

• Badacze z ReversingLabs odkryli złośliwy pakiet w repozytorium NuGet.
• Paczka StripeApi[.]Net podszywała się pod oficjalną bibliotekę Stripe[.]net używaną do integracji z bramką płatności Stripe.
• Złośliwy kod wykradał token API Stripe podczas inicjalizacji klienta i wysyłał go do bazy w Supabase.
• Atakujący sztucznie zawyżali liczby pobrań, aby zwiększyć wiarygodność pakietu.
• Paczka została szybko usunięta z NuGet, a badacze nie znaleźli w bazie dowodów na realnie wykradzione klucze.

Stripe to popularna bramka obsługująca wiele metod płatności, takich jak karty kredytowe czy subskrypcje. Ułatwia wdrażanie monetyzacji w wielu usługach/aplikacjach.

Firma dostarcza oficjalny pakiet NuGet (Stripe.net), który integruje Stripe z aplikacjami napisanymi w .NET (Microsoft). Zawiera on bibliotekę, dzięki której programiści nie muszą sami obsługiwać całej komunikacji z API – zamiast tego mogą skorzystać z gotowych już klas i metod.

Atakujący opublikowali inny pakiet, o łudząco podobnej nazwie (typosquatting) – StripeApi[.]Net – zapewne licząc na omyłkowe zainstalowanie go przez programistów szukających oficjalnej paczki.

Złośliwy pakiet został skonfigurowany tak, aby jak najbardziej przypominał oficjalną paczkę. Używa tej samej ikony i posiada niemal identyczny plik readme. Jedyne czym się różni, to myślnik zamiast kropki (Stripe-net zamiast Stripe[.]net).

Linki w opisie prowadzą do oficjalnych stron Stripe, a przypisane paczce tagi są identyczne z tymi używanymi w oficjalnym pakiecie. Choć nazwa twórcy fałszywej zależności – StripePayments – również podszywa się pod Stripe, atakujący nie dodali zdjęcia profilowego – korzystają z domyślnego awataru.

Złośliwy pakiet NuGet zawiera biblioteki DLL działające de facto tak samo, jak oryginalna biblioteka. Modyfikuje jednak kluczowe metody, dzięki czemu przekazuje część danych do atakujących.

Tekst zaznaczony na czerwono to kod dodany w złośliwym pakiecie. W momencie inicjalizacji klasy StripeClient wykradany jest token API użytkownika. Taka inicjalizacja jest niezbędna do integracji aplikacji ze Stripe, więc musi nastąpić, gdy programista chce użyć tej biblioteki.

Token API jest następnie przekazywany do funkcji AddApiKeyAsync, która wysyła token wraz z identyfikatorem maszyny (generowanym na podstawie nazwy komputera) do Supabase.

Supabase to platforma typu BaaS (Backend as a Service), która oferuje API do tworzenia aplikacji – wraz z obsługą uwierzytelniania, bazy danych i innych usług. Całość działa w domenie supabase[.]co, a więc domyślnie nie znajduje się na listach blokad (takich jak np. lista CERT Polska). Oczywiście projekt ma unikalną subdomenę, którą można indywidualnie blokować, ale sama komunikacja z Supabase zauważona np. w logach, na pierwszy rzut oka nie będzie wzbudzać podejrzeń.

W efekcie token API użytkownika trafia do atakujących. Pozwala on w ramach danego konta Stripe uzyskać dostęp do informacji m.in. o płatnościach, subskrypcjach, danych klientów oraz zarządzać nimi. Wyciek klucza w fazie developmentu aplikacji nie powinien być dużym zagrożeniem (o ile używamy osobnych – testowych – poświadczeń). Problem pojawiłby się, gdy aplikacja ze złośliwym pakietem zostaje wdrożona na serwerze i zaczyna korzystać z produkcyjnych poświadczeń.

Badacze ustalili również, że fałszywa paczka ma sztucznie zawyżone liczby pobrań – miała być pobierana ponad 180 tysięcy razy (jest to suma pobrań wszystkich 506 wersji). Pierwsza wersja została jednak opublikowana w połowie lutego, a natychmiast po publikacji nastąpił strumień aktualizacji i pobrań.

Badacze z ReversingLabs znaleźli i zgłosili pakiet stosunkowo szybko po jego opublikowaniu, a zespół NuGet usunął go wkrótce po otrzymaniu zgłoszenia. Krótki czas “życia” znacznie zmniejsza potencjalną skalę działalności atakujących.

Atakujący niewystarczająco skonfigurowali ograniczenia swojego klucza API Supabase, przez co badaczom udało się uzyskać dostęp do bazy danych wykorzystywanej przez złośliwą paczkę. Nie znaleźli tam żadnych wyeksfiltrowanych tokenów, a jedynie wpis testowy. Sugeruje to, że albo nie udało się wykraść żadnego klucza, albo ewentualne poświadczenia zostały usunięte.

Programiści często wykorzystują różne zewnętrzne paczki i biblioteki. Przyspieszają one tworzenie oprogramowania i zapewniają wygodniejszy dostęp do funkcjonalności oraz zewnętrznych narzędzi. Taka wygoda oznacza jednak kolejne ogniwa w łańcuchu dostaw, który nierzadko staje się celem atakujących.

W tym przypadku fakt skorzystania ze złośliwej biblioteki mógł pozostać niezauważony – działały w niej takie same funkcje i metody, jak w oryginalnej paczce. Klucz API wykradany był w tle i bez żadnego zauważalnego sygnału dla użytkownika.

Atakujący zadbali o to, aby ich pakiet wyglądał na oryginalny i zawyżyli liczbę pobrań, aby użytkownik nawet widząc go na stronie NuGet nie nabrał żadnych podejrzeń. Jego zainstalowanie możliwe było nie tylko przez literówkę w treści komendy – fałszywą paczkę można było też znaleźć w repozytorium nie wiedząc, czym naprawdę jest.

Nie możemy nie wspomnieć też o atakach typu slopsquatting. Wykorzystują one skłonność dużych modeli językowych do halucynacji. Kiedy programiści generują kod przy pomocy LLM, modele te czasami generują nazwy paczek, które choć brzmią podobnie, to różnią się od oryginalnych. 

Użytkownik je instaluje, nie spodziewając się zagrożenia, czym ryzykuje pobranie złośliwego oprogramowania na swoje urządzenie. Ataki w łańcuchu dostaw dotyczą też oryginalnych paczek, które mogą zostać przejęte i w ramach wdrożonej aktualizacji rozpowszechniać złośliwy kod.

Programiści powinni być wyczuleni na fakt, że instalowane paczki również stanowią wektor ataku. Warto w ramach code review sprawdzać także pliki zawierające listy pakietów (*.csproj, package.json, composer.json itp.) – dotyczy to także kodu generowanego przez LLM.

Równie ważne będzie też zadbanie, by do testów / developmentu nigdy nie używać produkcyjnych poświadczeń, tokenów i kluczy API. Dobrą praktyką jest ograniczanie ich do konkretnych adresów IP (oraz sensowne limitowanie uprawnień / dostępów), co może złagodzić skutki potencjalnego wycieku.

IOC

Nazwa paczki: StripeApi.Net (Stripe-net)

Wersja: 50.4.1

SHA1: 050bf5d4cf8fb4964e0e67b4cb46dacf89e7a615

Źródło: reversinglabs.com

~Tymoteusz Jóźwiak