Krytyczna luka w aplikacjach Microsoft 365 na Androidzie pozwalała kraść tokeny kont

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

W kilku aplikacjach Microsoft 365 dla systemu Android wykryto krytyczną lukę bezpieczeństwa, która mogła umożliwić złośliwej aplikacji działającej na tym samym urządzeniu przejęcie tokenów uwierzytelniających użytkownika. Problem wynikał z pozostawienia aktywnej flagi debugowania w kompilacjach produkcyjnych, co wyłączało mechanizm sprawdzania, czy żądanie dostępu do konta pochodzi od zaufanej aplikacji.

W praktyce oznaczało to możliwość uzyskania dostępu do zasobów Microsoft 365 bez znajomości hasła, bez ponownego logowania i bez wyraźnego ostrzeżenia dla ofiary. Skala ryzyka była istotna, ponieważ mechanizm współdzielenia sesji obejmuje wiele popularnych aplikacji pakietu biurowego Microsoftu.

W skrócie

Luka dotyczyła wybranych aplikacji Microsoft 365 na Androidzie, m.in. Worda, Excela, PowerPointa, OneNote, Loop i Microsoft 365 Copilot.
Błąd pozwalał dowolnej aplikacji zainstalowanej na tym samym urządzeniu zażądać tokenu zalogowanego użytkownika.
Źródłem problemu była współdzielona biblioteka oraz pozostawiona aktywna konfiguracja debugowania.
Microsoft przygotował poprawki i opublikował identyfikatory CVE dla części objętych produktów.
Administratorzy i użytkownicy powinni nie tylko zaktualizować aplikacje, ale także ocenić ryzyko przejęcia aktywnych sesji.

Kontekst / historia

Ekosystem Microsoft 365 od lat korzysta z mechanizmów jednokrotnego logowania między aplikacjami mobilnymi. Dzięki temu użytkownik po uwierzytelnieniu w jednej aplikacji może płynnie korzystać z kolejnych narzędzi bez ponownego wpisywania danych logowania. To rozwiązanie zwiększa wygodę, ale jednocześnie wymaga rygorystycznej kontroli zaufania pomiędzy aplikacjami.

W tym przypadku badacze ustalili, że problem nie wynikał z osłabienia kryptografii ani złamania procesu logowania, lecz z błędnej konfiguracji logiki autoryzacyjnej. Produkcyjna wersja kodu zachowywała się tak, jakby nadal pracowała w środowisku testowym, przez co pomijano weryfikację uprawnionych klientów żądających tokenów.

To szczególnie niebezpieczny scenariusz, ponieważ wada pojawiła się w komponencie współdzielonym przez wiele aplikacji. Oznacza to, że pojedynczy błąd implementacyjny mógł zostać odziedziczony przez kilka produktów jednocześnie, zwiększając powierzchnię ataku i utrudniając szybką inwentaryzację zagrożenia.

Analiza techniczna

Technicznie podatność sprowadzała się do pozostawienia aktywnej flagi debugowania w kodzie przeznaczonym dla użytkowników końcowych. Taka konfiguracja powodowała wyłączenie mechanizmu sprawdzającego, czy aplikacja prosząca o token należy do zaufanego zestawu klientów Microsoftu. W poprawnie działającym modelu żądanie z nieautoryzowanego pakietu powinno zostać odrzucone.

W podatnym scenariuszu dowolna aplikacja obecna na urządzeniu mogła próbować pobrać token zalogowanego użytkownika. Szczególne znaczenie miały tokeny typu FOCI, używane do obsługi współdzielonego logowania między aplikacjami z tej samej rodziny. Dla napastnika mają one wysoką wartość, ponieważ umożliwiają dalszy dostęp do usług i mogą być wykorzystywane w sposób przypominający zwykłą aktywność użytkownika.

Atak nie wymagał przechwycenia hasła, obejścia MFA ani podstawienia fałszywego ekranu logowania. Wystarczyło, aby ofiara miała na urządzeniu podatną aplikację Microsoft 365 oraz złośliwą aplikację zdolną do zainicjowania żądania pobrania tokenu. Po jego uzyskaniu możliwy stawał się dostęp do poczty, kalendarza, dokumentów, plików i innych zasobów powiązanych z kontem.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tej luki była potencjalna kompromitacja tożsamości użytkownika w usługach Microsoft 365 z poziomu lokalnej aplikacji na Androidzie. W środowisku firmowym mogło to prowadzić do nieautoryzowanego dostępu do danych biznesowych, wiadomości e-mail, zasobów współdzielonych oraz harmonogramów spotkań.

Ryzyko rośnie szczególnie w modelu BYOD oraz tam, gdzie organizacja nie ogranicza instalacji aplikacji do zatwierdzonego katalogu. W takich warunkach złośliwe oprogramowanie może zostać dostarczone pod pozorem narzędzia produktywności, komunikatora lub aplikacji użytkowej. Sam fakt, że atak wymagał obecności drugiej aplikacji na urządzeniu, nie obniża znacząco zagrożenia w realnych scenariuszach operacyjnych.

Warto też pamiętać, że samo zainstalowanie poprawki nie zawsze rozwiązuje problem w pełnym zakresie. Jeśli token odświeżania został już wcześniej przejęty, jego ważność może utrzymywać się także po aktualizacji aplikacji. Dlatego reakcja organizacji nie powinna kończyć się na patchingu, lecz obejmować również działania związane z sesjami, tożsamością i monitoringiem nadużyć.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja wszystkich podatnych aplikacji Microsoft 365 na urządzeniach z Androidem. W środowiskach korporacyjnych proces ten powinien zostać wymuszony centralnie przez systemy MDM lub EMM, a zgodność wersji zweryfikowana w ramach inwentaryzacji.

Równolegle warto przeprowadzić przegląd urządzeń, na których działały podatne wersje aplikacji, szczególnie jeśli użytkownicy instalowali oprogramowanie spoza zaufanych źródeł. Dla kont o podwyższonych uprawnieniach uzasadnione może być unieważnienie tokenów odświeżania i wymuszenie ponownego logowania.

Monitorować logi tożsamości i dostępu pod kątem nietypowej aktywności w Microsoft 365.
Ograniczyć możliwość instalacji niezatwierdzonych aplikacji na urządzeniach służbowych.
Egzekwować polityki aplikacyjne w Android Enterprise.
Weryfikować stan zabezpieczeń urządzeń przed dopuszczeniem ich do zasobów firmowych.
Połączyć zarządzanie podatnościami mobilnymi z procesami IAM oraz wykrywaniem anomalii.
Uwzględnić kontrolę flag debugowania i ustawień testowych w procesach jakościowych SDLC.

Podsumowanie

Luka wykryta w aplikacjach Microsoft 365 dla Androida pokazuje, jak pozornie drobny błąd konfiguracyjny może doprowadzić do poważnego naruszenia granic zaufania między aplikacjami. Problem dotyczył mechanizmu współdzielenia tokenów i umożliwiał ich pobranie przez nieuprawnione oprogramowanie obecne lokalnie na urządzeniu.

Choć producent udostępnił poprawki, organizacje powinny potraktować incydent szerzej niż jako zwykłą aktualizację aplikacji. Kluczowe znaczenie mają również przegląd ekspozycji, kontrola ekosystemu mobilnego, analiza zdarzeń związanych z tożsamością oraz ewentualne unieważnienie aktywnych sesji. To kolejny sygnał, że bezpieczeństwo mobilne i bezpieczeństwo tożsamości coraz częściej tworzą jeden wspólny obszar ryzyka.