Amikor az unalom veszélyt szül
Unalmas dokumentációírás közben ráakadtam egy aka.ms linkre. Ezek a rövidítők minden Microsoft-dolgozó számára ismerősek, hiszen vállalati szinten is használják őket. Eszembe jutott, mi történik, ha egyszerűen meglátogatom magát az aka.ms címet? Egy bejelentkezési oldal fogadott, vélhetően dolgozóknak. Természetesen, a saját fiókommal nem engedett be – tenanton belüli azonosítás szükséges hozzá.
De kicsit tovább ásva egy másik érdekes linket találtam az eng.ms domainen. Ismét egy bejelentkező oldal, ahol – meglepő módon – már lehetőségem volt a saját Microsoft 365 fiókommal belépni. Egy engedélyezési ablak jelent meg, hogy engedélyt kérek az adataimhoz. Elfogadtam, majd egy 500-as hibakód jelent meg, de legalább valameddig bejutottam. Ez viszont felkeltette az érdeklődésemet: hova vezet, ha tovább kísérletezem?
Bejutás a Microsoft Engineering Hubba
Subdomain-vadászatba kezdtem az eng.ms-nél, míg rá nem bukkantam a rescue.eng.ms-re. Újabb bejelentkezés, újabb engedélyezési ablak, és most végleg bent vagyok. A képernyő tetején ott volt a saját nevem – egyértelmű jele annak, hogy nem kellene itt lennem. Az Engineering Hub belső mérnöki portál, rengeteg belső dokumentummal és információval. Egy rutinvizsgálat során több mint 13 ezer jelszavas találat bukkant fel, mind belső leírásokból.
Ezen a ponton léptem vissza, és jelentettem a hibát a Microsoft Security Response Centre-nek – de addigra már tudtam, hogy ez a hibás konfiguráció akár más rendszereiket is érintheti.
Multi-tenant alkalmazások veszélyei
Entra ID-ben alkalmazásokat regisztrálnak, amelyek lehetnek single-tenantek (csak a saját szervezetből engednek belépést) vagy multi-tenantek (több tenantból is fogadnak felhasználókat). Utóbbiak különösen kockázatosak lehetnek, mert – helytelenül beállítva – bárki beléphet akár személyes Microsoft-fiókkal is.
Az Engineering Hub is multi-tenant alkalmazás volt, így a rendszer nem ellenőrizte, hogy jogosult vagyok-e. A hitelesítési folyamat során az alkalmazás a /common végpontra irányított, ahol az én tenantom bocsátotta ki a belépési tokenemet. Így beléptetett, de maga az alkalmazás soha nem ellenőrizte, hogy a token jogosult-e ténylegesen a rendszerhez.
Nem hagyható figyelmen kívül, hogy a fejlesztők gyakran nem is sejtik, hogy multi-tenant mód van beállítva; ilyenkor a /common vagy /organizations autentikációs végpont enged be akárkit a saját tenantjából.
A Microsoft támadási felületének feltérképezése
Kicsit továbbmentem: több tízezer Microsoft-hoz köthető subdomaint vizsgáltam (microsoft.com, azure.com, office.com stb.). Összesen 1406 alkalmazás használt Entra ID-t, ezek közül 176 volt multi-tenant.
Sok alkalmazásnál a fejlesztők összekeverték a single-tenant megoldást, és beállították a / végpontot, miközben az alkalmazás maga multi-tenant maradt. Így egy egyszerű konfigurációs hiba miatt szélesre tárult a vállalati környezet ajtaja.
Korábbi kutatások is igazolták: ha multi-tenant alkalmazásnál az autentikációs url-t vagy végpontot módosítod (például Burp Suite-tel), a saját tenantodból kiadott belépési tokennel léphetsz be. Mégis, több alkalmazás kért plusz jóváhagyást vagy hozzáférési engedélyt bizonyos belső erőforrásokhoz, amit különféle skriptekkel meg lehetett kerülni; így minden multi-tenant alkalmazást egyesével tesztelhettem.
Belső Microsoft alkalmazások kompromittálása
Összesen 22 belső Microsoft-alkalmazáshoz férhettem hozzá. Ezek között volt kockázatnyilvántartó, Security Intelligence Platform, Service Principal- és felhasználókereső, logfile-okban Authorization Code-ok, vagy épp licence-generáláshoz szükséges privát kulcs részletek.
Kiemelhető még a Média Létrehozó szolgáltatás (Media Creation), amelyen keresztül licencekulcs-generálásra, sőt akár távoli kódfuttatásra (RCE) is lehetőség adódott egy fejlesztői eszköz manipulációján keresztül.
További rendszerek: Engage ACE Hub, Responsible AI Ops Platform, Microsoft Internal Billing Account (BAMI), CPET webszolgáltatás, HxSDK dokumentáció, Hardverleltár API, Elektronikus Címkézés menedzsment, minőségellenőrző, Bing Ads diagnosztika, Secure Devices Portal, Azure előfizetés-hub, stb.
Ebből adódóan már egyetlen helytelen beállítás egy ekkora szervezetben beláthatatlan következményekkel járhat.
Mit tehetsz – és veszélyben vagy-e?
A sebezhetőség napjainkban is létezik: a saját ügyfeleim 2%-ánál is találtam hasonló hibákat. A legfontosabb tanulságok:
- Csak akkor használj multi-tenant alkalmazásokat, ha tényleg muszáj!
- Ha mégis, az alkalmazás logikájában mindig ellenőrizd a tokenben az iss (issuer) vagy tid (tenant ID) értékét!
Ehhez gyors PowerShell-szkript is készült, amellyel néhány másodperc alatt felmérheted saját Entra környezeted potenciálisan sebezhető alkalmazásait.
Jutalom vagy csalódás?
2024 novemberében négy esetet jelentettem a MSRC-nek, majd 2025 januárjára további 17 alkalmazást fedeztem fel. Harmadik helyet értem el a versenyben – a díjazás összesen… hát, semmi jelentős. Viszont a Reward Support Tool alkalmazás tesztelésekor egy vicces menüpont fogadott: egyszerűen bármelyik PayPal-fiókra lehetne kifizetést indítani – legalább szimbolikusan megmaradt az „végtelen pénz hiba” (infinite money glitch).
