Când discutăm despre securitatea identităților în cloud, un scor CVSS de 10.0 nu e ceva de ignorat; subiectul este o vulnerabilitate în Microsoft Entra ID (CVE-2025-55241) care ar fi putut permite accesul la orice tenant din lume. Descoperirea a fost făcută de cercetătorul Dirk-jan Mollema în iulie, în timp ce pregătea prezentări pentru Black Hat și DEF CON, și imediat raportată la Microsoft Security Response Center. Deși problema a fost remediată și Microsoft a implementat mitigări care blochează anumite tipuri de token-uri, detaliile evidențiază cât de aproape am fost de un dezastru la scară largă.
Vulnerabilitatea combina două elemente: token-uri de impersonare nedocumentate, numite Actor tokens, folosite intern de Microsoft pentru comunicațiile serviciu-la-serviciu, și o eroare critică în vechiul Azure AD Graph API, care nu valida corect tenantul de origine. Practic, obținând un Actor token dintr-un tenant controlat de atacator, se putea autentifica ca orice utilizator din orice alt tenant, inclusiv ca Global Admin. Aceste Actor tokens nu erau supuse politicilor de securitate precum Conditional Access, deci nu exista o setare pe care un administrator să o activeze pentru a bloca atacul.
Impactul teoretic era extrem de larg: un atac reușit ar fi oferit unui actor rău intenționat acces nelimitat la date din Entra ID, posibilitatea de a crea sau prelua conturi și de a extinde accesul către Microsoft 365 și Azure. Printre datele care ar fi putut fi compromise se numără informațiile personale ale utilizatorilor, roluri și grupuri, setările tenantului și politicile Conditional Access, aplicațiile și permisiunile acestora, dispozitivele și cheile BitLocker sincronizate cu Entra ID. Având control complet, un atacator ar fi putut crea conturi noi, acorda privilegii de administrator global și autentifica interactiv în serviciile tenantului sau adăuga credențiale la aplicații/Service Principals pentru exfiltrarea de e-mailuri sau fișiere, o tehnică deja utilizată de grupuri de amenințare.
Pașii tehnici pentru a obține compromiterea totală sunt relativ simpli și eficienți: identificarea ID-ului tenantului vizat (posibil prin API-uri publice pe baza domeniului), obținerea unui netId valid al unui utilizator obișnuit, construirea unui token de impersonare folosind Actor token-ul din tenantul atacatorului împreună cu tenant ID și netId-ul victimei, listarea Global Adminilor și a netId-urilor lor, fabricarea unui token pentru un Global Admin și apoi efectuarea de operațiuni de citire/scriere prin Azure AD Graph API. Doar modificările din pasul final ar fi generat telemetrie în tenantul victimei; restul acțiunilor ar fi putut rămâne invizibile.
Cercetarea lui Mollema și colaborarea cu Outsider Security au permis Microsoft să remedieze vulnerabilitatea și să implementeze măsuri care blochează aplicațiile de la solicitarea acestor Actor tokens pentru Azure AD Graph API. Microsoft nu raportase cazuri cunoscute de exploatare activă, ceea ce este o veste bună, dar detaliile tehnice publicate subliniază cât de periculoasă era combinația dintre token-urile necontrolate și un API legacy care nu valida corect originea cererilor.
Publicarea analizei tehnice oferă administratorilor și comunității informații precise despre mecanica atacului și vectorii utilizați. Dincolo de remedierea aplicată, cazul scoate în evidență două lecții clare: dependența continuă de API-uri legacy poate crea ferestre țintă pentru atacatori, iar mecanismele interne neaprobate sau neprotejate, precum token-urile folosite între servicii, pot deveni puncte critice dacă nu sunt documentate și supuse acelorași politici de securitate ca token-urile standard.
Microsoft Entra ID, Azure AD Graph API, Actor tokens și CVE-2025-55241 rămân termeni relevanți pentru oricine gestionează identități în cloud. Dacă administrați un tenant, merită să verificați că toate actualizările și mitigările aplicate de Microsoft sunt active și că dependențele vechi sunt migrate sau izolate. Care este opinia ta despre modul în care marile platforme gestionează riscurile asociate API-urilor vechi și mecanismelor interne de autentificare?
Fii primul care comentează