Luka w zabezpieczeniach kilku aplikacji Microsoft 365 na Androida naraziła użytkowników na potencjalne przejęcie kont na ogromną skalę, co po raz kolejny pokazuje, jak krucha może być zaufana warstwa uwierzytelniania, gdy tokeny nie są odpowiednio chronione.
Badacze z firmy Enclave odkryli, że ustawienie związane z debugowaniem zostało omyłkowo pozostawione włączone w wersjach produkcyjnych wielu aplikacji Microsoft na Androida, w tym Word, Excel, PowerPoint, OneNote, Loop i Microsoft 365 Copilot.
Problem osłabiał mechanizm zabezpieczający, którego zadaniem było zapewnienie, że tokeny uwierzytelniania mogą otrzymywać od innych aplikacji Microsoft na tym samym urządzeniu z Androidem wyłącznie zaufane aplikacje Microsoft.
Microsoft wydał od tego czasu aktualizacje i przypisał tym lukom wiele identyfikatorów CVE, w tym CVE-2026-41100, CVE-2026-41101, CVE-2026-41102 i CVE-2026-42832.
Co poszło nie tak?
Aplikacje Microsoft 365 na Androida obsługują przepływy logowania między aplikacjami. Pozwala to użytkownikom uwierzytelnić się raz i płynniej przechodzić między zaufanymi aplikacjami Microsoft.
Takie współdzielone logowanie może być przydatne, ale zależy od bezpiecznej granicy zaufania. Jedna aplikacja musi mieć możliwość zweryfikowania, że inna aplikacja żądająca tokenu uwierzytelniania jest legalna i zaufana.
Według Enclave ta weryfikacja zawiodła, ponieważ ustawienie testowe zostało pozostawione włączone w wersjach produkcyjnych.
Ustawienie to w praktyce wyłączało kontrolę autoryzacji, która powinna była uniemożliwiać niezaufanym aplikacjom otrzymywanie tokenów uwierzytelniania Microsoft.
Mówiąc prościej, aplikacja, której nie należało ufać, mogła potencjalnie zażądać tokenu i go otrzymać.
Dlaczego było to tak niebezpieczne
Problem nie ograniczał się do jednej aplikacji.
Podatny kod znajdował się we współdzielonym zestawie programistycznym (SDK) Microsoft używanym w wielu aplikacjach Microsoft na Androida. Oznaczało to, że ta sama słabość mogła powielać się jednocześnie w kilku aplikacjach.
Podobno do podatnych aplikacji należały:
- Microsoft Word
- Microsoft Excel
- Microsoft PowerPoint
- Microsoft OneNote
- Microsoft Loop
- Microsoft 365 Copilot
Ponieważ aplikacje te są powszechnie instalowane, potencjalna skala narażenia była znaczna.
Złośliwa aplikacja na Androida zainstalowana na tym samym urządzeniu mogła teoretycznie zażądać tokenów Microsoft od podatnej aplikacji, otrzymać je bez właściwej weryfikacji, wykraść je, a następnie wykorzystać do uzyskania dostępu do zasobów Microsoft 365.
Do czego mogli uzyskać dostęp atakujący?
Skutki zależały od konkretnych zdobytych tokenów i uprawnień dostępnych dla danego użytkownika.
Według Enclave atakujący mogli potencjalnie uzyskać dostęp do wrażliwych danych Microsoft 365, w tym:
- wiadomości e-mail
- wiadomości Microsoft Teams
- plików przechowywanych w Microsoft 365
- danych powiązanych z kontem w aplikacjach Microsoft
- dokumentów użytkownika
- zasobów chmurowych dostępnych w ramach sesji użytkownika
W niektórych scenariuszach atakujący mogli nie tylko odczytywać dane, ale też wykonywać działania, takie jak wysyłanie e-maili.
Czyni to problem szczególnie poważnym, ponieważ mógł on wspierać przejęcie konta, business email compromise, kradzież danych, podszywanie się pod użytkowników i dalszą socjotechnikę.
Rola tokenów FOCI
Jedna z najbardziej niepokojących części problemu dotyczyła tokenów FOCI.
FOCI oznacza Family of Client IDs (rodzinę identyfikatorów klientów). Tokeny te są zaprojektowane tak, aby działały w całej rodzinie zaufanych aplikacji Microsoft, co ułatwia użytkownikom uwierzytelnianie między aplikacjami.
Ta wygoda staje się niebezpieczna, jeśli token opuści swoją zamierzoną granicę bezpieczeństwa.
Tokeny FOCI można ponownie wykorzystywać i odświeżać przez długi czas. Jeśli zostaną skradzione, mogą zapewniać trwały dostęp bez oczywistych oznak kompromitacji.
Stwarza to poważne wyzwanie w zakresie wykrywania, ponieważ aktywność z użyciem tokenu może wyglądać normalnie dla systemów zaplecza. Z perspektywy usługi token wydaje się ważny i wydany w ramach zaufanego przepływu.
To jest główne ryzyko: skradzione tokeny mogą sprawić, że atakujący będą wyglądać jak legalni użytkownicy lub legalne aplikacje.
Dlaczego logi mogą nie wyglądać podejrzanie
Tradycyjne przejęcie konta często generuje podejrzane sygnały: nietypowe logowania, niemożliwe podróże, nieudane próby MFA, nieznane urządzenia lub nietypowe przepływy uwierzytelniania.
Kradzież tokenów może być trudniejsza do wykrycia.
Jeśli atakujący zdobędzie ważny token uwierzytelniania i użyje go poprawnie, usługi zaplecza mogą widzieć coś, co wygląda na normalny dostęp.
Może nie być powtórzenia hasła. Może nie być oczywistego wyzwania MFA. Może nie być podejrzanego monitu logowania.
Atakujący nie włamuje się frontowymi drzwiami. Używa ważnego klucza, którego nigdy nie powinien był otrzymać.
Dlatego bezpieczeństwo tokenów jest dziś jednym z najważniejszych elementów nowoczesnej ochrony tożsamości.
Jak mogła działać eksploatacja
Atakujący musiałby dostarczyć złośliwą aplikację na Androida na telefon ofiary.
Aplikacja ta mogłaby zawierać procedurę zaprojektowaną do żądania tokenów od podatnych aplikacji Microsoft.
Ponieważ podatne aplikacje nie weryfikowały prawidłowo, czy aplikacja żądająca jest zaufana, złośliwa aplikacja mogła potencjalnie otrzymać tokeny, których nigdy nie powinna była móc uzyskać.
Atakujący mógł następnie przesłać te tokeny na własną infrastrukturę i wykorzystać je do uzyskania dostępu do usług Microsoft 365.
Ścieżkę ataku można streścić następująco:
- Ofiara instaluje lub aktualizuje złośliwą aplikację na Androida.
- Złośliwa aplikacja po cichu żąda tokenów uwierzytelniania Microsoft.
- Podatna aplikacja Microsoft zwraca token bez właściwej weryfikacji zaufania.
- Złośliwa aplikacja wykrada token.
- Atakujący używa tokenu, aby uzyskać dostęp do danych Microsoft 365.
Sprawia to, że problem jest jednocześnie kwestią mobilnego łańcucha dostaw i bezpieczeństwa tożsamości.
Drobny błąd programistyczny o dużych skutkach
Podatność wydaje się wynikać z drobnego błędu konfiguracji: ustawienia debugowania lub testowego, które nie powinno pozostać włączone w wersji produkcyjnej.
Taki problem może wydawać się nieistotny na etapie tworzenia oprogramowania, ale w systemach uwierzytelniania może mieć poważne konsekwencje.
Kod uwierzytelniania ma krytyczne znaczenie dla bezpieczeństwa. Jedna źle ustawiona flaga, wyłączona kontrola weryfikacji lub niebezpieczne rozwiązanie awaryjne mogą podważyć cały model zaufania.
Ten przypadek przypomina, że przeglądy bezpieczeństwa muszą obejmować konfiguracje kompilacji, domyślne ustawienia SDK, flagi debugowania i kontrole wydań produkcyjnych, a nie tylko logikę aplikacji.
Współdzielone SDK mogą wzmacniać ryzyko
Problem pokazuje również, jak współdzielone SDK mogą mnożyć skutki dla bezpieczeństwa.
Gdy luka istnieje we wspólnym komponencie używanym przez wiele aplikacji, zasięg szkód szybko się rozszerza.
Jeden błąd może dotknąć wiele produktów, wielu użytkowników i wiele przepływów uwierzytelniania.
Współdzielone SDK są użyteczne, ponieważ ograniczają duplikację kodu i zapewniają spójność. Należy je jednak traktować jako komponenty o wysokiej wartości, wymagające rygorystycznych testów bezpieczeństwa.
Organizacje tworzące współdzielone SDK powinny stosować:
- bezpieczne ustawienia domyślne
- kontrole bramek wydania
- zautomatyzowaną walidację konfiguracji
- weryfikację kompilacji produkcyjnych
- testowanie przepływów tokenów
- testowanie scenariuszy nadużyć
- niezależny przegląd bezpieczeństwa
Błąd we współdzielonym kodzie uwierzytelniania może stać się problemem całego ekosystemu.
Dlaczego bezpieczeństwo tokenów mobilnych ma znaczenie
Aplikacje mobilne coraz częściej pełnią funkcję bram do usług chmurowych.
Użytkownicy uzyskują z urządzeń mobilnych dostęp do poczty, plików, czatu, systemów CRM, narzędzi finansowych, platform deweloperskich, systemów HR i asystentów AI.
Oznacza to, że mobilne tokeny uwierzytelniania mogą odblokowywać bardzo wrażliwe dane biznesowe.
Atakujący zdają sobie z tego sprawę.
Jeśli uda im się wykraść tokeny mobilne, mogą ominąć zabezpieczenia oparte na hasłach i korzystać z usług tak, jakby byli legalnym użytkownikiem.
Dlatego bezpieczeństwo aplikacji mobilnych musi chronić:
- przechowywanie tokenów
- wymianę tokenów
- komunikację między aplikacjami
- weryfikację zaufanych aplikacji
- integralność urządzenia
- manipulacje w czasie wykonania
- ingerencję złośliwych aplikacji
- logikę odświeżania sesji
Urządzenie, aplikacja i użytkownik muszą być traktowani jako elementy decyzji o zaufaniu.
Wnioski dla deweloperów
Dla deweloperów ten incydent wzmacnia kilka ważnych lekcji.
Tokenów uwierzytelniania nigdy nie wolno traktować niedbale.
Zalecane praktyki obejmują:
- nigdy nie zostawiaj włączonych ustawień debugowania ani testowych w wersji produkcyjnej
- weryfikuj wszystkie żądania tokenów między aplikacjami
- sprawdzaj tożsamość i integralność aplikacji żądających
- unikaj zaszytych na stałe sekretów w plikach binarnych aplikacji mobilnych
- stosuj bezpieczne przechowywanie tokenów
- ograniczaj czas życia tokenów, gdzie to możliwe
- wiąż tokeny z kontekstem zaufanej aplikacji i urządzenia
- testuj przepływy uwierzytelniania w scenariuszach ze złośliwą aplikacją
- regularnie audytuj współdzielone SDK
- uwzględniaj kontrole konfiguracji kompilacji w potokach wydań
Deweloperzy powinni zakładać, że urządzenia mobilne mogą już zawierać złośliwe aplikacje próbujące przechwytywać, żądać lub nadużywać tokenów.
Wnioski dla organizacji
Organizacje korzystające z Microsoft 365 powinny upewnić się, że podatne aplikacje zostały zaktualizowane na zarządzanych urządzeniach z Androidem.
Zalecane działania obejmują:
- sprawdzenie, czy aplikacje Microsoft 365 na Androida zostały zaktualizowane do poprawionych wersji
- egzekwowanie zasad zarządzania urządzeniami mobilnymi (MDM)
- ograniczenie instalacji z niezaufanych źródeł aplikacji
- monitorowanie nietypowego dostępu do Microsoft 365 z sesji mobilnych
- przegląd ryzykownych logowań i zdarzeń dostępu opartego na tokenach
- egzekwowanie zasad dostępu warunkowego
- wymaganie zgodności urządzeń przy dostępie do Microsoft 365
- ograniczenie dostępu z niezarządzanych urządzeń z Androidem
- stosowanie ochrony przed zagrożeniami mobilnymi tam, gdzie to właściwe
- edukowanie użytkowników, by nie instalowali nieznanych plików APK ani nieoficjalnych aplikacji
Jeśli wykryto podejrzany dostęp mobilny, organizacje powinny unieważnić sesje i tokeny odświeżania, a nie tylko zresetować hasła.
Dlaczego reset hasła może nie wystarczyć
W scenariuszach kradzieży tokenów zmiana hasła nie zawsze od razu odbiera atakującemu dostęp.
Jeśli skradziony token odświeżania pozostaje ważny, atakujący może nadal korzystać z usług, dopóki token nie zostanie unieważniony lub nie wygaśnie.
Oznacza to, że reagowanie na incydent powinno obejmować:
- unieważnienie tokenów odświeżania
- wylogowanie użytkownika ze wszystkich sesji
- przegląd uprawnień OAuth
- sprawdzenie zgodności urządzeń mobilnych
- usunięcie podejrzanych urządzeń
- rotację poświadczeń w razie potrzeby
- przegląd logów dostępu do skrzynki pocztowej i plików
Kompromitacja tokenu wymaga reakcji skoncentrowanej na tokenach.
Podsumowanie
Luka w tokenach Microsoft 365 na Androida pokazuje, jak jeden drobny błąd konfiguracji produkcyjnej może osłabić zaufanie w powszechnie używanych aplikacjach korporacyjnych.
Wyłączając kluczową kontrolę weryfikacji aplikacji, podatne aplikacje mogły potencjalnie przekazywać tokeny uwierzytelniania niezaufanym aplikacjom na Androida. Ponieważ tokeny te mogły zapewniać dostęp do wrażliwych usług Microsoft 365, ryzyko było znaczne.
Tokeny uwierzytelniania są potężne. Muszą być chronione jak poświadczenia, stale weryfikowane i utrzymywane w zamierzonej granicy bezpieczeństwa.
We współczesnych środowiskach chmurowych skradziony token może być równie niebezpieczny jak skradzione hasło — a czasem trudniejszy do wykrycia.
