Wyciek kluczy Stripe naraził na ryzyko dane 688 363 klientów

Zdarzenie wiązało się także z bezpośrednim ryzykiem dla operacji płatniczych. 519 z 659 kont miało podobno możliwość zarówno przyjmowania płatności, jak i realizowania wypłat. Jeśli klucze pozostały aktywne, takie uprawnienia mogły ułatwić oszustwa płatnicze lub próby przekierowania środków.

Najwięcej dotkniętych problemem merchantów miało znajdować się w Stanach Zjednoczonych — 212 kont, następnie w Wielkiej Brytanii — 81 i Francji — 57.

Kto opublikował dane?

Materiały przypisano aktorowi znanemu jako „Satanic”, który miał opublikować je 18 sierpnia na forum pwnforums. Zbiór był oferowany do pobrania, a nie sprzedawany.

Liczby podawane dla pierwszej publikacji nie pokrywają się jednak dokładnie z później zweryfikowanym zbiorem. Hudson Rock opisał powiązaną analizę obejmującą 669 folderów dostawców, 1033 przejęte klucze API oraz archiwum deklarowane jako mające 33 GB.

Różnice mogą wynikać z kolejnych etapów publikacji, odmiennych metod liczenia albo innych kryteriów weryfikacji. Nie należy traktować ich jako jednego, ostatecznie potwierdzonego bilansu. Niezweryfikowane pozostaje również twierdzenie, że aktor miał około 20 tys. dodatkowych kluczy API Stripe, które zamierzał opublikować w przyszłości.

Hudson Rock odnotował także rozbieżność między rozmiarem podanym na forum a plikiem dostępnym do pobrania: forum reklamowało 33 GB, podczas gdy archiwum miało około 2,37 GB. Jest to zgodne z twierdzeniem, że poza pierwszym pobranym pakietem mogły istnieć kolejne materiały, ale samo w sobie tego nie potwierdza.

Dlaczego nie wygląda to na włamanie do Stripe?

Dostępne informacje wskazują, że napastnicy mogli wykorzystać skradzione sekretne klucze merchantów do wykonywania zwykłych żądań API Stripe. W takim scenariuszu dane były pobierane za pomocą poświadczeń mających dostęp do konkretnych kont, a nie w wyniku przełamania zabezpieczeń centralnych systemów Stripe. Badacze nie znaleźli dowodów na naruszenie podstawowej infrastruktury platformy.

Możliwe źródła wycieku kluczy obejmują:

• logi infostealerów, czyli złośliwego oprogramowania kradnącego dane,
• commity w publicznych repozytoriach,
• ujawnione pliki .env,
• niezabezpieczone kopie zapasowe,
• logi systemów CI/CD,
• nieprawidłowo skonfigurowane serwery WWW,
• automatyczne skanowanie zmiennych środowiskowych i innych słabo chronionych sekretów.

W momencie publikacji raportów badacze nie powiązali infekcji infostealerem z konkretnymi domenami merchantów wymienionymi w zbiorze. Dokładne pierwotne źródło kluczy pozostawało więc nierozstrzygnięte.

To rozróżnienie ma znaczenie dla reagowania na incydent. Kompromitacja infrastruktury Stripe oznaczałaby zdarzenie dotyczące całej platformy. Wyciek kluczy merchantów wskazuje natomiast na wiele oddzielnych sekretów, które wyciekły, a następnie zostały wykorzystane do atakowania kont, do których dawały dostęp.

Co mógł zrobić jeden aktywny klucz?

Badacze poinformowali, że jeden aktywny klucz wystarczył do uzyskania dostępu do listy klientów merchanta, utworzenia fałszywego Payment Linku oraz wykonania testowej opłaty — wszystko w ciągu 17 godzin.

Demonstracja pokazuje, dlaczego aktywny, szeroko uprzywilejowany klucz sekretny powinien być traktowany jak natychmiastowy incydent bezpieczeństwa konta. Napastnik nie musi włamywać się do Stripe, jeśli klucz już autoryzuje dostęp do danych klientów i funkcji płatniczych.

Potencjalne skutki wykraczają poza samo ujawnienie danych. Zależnie od uprawnień klucza i konfiguracji konta nieuprawniony użytkownik mógł uzyskać dostęp do historii płatności albo wykonywać działania związane z linkami płatniczymi, obciążeniami, zwrotami i wypłatami. Zbiór obejmował kilka takich kategorii transakcji, ale dostępne raporty nie potwierdzają, że na każdym wymienionym koncie doszło do oszustwa.

Dlaczego skanowanie sekretów w GitHubie nie wystarcza?

Incydent pokazuje, że samo skanowanie publicznych repozytoriów nie zapewnia wystarczającej ochrony danych uwierzytelniających używanych do płatności. Badacze wskazali na możliwe miejsca wycieku, których standardowe skanowanie repozytorium może nie obejmować: logi GitHub Actions, historyczne artefakty, publiczne pliki .env, kopie zapasowe i nieprawidłowo skonfigurowane serwery.

W odrębnym raporcie podano, że badacze znaleźli ponad 50 tys. sekretów Stripe w publicznym kodzie, logach GitHub Actions i źle skonfigurowanych serwerach. Ta liczba opisuje szerszy problem wykrywania ujawnionych kluczy, a nie klucze potwierdzone jako część zbioru opublikowanego 18 sierpnia.

Dla firm praktyczny wniosek jest prosty: usunięcie sekretu z aktualnej wersji repozytorium nie sprawia, że staje się on bezpieczny. Kopie mogą nadal znajdować się w historii commitów, logach kompilacji, artefaktach, backupach lub wdrożonych systemach. Klucz, który mógł zostać ujawniony, trzeba unieważnić albo wymienić, a następnie zbadać także systemy powiązane.

Co powinni teraz zrobić merchantci Stripe?

Firmy, które mogły ujawnić swoje poświadczenia, powinny w pierwszej kolejności ograniczyć skutki incydentu:

1. Natychmiast unieważnić lub wymienić potencjalnie ujawnione aktywne klucze sekretne. Samo usunięcie pliku lub wpisu z repozytorium nie dezaktywuje klucza.
2. Przeanalizować aktywność API i konta Stripe pod kątem nieznanych adresów IP, dostępu do list klientów, eksportów danych, tworzenia Payment Linków, prób płatności, zwrotów i wypłat.
3. Sprawdzić dane rachunku bankowego używanego do wypłat oraz ostatnie zmiany ustawień wypłat. W razie potrzeby zwiększyć monitoring lub czasowo wprowadzić dodatkowe kontrole przelewów.
4. Zastąpić szeroko uprzywilejowane klucze kluczami ograniczonymi, które pozwalają wyłącznie na operacje potrzebne danej aplikacji.
5. Przenieść sekrety do zarządzanego magazynu sekretów i usunąć je z kodu źródłowego, plików środowiskowych, logów oraz niezabezpieczonych kopii zapasowych.
6. Przeszukać historyczne repozytoria, logi CI/CD, artefakty, serwery i backupy, a nie tylko najnowszy publiczny kod.

Obecne dowody wskazują na poważne ujawnienie poświadczeń merchantów, stwarzające istotne ryzyko dla danych klientów i operacji płatniczych. Nie uzasadniają jednak stwierdzenia, że doszło do włamania do centralnej infrastruktury Stripe. Z powodu rozbieżnych danych raportowane liczby należy traktować jako szacunki dotyczące konkretnych zbiorów, a nie jeden definitywny wykaz.