Wyciek tokenów OAuth: jeden dostawca, setki firm

W sierpniu 2025 roku setki firm dowiedziały się, że ich dane z Salesforce zostały wykradzione — mimo że nikt nie złamał ich haseł ani nie ominął ich MFA. Napastnicy nie musieli: zdobyli tokeny OAuth należące do popularnej integracji marketingowej (Salesloft Drift, podpiętej do Salesforce), a te tokeny były jednocześnie kluczem do danych wszystkich klientów, którzy tę integrację zainstalowali. To jeden z najważniejszych incydentów roku i modelowa lekcja o niedocenianym ryzyku: aplikacjach trzecich podpiętych do Twoich systemów.

Jak działa ten atak (i czemu jest tak skuteczny)

Gdy podłączasz zewnętrzną aplikację do Salesforce, Microsoft 365 czy Google Workspace przez „Zaloguj przez…” lub instalację integracji, wydajesz jej token OAuth — trwały poświadczyciel, który pozwala aplikacji działać w Twoim imieniu bez ponownego logowania i niezależnie od Twojego MFA. To wygodne i całkowicie standardowe. Problem pojawia się, gdy token wycieknie:

1. Napastnik kompromituje dostawcę integracji (tu: infrastrukturę powiązaną z Salesloft Drift) i wykrada bazę tokenów OAuth jego klientów.
2. Każdy taki token to gotowy dostęp do danych klienta — bez hasła, bez MFA, bez alertu o „nietypowym logowaniu”, bo z perspektywy Salesforce to legalna, znana aplikacja robiąca to, co zwykle.
3. Napastnik masowo odpytuje dane (w tym przypadku — dane z instancji Salesforce setek firm), często szukając kolejnych sekretów: kluczy API, tokenów do innych chmur, danych uwierzytelniających w polach tekstowych.

Efekt: pojedyncza kompromitacja jednego dostawcy zamienia się w wyciek u setek jego klientów naraz. To ta sama dźwignia, którą widzieliśmy przy robaku npm — skala bierze się z zaufania, które hurtowo pokładamy w integracjach.

Dlaczego MFA nie pomogło

To najważniejszy wniosek dla zarządów, które „zainwestowały w MFA i czują się bezpieczne”. Tokeny OAuth z założenia omijają logowanie — istnieją właśnie po to, by aplikacja nie musiała się co chwilę uwierzytelniać. Wykradziony token to dostęp, którego nie zatrzyma silne hasło ani drugi składnik, bo działa poza tym mechanizmem. Jedyne, co go unieważnia, to odebranie zgody / rotacja tokenu — a żeby to zrobić, najpierw trzeba wiedzieć, że wyciekł.

Lekcje dla każdej firmy

Integracje to dostawcy — traktuj je jak dostawców. Każda aplikacja OAuth podpięta do Twoich systemów ma dostęp do danych i jest kolejnym elementem łańcucha dostaw. Zanim ją podłączysz: jaki zakres uprawnień żąda? czy naprawdę potrzebuje dostępu do zapisu i do wszystkich rekordów? kto za nią odpowiada?

Przegląd i minimalizacja zgód OAuth. Zrób inwentaryzację aplikacji podłączonych do Salesforce, M365 i Google — w co drugim tenancie znajdujemy zapomniane integracje z szerokim dostępem. Odbierz zgody nieużywane, ogranicz zakresy do minimum. To ten sam przegląd, który zalecamy przy shadow IT i bezpieczeństwie M365.

Monitoruj użycie tokenów, nie tylko logowania. Klasyczny monitoring skupia się na logowaniach użytkowników. Tu potrzebny jest wgląd w aktywność aplikacji: nietypowo duże pobrania danych przez integrację, dostęp z nowych adresów, odpytywanie rekordów wykraczające poza normalny wzorzec. To rozszerzenie monitoringu bezpieczeństwa o warstwę aplikacyjną.

Nie trzymaj sekretów w danych. Atakujący masowo przeszukiwali pobrane rekordy Salesforce w poszukiwaniu kluczy i haseł wpisanych w pola tekstowe (notatki, opisy). To przypomnienie, że dane w CRM bywają skarbnicą poświadczeń — a te powinny mieszkać w menedżerze haseł, nie w komentarzu do rekordu.

Reaguj rotacją, nie tylko łataniem. Po takim incydencie kluczowe jest unieważnienie tokenów i rotacja wszystkiego, co mogło być w wykradzionych danych. To ta sama zasada „kradzież sekretów uodparnia na naprawę”, którą widzieliśmy przy ToolShell.

Najczęstsze pytania (FAQ)

Używamy Salesforce/M365 z MFA. Czy byliśmy bezpieczni? Niekoniecznie. Jeśli mieliście podłączoną integrację, której tokeny wyciekły, napastnik mógł czytać Wasze dane mimo MFA — bo token OAuth działa poza logowaniem. Bezpieczeństwo w takim modelu zależy nie tylko od Was, ale i od dostawcy integracji.

Jak sprawdzić, które aplikacje mają dostęp do naszych danych? W Salesforce, Entra ID i Google Workspace istnieją panele „connected apps”/„enterprise applications” z listą zgód OAuth i zakresów. Przejrzyj je: odbierz nieużywane, zawęź nadmiarowe, zweryfikuj, które mają dostęp do zapisu i do pełnych danych.

Co zrobić, gdy dostawca integracji zgłosi u siebie incydent? Potraktuj to jak własny incydent: odbierz i odtwórz zgody/tokeny dla tej integracji, przejrzyj logi aktywności aplikacji pod kątem nietypowych pobrań w oknie ekspozycji, sprawdź, czy w danych nie było sekretów do rotacji. Nie czekaj na potwierdzenie „czy akurat Was to dotyczy”.

Czy powinniśmy w ogóle rezygnować z integracji OAuth? Nie — są zbyt użyteczne i to nie one są problemem, lecz brak nadzoru nad nimi. Chodzi o świadome zarządzanie: minimalne zakresy, przegląd zgód, monitoring użycia i traktowanie każdej integracji jak dostawcy z dostępem do danych.

Jak przetestować to ryzyko u nas? Audyt bezpieczeństwa obejmujący konfigurację SaaS przegląda zgody OAuth, zakresy uprawnień integracji i widoczność ich aktywności — dokładnie te obszary, które zdecydowały o zasięgu tego wycieku. Umów przegląd.

Podsumowanie

Wyciek tokenów z integracji Salesloft/Salesforce pokazał, że w erze SaaS Twoje dane są tak bezpieczne, jak najsłabsza aplikacja, której dałeś dostęp — a token OAuth potrafi ominąć nawet najlepsze MFA. Obrona to nie rezygnacja z integracji, lecz zarządzanie nimi jak dostawcami: minimalne zakresy, regularny przegląd zgód, monitoring użycia tokenów i szybka rotacja po incydencie. Sprawdź, komu Twoje systemy dziś ufają — zanim zrobi to za Ciebie ktoś niepowołany.

Źródła i dalsza lektura: Google Threat Intelligence / Mandiant, Sekurak, Niebezpiecznik.