Jedno skradzione OAuth z rozszerzenia AI, kilka przejętych usług: efekt domina od dodatku do przeglądarki po firmową chmurę

Pracownik instaluje rozszerzenie AI do przeglądarki, loguje je do firmowego konta Google albo Microsoft i akceptuje kilka ekranów zgód. Dodatek ma streszczać strony, pisać odpowiedzi i analizować dokumenty. Problem zaczyna się wtedy, gdy przechwycony zostaje token OAuth. Atakujący nie musi znać hasła, łamać MFA ani imitować strony logowania. Jeżeli token nadal jest ważny i ma odpowiednio szerokie uprawnienia, może po prostu użyć go do wykonania operacji, które wcześniej zatwierdził użytkownik.

To właśnie odróżnia kradzież tokenu od klasycznego wycieku hasła. Hasło jest kluczem do procesu logowania. Access token jest natomiast dowodem, że proces autoryzacji już się odbył. Serwer API widzi prawidłowy token i zakres uprawnień, a nie to, czy żądanie wysłał użytkownik ze swojego laptopa, czy napastnik z innej infrastruktury. Mechanizmy typu proof-of-possession mogą ograniczać możliwość ponownego użycia skradzionego tokenu, ale działają tylko tam, gdzie wspierają je zarówno system wydający token, jak i usługa docelowa.

Rozszerzenie AI staje się punktem wejścia, gdy dostaje więcej dostępu, niż rzeczywiście potrzebuje

Rozszerzenie przeglądarkowe pracuje wyjątkowo blisko danych użytkownika. W zależności od przyznanych mu uprawnień może widzieć zawartość otwieranych kart, komunikować się z określonymi domenami, korzystać z pamięci przeglądarki albo inicjować autoryzację do usług zewnętrznych. Sam OAuth nie jest tutaj błędem. Problem pojawia się wtedy, gdy wygodny dodatek otrzymuje szerokie scope’y, a organizacja traktuje zgodę OAuth jak techniczny szczegół zamiast jak nadanie dostępu do danych.

Google przewiduje dla rozszerzeń Chrome obsługę autoryzacji przez Chrome Identity API, natomiast sam OAuth pozwala aplikacji uzyskać access token potrzebny do wywoływania określonych API. Zakres możliwości nie wynika więc z etykiety „rozszerzenie AI”, lecz z tego, jakie dokładnie uprawnienia zaakceptował użytkownik.

W praktycznym audycie interesują mnie cztery rzeczy:

• jakie scope’y przyznano aplikacji — od prostego odczytu profilu do dostępu do poczty, plików czy kalendarza;

• czy token jest przechowywany po stronie przeglądarki i czy może zostać odczytany przez podatny albo złośliwy kod;

• czy aplikacja dostała możliwość długotrwałego dostępu, np. przez mechanizm odświeżania tokenów;

• czy ta sama tożsamość pracownika otwiera kolejne usługi firmowe przez SSO lub federację.

Ten ostatni punkt jest najczęściej niedoceniany. Sam token do jednego API nie jest magicznym kluczem do wszystkich systemów firmy. OAuth jest związany z konkretnym odbiorcą i zakresem uprawnień. Efekt domina pojawia się jednak wtedy, gdy jedna przejęta usługa zawiera dane, które umożliwiają przejście dalej.

Przykład jest prosty. Atakujący uzyskuje dostęp do skrzynki użytkownika. W niej znajduje:

• powiadomienia z GitHub, GitLab, Jira albo systemu CRM,

• wiadomości zawierające linki do współdzielonych dokumentów,

• zaproszenia do paneli administracyjnych,

• alerty z infrastruktury chmurowej,

• korespondencję z działem finansowym,

• adresy pracowników uprzywilejowanych,

• informacje pozwalające przygotować wiarygodny phishing wewnętrzny.

Od tej chwili problem nie dotyczy już rozszerzenia. Dotyczy całego grafu zależności między kontami i usługami.

Istotne jest też rozróżnienie access tokenu od refresh tokenu. Access token jest zazwyczaj krócej żyjącym poświadczeniem używanym bezpośrednio do API. Refresh token służy do zdobywania kolejnych access tokenów i dlatego jego przejęcie jest szczególnie groźne. Microsoft wprost wskazuje, że skradzione tokeny mogą być ponownie używane do podszycia się pod użytkownika; firma szacowała skalę wykrywanych prób kradzieży tokenów na około 39 tys. incydentów dziennie.

I tu pojawia się niewygodna cecha OAuth: zmiana hasła nie zawsze rozwiązuje problem. Jeżeli ważny token nadal działa, napastnik może zachować dostęp niezależnie od tego, że użytkownik ustawił nowe hasło. Administrator musi pracować na sesjach, tokenach, zgodach aplikacji i konkretnych połączeniach OAuth, a nie tylko na danych logowania.

Efekt domina zaczyna się od uprawnień, ale rośnie dzięki firmowym zależnościom

Najgroźniejszy scenariusz nie wygląda jak filmowe „przejęcie całej chmury jednym tokenem”. Jest bardziej przyziemny i przez to skuteczniejszy. Atakujący wykorzystuje jeden dostęp do zdobywania kolejnych informacji, tożsamości i poświadczeń.

Typowy łańcuch może wyglądać tak:

1. Rozszerzenie uzyskuje token do konta pracownika.
Źródłem może być złośliwa aktualizacja, przejęcie konta wydawcy dodatku, luka umożliwiająca wykonanie kodu albo komponent, który wysyła dane poza oczekiwany backend.

2. Token daje dostęp do konkretnego API.
Jeżeli zakres obejmuje pocztę lub pliki, napastnik zaczyna od wyszukiwania danych o wysokiej wartości. Nie musi pobierać całej skrzynki. Kilkanaście dobrze dobranych zapytań często daje więcej niż masowy eksport.

3. Z danych powstaje mapa organizacji.
Nazwy projektów, adresy administratorów, dostawcy chmurowi, domeny, repozytoria, systemy księgowe, procedury zatwierdzania płatności — wszystko to pomaga wybrać następny krok.

4. Następuje przejście do następnej usługi.
Może nim być wyłudzenie nowej zgody OAuth, przejęcie resetu konta, wykorzystanie sekretu znalezionego w pliku, dostęp do repozytorium albo podszycie się pod pracownika przed helpdeskiem.

5. Atak utrzymuje się poza pierwotnym rozszerzeniem.
Usunięcie dodatku z Chrome jest wtedy za późne. Pierwszy kanał dostępu może już nie być potrzebny.

W Microsoft Entra administrator może zablokować aplikacji możliwość pozyskiwania nowych tokenów, ale już wydane access tokeny mogą pozostać ważne do czasu ich wygaśnięcia. To ważna różnica operacyjna: odebranie zgody jest konieczne, lecz nie należy zakładać, że natychmiast kasuje każdą aktywną możliwość dostępu.

Podobny problem widać w innych systemach opartych na tokenach. CERT Polska opisywał podatności, w których token pozostawał użyteczny nawet po wylogowaniu użytkownika. W Strapi problem CVE-2025-3930 pozwalał ponownie wykorzystywać przechwycony JWT aż do jego wygaśnięcia; domyślna ważność wynosiła tam 30 dni. Nie jest to ten sam mechanizm co OAuth w Google Workspace czy Entra ID, ale dobrze pokazuje najważniejszą zasadę reagowania: „użytkownik został wylogowany” nie jest równoznaczne z „wszystkie skradzione poświadczenia przestały działać”.

Dlatego po wykryciu podejrzanego rozszerzenia kolejność ma znaczenie. Najpierw ogranicza się dalsze wykorzystanie tożsamości, dopiero później sprząta urządzenie.

Priorytet P1 powinien obejmować:

• zablokowanie albo usunięcie podejrzanej aplikacji OAuth na poziomie organizacji;

• odebranie jej zgód;

• unieważnienie aktywnych sesji i tokenów użytkowników objętych incydentem;

• sprawdzenie logów API i logowań pod kątem nietypowych adresów IP, user-agentów, godzin oraz operacji;

• ustalenie, jakie dane token faktycznie pozwalał odczytywać lub modyfikować.

Dopiero potem ma sens szczegółowe badanie stacji roboczej, analiza wersji rozszerzenia i ustalanie początkowego wektora.

Błąd, który widuję w takich procedurach bardzo często, to odwrotna kolejność: dział IT usuwa dodatek ze 120 laptopów i uznaje, że incydent został ograniczony. Tymczasem wykradziony token znajduje się już poza organizacją. Deinstalacja usuwa źródło wycieku, ale nie usuwa skopiowanego poświadczenia.

Najlepszą ochroną nie jest zakaz AI, lecz ograniczenie promienia rażenia

Całkowite blokowanie rozszerzeń AI wygląda atrakcyjnie na papierze, lecz w wielu firmach kończy się instalowaniem alternatyw poza kontrolą działu IT. Lepszym punktem wyjścia jest potraktowanie dodatków tak samo jak innych aplikacji SaaS mających dostęp do firmowej tożsamości.

Pierwszą barierą powinien być allowlist rozszerzeń. W środowisku zarządzanym organizacja powinna instalować zatwierdzone dodatki centralnie i blokować samodzielne uruchamianie niezweryfikowanych rozszerzeń na profilach służbowych. Weryfikacja nie może kończyć się na ocenie sklepu z dodatkami. Trzeba sprawdzić producenta, politykę prywatności, zakres host permissions, mechanizm aktualizacji oraz to, czy rozszerzenie komunikuje się wyłącznie z oczekiwanymi domenami.

Druga bariera to minimalizacja zgód OAuth. Jeżeli narzędzie ma jedynie poprawiać tekst wpisany w formularzu, trudno uzasadnić stały dostęp do całej skrzynki pocztowej albo wszystkich plików użytkownika. Scope należy oceniać funkcja po funkcji.

Sensowna reguła decyzyjna wygląda tak:

• odczyt publicznego profilu użytkownika — ryzyko stosunkowo niskie;

• dostęp do pojedynczych plików wybranych przez użytkownika — do zaakceptowania po sprawdzeniu aplikacji;

• pełny odczyt poczty, dysku lub kontaktów — wymaga uzasadnienia biznesowego;

• możliwość wysyłania wiadomości, modyfikowania plików albo wykonywania działań jako użytkownik — traktować jako uprawnienie wysokiego ryzyka;

• zgoda obejmująca znaczną część organizacji lub aplikację wielodostępną — wymaga kontroli administracyjnej, nie decyzji pojedynczego pracownika.

Google rozwija model granular permissions, czyli przyznawania aplikacji poszczególnych uprawnień osobno. To właściwy kierunek, ale nie rozwiązuje problemu automatycznie: użytkownik nadal może zatwierdzić więcej, niż aplikacja faktycznie potrzebuje.

Trzecia bariera to telemetria. Jeżeli firma nie zapisuje informacji o zgodach OAuth i wywołaniach API, analiza po incydencie zaczyna się od zgadywania. Minimum to możliwość ustalenia:

• kto zatwierdził aplikację,

• kiedy nastąpiło zatwierdzenie,

• jakie scope’y przyznano,

• z których kont aplikacja korzystała,

• jakie operacje wykonywano po podejrzanym zdarzeniu,

• czy pojawiło się nietypowe logowanie lub użycie API.

MFA pozostaje potrzebne, ale nie wolno traktować go jak zabezpieczenia przed każdym przejęciem konta. Token wystawiony po prawidłowo zakończonym MFA może pozwalać wykonywać żądania bez ponownego przechodzenia całego procesu logowania. To dokładnie powód, dla którego kradzież sesji i tokenów jest tak skuteczna.

Po stronie Microsoft warto dodatkowo sprawdzić możliwości wymuszające silniejszą ochronę tokenów i polityki dostępu warunkowego. Proof-of-possession może utrudnić zwykłe skopiowanie i odtworzenie tokenu na urządzeniu napastnika, ale nie jest uniwersalnym przełącznikiem bezpieczeństwa — musi być obsługiwany w całym łańcuchu autoryzacji i dostępu do zasobu.

Najbardziej irytująca część tej ochrony jest organizacyjna. Regularny przegląd aplikacji OAuth szybko generuje długą listę integracji, których właściciela nikt już nie pamięta. Część z nich rzeczywiście wspiera procesy biznesowe, część została zaakceptowana dwa lata wcześniej na potrzeby jednego testu. Automatyczne kasowanie wszystkiego kończy się awariami integracji. Zostawianie wszystkiego — rosnącym długiem bezpieczeństwa.

Dlatego aplikację bez potwierdzonego właściciela biznesowego należy najpierw oznaczyć do wygaszenia, sprawdzić jej aktywność i dopiero później odebrać dostęp. Wyjątek stanowią aplikacje wykazujące oznaki kompromitacji: tam priorytetem jest natychmiastowe odcięcie dostępu, nawet kosztem przerwania procesu biznesowego.

Więcej informacji na: https://sajo.pl

FAQ

Czy samo usunięcie podejrzanego rozszerzenia z Chrome wystarczy?
Nie. Jeżeli token został już wykradziony, jego kopia znajduje się poza przeglądarką. Trzeba odebrać zgody aplikacji, unieważnić sesje i tokeny oraz sprawdzić aktywność konta po prawdopodobnym momencie kompromitacji.

Czy zmiana hasła automatycznie unieważnia token OAuth?
Nie należy tego zakładać. Sposób unieważniania zależy od dostawcy, rodzaju tokenu i konfiguracji. Reakcja na incydent powinna obejmować osobne działania dotyczące tokenów, sesji i zgód aplikacji.

Czy MFA zatrzymuje atak z użyciem skradzionego tokenu?
Nie zawsze. MFA chroni przede wszystkim moment uwierzytelnienia. Jeżeli napastnik przejął ważny token wydany już po poprawnym logowaniu, może próbować korzystać z niego bez ponownego wpisywania hasła i kodu MFA.

Czy jeden token OAuth daje dostęp do całej firmowej chmury?
Nie. Token ma określonego odbiorcę i zakres uprawnień. Efekt domina powstaje wtedy, gdy dostęp do pierwszej usługi pozwala zdobyć informacje lub poświadczenia prowadzące do następnych systemów.

Co sprawdzić jako pierwsze po wykryciu podejrzanego dodatku AI?
Najpierw sprawdź jaką aplikację OAuth autoryzował dodatek, jakie scope’y otrzymała i którym użytkownikom wydano dostęp. Jeżeli zakres obejmuje pocztę, pliki lub operacje wykonywane w imieniu użytkownika, od razu odetnij aplikację i unieważnij aktywne poświadczenia. Analizę kodu rozszerzenia zostaw na drugi etap. Najgroźniejszym błędem byłoby rozpoczęcie od samej deinstalacji dodatku i pozostawienie ważnych tokenów po stronie atakującego.