Microsoft łata krytyczną lukę w Entra ID – co to oznacza dla Twojej firmy?
Dlaczego ta luka to duża sprawa
Każdy, kto korzysta z Microsoft 365, Azure czy Entra ID (dawniej Azure Active Directory), ufa, że systemy logowania i zarządzania dostępem działają bezbłędnie. W końcu to serce całej infrastruktury – miejsce, w którym definiujemy, kto jest zwykłym użytkownikiem. A także, kto jest administratorem mającym dostęp do wszystkiego.
Niedawno odkryto jednak lukę oznaczoną CVE-2025-55241, która wstrząsnęła społecznością IT. Dlaczego? Bo pozwalała potencjalnemu atakującemu podszyć się pod Global Administratora w dowolnym tenancie Microsoft 365. Innymi słowy – ktoś z zewnątrz mógł teoretycznie uzyskać pełną władzę nad cudzym środowiskiem chmurowym. I to bez znajomości haseł, kodów SMS czy nawet MFA.
Na szczęście Microsoft zdążył tę dziurę załatać w lipcu 2025, zanim pojawiły się informacje o realnych atakach. Ale sama natura tej podatności pokazuje, że w dzisiejszych czasach bezpieczeństwo to nie tylko firewalle i antywirusy. Przede wszystkim – czujność i gotowość na to, że zawsze może pojawić się „zero-day”, czyli luka, o której nikt jeszcze nie wie.
Co wiadomo o luce CVE-2025-55241
| Cecha | Opis |
|---|---|
| Typ podatności | Privilege Escalation / Elevation of Privilege – możliwość podniesienia uprawnień. Dark Reading |
| CVSS | Początkowo oceniana na 9.0, później podniesiona do 10.0 – maksymalna. |
| Mechanizm exploitu | Dwa kluczowe elementy: • „Actor tokens” – wewnętrzne tokeny używane przez Microsoft do komunikacji serwis-to-serwis (Service-to-Service), które nie były odpowiednio ograniczone. BetaNews • Stary (legacy) Azure AD Graph API – który nie weryfikował poprawnie, z którego tenanta pochodzi żądanie. Umożliwiało to przekroczenie granic tenantów (cross-tenant). |
| Zakres zagrożenia | Umożliwienie atakującemu podszywania się pod Global Admina w dowolnym tenancie. Nawet jeśli nie jest związany z danym tenantem, ma dostęp do zasobów. Potencjalnie dostęp do danych użytkowników, ról, polityk, aplikacji. The Cyber Express |
| Wykorzystanie w atakach | Microsoft informuje, że nie ma potwierdzeń rzeczywistego wykorzystania tej luki „w naturze” (in the wild) do tej pory. The Hacker News |
| Data załatania / naprawy | Luka została załatana przez Microsoft 17 lipca 2025. The Hacker News Oficjalna klasyfikacja CVE nadana 4 września 2025. The Cyber Express |
Jak działała luka?
Microsoft korzysta z tzw. Actor Tokens – specjalnych „biletów wstępu” wykorzystywanych przez usługi do rozmowy między sobą w tle. Normalny użytkownik tego nie widzi. Problem w tym, że część tych tokenów była zbyt ufna: nie sprawdzała dokładnie, do którego klienta (tenanta) należy dana usługa.
Efekt? Atakujący, który zdobył taki token, mógł nim „przemaszerować” do innego tenanta i uzyskać tam dostęp administracyjny. Co gorsza – takie operacje nie były widoczne w logach firmy, której dane były atakowane. Administrator mógł patrzeć w raporty bezpieczeństwa i widzieć czysto – podczas gdy ktoś z boku majstrował przy ustawieniach.
Dla porównania – to trochę tak, jakby pracownik banku miał specjalny klucz serwisowy. Miał nim wejść tylko do własnego oddziału, ale ktoś odkrył, że ten klucz otwiera też inne placówki. Co więcej, alarm w ogóle nie rejestruje, że ktoś tam wchodził.
Dodatkowe szczegóły techniczne
Braki w wykrywalności: Tokeny typu „actor” nie były rejestrowane w tenantach docelowych; operacje mogły być przeprowadzane bez widocznych alarmów.
Actor Tokens: Są to tokeny JWT, wydawane przez Microsoft Access Control Service, służące do komunikacji pomiędzy usługami wewnętrznymi (np. Exchange Online, SharePoint). Nie podlegają politykom Conditional Access w tenancie docelowym, nie są logowane u odbiorcy.
Nieprawidłowa weryfikacja tożsamości tenanta: Legacy Graph API nie sprawdzało, czy żądanie pochodzi z tego samego tenanta co użytkownik. Otwierało więc furtkę cross-tenant impersonation.
Dlaczego CVE-2025-55241 to poważna sprawa
- Utrata izolacji między tenantami: fundament bezpieczeństwa w chmurze to to, że jeden tenant nie wpływa na inny. Ten exploit łamał tę zasadę.
- Możliwość podszywania się pod Global Adminów: jeśli atakujący uzyskuje rolę Global Admina w innym tenancie, może przejąć pełną kontrolę.
- Omijanie zabezpieczeń: MFA, polityki dostępu warunkowego (Conditional Access) i inne mechanizmy mogły być nieskuteczne. Wynikało to z tego, że exploit operował po stronie backendu Microsoftu, przy tokenach „wewnętrznych”.
Co Microsoft zrobił / rekomendacje
- Microsoft przyjął raport odpowiedzialnie (responsible disclosure), rozpoczął działania naprawcze w lipcu, patch został wdrożony globalnie przed oficjalną publikacją.
- Zmiany obejmują: blokadę użycia Actor Tokenów w sposób cross-tenant przez Azure AD Graph API. Ograniczenie wystawiania tych tokenów przy użyciu poświadczeń typu Service Principal.
- Microsoft zachęca klientów do upewnienia się, że ich środowisko Entra ID jest zaktualizowane. A także, że korzystają z aktualnych API (nie deprecated), oraz by monitorować logi administracyjne.
Podobne przypadki / kontekst bezpieczeństwa
Aby pokazać, że CVE-2025-55241 nie jest odosobnionym przypadkiem:
- W tym samym czasie (2025) wielokrotnie zgłaszano luki w systemach IAM (Identity and Access Management). Szczególnie przy migracji z legacy API do nowych wersji.
- Firma Semperis wcześniej opisała lukę nazwaną „nOAuth” w Entra ID. Umożliwiała przejęcie kont przy minimalnym wysiłku, z obejściem MFA i Conditional Access.
- Badacz Dirk-jan Mollema, odkrywca tej luki, wskazuje że istnieją inne punkty słabości w architekturze Entra ID.
Rekomendacje dla użytkowników i administratorów
1. Sprawdzenie statusu aktualizacji
Pierwszym i najważniejszym krokiem jest upewnienie się, że środowisko Microsoft Entra ID działa już w wersji zabezpieczonej przez Microsoft.
- Wejdź do portalu administracyjnego Microsoft 365 / Azure i sprawdź ostatnie komunikaty bezpieczeństwa.
- Zweryfikuj, czy aktualizacje zostały wdrożone automatycznie (Microsoft zwykle robi to globalnie), ale nie zakładaj, że „na pewno się udało”.
- Jeśli masz środowiska testowe lub odseparowane instancje, upewnij się, że również tam wgrano poprawki.
Dlaczego to ważne? – aktualizacje często instalują się w tle, ale błędy w politykach czy niestandardowe konfiguracje mogą powodować, że część systemów pozostaje podatna.
2. Migracja z przestarzałych API
Jeśli Twoja organizacja wciąż korzysta z Azure AD Graph API, czas na jego wygaszenie i przejście na Microsoft Graph API.
- Azure AD Graph API jest oficjalnie deprecated (przestarzała? – jak to wytłumaczyć?) i nie otrzymuje już nowych funkcji ani pełnych łatek bezpieczeństwa.
- Migracja bywa uciążliwa (zmiany w kodzie aplikacji, konektorach, integracjach), ale jest konieczna, aby uniknąć problemów podobnych do tej luki.
- Microsoft jasno komunikuje, że Graph API to przyszłość – zarówno pod względem funkcjonalnym, jak i bezpieczeństwa.
Dla kogo? – przede wszystkim dla firm korzystających z aplikacji własnych, integracji systemów HR, CRM czy ERP z Entra ID. Jeśli używasz tylko standardowych usług M365 – najpewniej już jesteś na Graph API.
3. Audyt kont i ról
Regularny audyt to podstawa higieny bezpieczeństwa:
- Przejrzyj listę użytkowników posiadających prawa Global Admina – z zasady powinno to być maksymalnie 2–3 osoby w organizacji.
- Sprawdź konta Service Principal oraz aplikacje, które mają szerokie uprawnienia. Często tam kryją się „zapomniane” dostępy, które w rękach atakującego stają się złotą kartą wstępu.
- Usuń lub ogranicz uprawnienia kont, które nie są już używane. Dotyczy to administratorów, którzy odeszli z firmy, czy testowych aplikacji z dostępem do całego tenanta.
Praktyczna rada – stwórz cykliczny proces (np. raz na kwartał) automatycznego raportu ról i porównuj go w czasie.
4. Monitorowanie logów i alertów
Choć exploit CVE-2025-55241 był trudny do wykrycia, nie oznacza to, że monitorowanie logów nie ma sensu.
- Korzystaj z narzędzi SIEM (np. Wazuh, Sentinel, Splunk), które potrafią agregować i analizować logi w czasie rzeczywistym.
- Ustaw alerty na nietypowe działania – np. nadanie komuś roli Global Admin, rejestrację nowej aplikacji z szerokimi uprawnieniami, logowania z nietypowych lokalizacji.
- Nawet jeśli dana luka nie zostawia śladów, często pojawiają się sygnały poboczne (anomalia w ruchu, nietypowe żądania API, dziwne logowania).
Wniosek – logi to czarne skrzynki organizacji. Nawet jeśli nie uchronią przed każdym zero-day, są bezcennym źródłem dowodów w przypadku incydentu.
5. Zasada najmniejszych uprawnień (PoLP – Principle of Least Privilege)
Każdy użytkownik, aplikacja czy usługa powinna mieć tylko takie uprawnienia, jakie są niezbędne do pracy – ani jednego więcej.
- Ogranicz dostęp do danych i systemów – np. pracownik HR nie potrzebuje dostępu do zasobów IT.
- Kontroluj dostęp aplikacji serwisowych – jeśli aplikacja potrzebuje tylko odczytu listy użytkowników, nie dawaj jej pełnych praw administracyjnych.
- Regularnie weryfikuj i odbieraj zbędne role. Sytuacje, w których ktoś „na chwilę” dostaje uprawnienia admina, a później zostają mu one na stałe, to klasyczne luki w bezpieczeństwie.
Korzyść – nawet jeśli dojdzie do wycieku tokenu, skradzionych danych logowania czy błędu konfiguracyjnego, szkody będą ograniczone.
Wnioski – co to mówi o bezpieczeństwie w 2025 roku?
- Nie ma systemu idealnego – nawet najlepsze rozwiązania, używane przez miliony firm na świecie, mogą mieć krytyczne błędy.
- Zero-day to codzienność – luka była niewidoczna przez lata, aż ktoś w końcu ją odkrył. W tym czasie mogła być potencjalnie używana.
- Liczy się czas reakcji – im szybciej producent załata problem, a firma wdroży aktualizacje, tym mniejsze ryzyko.
- Bez konfiguracji i nadzoru każdy system jest zagrożony. Nawet najlepiej ustawiony firewall czy Microsoft 365 nie ochroni przed nieznanymi lukami, jeśli firma nie trzyma ręki na pulsie.
Rola BOIT – dlaczego warto mieć partnera
To właśnie w takich sytuacjach widać, po co istnieją firmy takie jak BOIT. Naszą rolą jest:
- monitorowanie na bieżąco komunikatów o lukach bezpieczeństwa,
- szybka analiza, czy dane zagrożenie dotyczy Twojej infrastruktury,
- rekomendowanie i wdrażanie aktualizacji,
- stałe audyty i testy, które pozwalają ocenić realne ryzyko.
Innymi słowy – nawet jeśli systemy same w sobie są podatne, Ty nie musisz się o to martwić. Jeśli masz partnera, który trzyma rękę na pulsie i reaguje od razu, gdy pojawia się krytyczne zagrożenie.
