Compliant Device Bypass, allt sem þú þarft að vita

Hvað hefur gerst hingað til?

• Í desember 2024 hélt Yuya Chudo erindið „Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise" á Black Hat Europe ráðstefnunni. Í þessari lotu sýndi hann hvernig hægt er að misnota harðkóðaða og lítt þekkta undanþágu í Conditional Access (CA) fyrir device compliance í samspili við hina óskjalfestu „FOCI-Feature" í Entra ID. Í erindinu kynnti hann einnig svar Microsoft MSRC (VULN-123240) um að þessi hegðun sé með ráðum gerð og nauðsynleg fyrir árangursríka Intune Enrollment nýrra tækja.
• Nokkrum dögum eftir ráðstefnuna gaf Sunny Chau út proof-of-concept tólið TokenSmith ásamt tengdum bloggfærslum, sem gerði tæknina aðgengilega breiðari hóp.
• Að auki hefur verið gefin út PoC skrifuð í PowerShell.
• Síðan í lok desember höfum við hjá glueckkanja AG verið að rannsaka hvernig hægt er að koma í veg fyrir og greina þessa tækni. Í þessari bloggfærslu viljum við deila nokkrum af niðurstöðum okkar varðandi árásina og fjalla um mögulegar mótvægisaðgerðir og greiningaraðferðir.

TL;DR

Til eru nokkrar auðlindir með innbyggðri undanþágu frá tilteknum Grant Controls/Conditions í Conditional Access, sem leysa ákveðin vandamál. Ein þeirra er undanþága Company Portal App fyrir Device Compliance, sem leysir hænu-og-egg vandamálið við að skrá tæki í Intune áður en þau teljast compliant. Þessi hegðun er skjölfest hér. Þetta þýðir að þú getur fengið access og refresh token fyrir þetta app frá óstýrðu tæki, jafnvel þó CA policy krefjist Device Compliance fyrir „All resources"

{: .post__screenshot}

Microsoft hefur innleitt feature sem kallast Family of Client IDs (FOCI), sem gerir hópi Microsoft OAuth client forrita kleift að fá access token fyrir hvaða annan client sem er í fjölskyldunni með því að nota refresh token sitt. Þetta er hegðun sem er annars ekki leyfð í OAuth2 staðlinum. Lestu upprunalegu vinnu Secureworks til að fá nánari upplýsingar. Þar sem Company Portal App er „fjölskyldumeðlimur" er hægt að nota umbeðin Refresh Tokens fyrir hana til að fá tokens fyrir önnur öpp í fjölskyldunni.

FOCI feature er takmarkað og consent milli client id og resource verður að vera sérstaklega uppsett og veitt. Í tilviki Company Portal App hefur þetta consent verið veitt, meðal annars, fyrir aðgang að Microsoft Graph með takmörkuðu scope og að Azure AD Graph API með heimildum núverandi notanda. Þetta þýðir að Company Portal refresh token er hægt að nota til að fá til dæmis Azure AD Graph API access token með scope user_impersonation, sem gerir okkur kleift að gera margt með til dæmis AADInternals eða ROADrecon

Til að framkvæma árásina þarf árásarmaðurinn annaðhvort gild skilríki fórnarlambsins ásamt getunni til að framkvæma MFA ef Conditional Access krefst þess, eða gilt refresh token.

Hvaða áhætta og blast radius er til staðar?

Hverjar af mögulegum resources (scopes) verða fyrir áhrifum af compliance undanþágunni?

Árásarmaðurinn hefur möguleikann á að biðja um tokens fyrir annað FOCI forrit, eins og áður hefur verið lýst. Þó hefur Microsoft aðeins innleitt bypass á device compliance kröfum fyrir aðgang að tokens að tilteknum resource forritum með ýmsum API permission scope. Sérstaklega eru eftirfarandi delegated API permissions viðkvæmar og áhugaverðar fyrir árásarmenn:

Þar sem veittar heimildir eru ekki fyrir forritið sjálft, ræðst áhrifin af forréttindum þess sem hringir (notendareikningi) og af því hvaða delegated permission scopes eru heimiluð til að framkvæma API köll á scope-inu.

Skoðum nánar hversu gagnrýnisverð sýnd delegated permission scope eru og hugsanlega heimild til að kalla á viðkvæmar API-ur.

Hvaða privileges og delegated scope eru gagnrýnisverð?

Azure AD Graph API

Þetta eldra forritunarviðmót býður upp á margar API-ur til að stjórna directory stillingum og hlutum í Entra ID (Azure AD). Þetta inniheldur Conditional Access policies, directory roles, CRUD á hópum og tækjum og aðgerðir á innskráðum notanda, eins og að breyta lykilorði. Fullur listi yfir allar studdar aðgerðir er að finna í Azure AD Graph API tilvísuninni. Þessi API verður alfarið tekin úr notkun 30. júní 2025 (byggt á nýjustu tilkynningum Microsoft).

Úthlutaða delegated scope-ið „user_impersonation" leyfir forritinu (í þessu tilviki Company Portal) að koma fram fyrir hönd notandans. Þannig er hægt að nota hverja þá heimild sem innskráður notandi hefur á Entra hlut, scope eða directory-stigi, sem heimild í API köllum. Notandinn gæti verið eigandi Entra ID hlutar (forrits, hóps eða annarra hluta), eða honum gætu verið úthlutaðar heimildir í gegnum Entra ID role úthlutanir. Ef um er að ræða virkar role úthlutanir með háum privileges, myndi þetta leyfa árásarmanninum að breyta hlutum eða koma tenantinum í hættu. Að minnsta kosti, jafnvel án nokkurra privileges, er hægt að nota sjálfgefnar notendaheimildir til víðtækrar könnunar og upptalningar á directory hlutum í tenantinum.

Þess vegna ræðst sviðsmyndirnar og áhrifin af því að misnota Azure AD Graph API af virkum eða varanlega úthlutuðum privileges þess notanda sem verður fyrir áhrifum. API-ur til að fá aðgang að Microsoft 365 þjónustum (til dæmis fyrir exfiltration á OneDrive) eru ekki innifaldar í Azure AD Graph.

Microsoft Graph API

Í samanburði við Azure AD Graph er delegated scope að Microsoft Graph API takmarkað við ákveðið scope. Samhliða OpenID scopes (openid, email, profile) og grunnaðgerðum til að lesa fyrir hönd notandans (ServicePrincipalEndpoint.Read.All, User.Read).

Hægt er að skrá og lesa alla device hluti með því að kalla á „device" endpoint í Microsoft Graph með sjálfgefnum heimildum með því að nota „Device.Read.All". Þetta gæti hjálpað árásarmönnum að öðlast innsýn í device hluti.

Ef um er að ræða notanda sem hefur verið stefnt í hættu og hefur úthlutun á „Intune Administrator" eða einhverja delegation í Microsoft Intune RBAC, ættu eftirfarandi veittar delegated API permissions að teljast vandamál:

• „DeviceManagementConfiguration.Read.All"
• „DeviceManagementConfiguration.ReadWrite.All"

Þessar delegated permissions leyfa CRUD aðgerðir, til dæmis á Device Compliance og Configuration Policies, en einnig útsetningu á Management Scripts fyrir frekari illgjarna virkni á target tækjum.

Device Registration Service

Með þessari heimild getur árásarmaðurinn tengt eða skráð tæki við Entra ID. Þetta myndi aftur gera honum kleift að skrá tækið í Intune og, eftir Intune stillingum, fá gilt og compliant tæki til að fá aðgang að enn fleiri vernduðum þjónustum.

Önnur FOCI forrit

Að biðja um aðgang að öðrum privileged viðmótum, til dæmis Azure Resource Manager API, er innan sviðs FOCI og einnig áhugavert fyrir árásarmanninn. Þó er þessi resource enn varin og ekki bypassuð af Conditional Access grant control „compliant device".

Getum við greint þessa árásartækni?

Eins og lýst er hér að ofan kemur mesta áhættan frá aðgangi að MS Graph og Azure AD Graph.

Þar sem application ID Microsoft Intune Company Portal App er alltaf notað í þessu tilviki, er aðalverkefnið við að búa til greiningu að útiloka lögmæta notkun, til dæmis með device registrations, sem samkvæmt athugunum okkar felst í því hvaða resources er fyrst nálgast í session, í tilviki árásar er það venjulega MS Graph eða Azure AD Graph.

Hér er virk greining sem við prófuðum í nokkrum umhverfum af mismunandi stærðum:

Hvernig ættum við að bregðast við þegar við greinum grunsamlega virkni?

Ræstu incident response ferlið þitt með skilgreindri playbook sem inniheldur:

• Leit að grunsamlegri eða óvenjulegri virkni frá notandanum sem hefur verið stefnt í hættu
  • Yfirlit yfir non-interactive sign-in á Resource forrit, þar með talið IP tölur og UserAgents byggt á sessionId
  • Athugaðu hvort Microsoft Entra Audit Logs sýni gagnrýnisverðar aðgerðir af hálfu notandans eða IP talna (til dæmis skilríki bætt við eigin app registrations)
  • Kannaðu hvort notandinn hafi skráð tæki í viðkomandi session
  • Athugaðu Intune audit logs fyrir aðgerðir forritsins „Company Portal" og viðkomandi notanda
• Leit að tengdum alerts fyrir þau entities sem verða fyrir áhrifum
  • Fletta upp entities í AlertEvidence töflunni til að finna önnur alerts byggt á SessionId, IP tölum og notanda
• Skilgreindu mikilvægi notandans (eftir privileges) í Exposure Management
• Farðu yfir niðurstöður leitarinnar og staðfestu hvort aðgerðin hafi verið lögmæt sem hluti af device enrollment.
• Skilgreindu upphaflegan aðgangsleið og endurstilltu skilríki notenda og ef þarf tæki.

Getum við milduð árásina?

Þar sem uppsetta undanþágan er nauðsynleg fyrir Intune enrollment, er engin mótvægisaðgerð sem myndi ekki brjóta aðra hluta Microsoft 365. Ekki er hægt að afmarka eða loka fyrir aðgang að Azure AD Graph resource-num beint. Öll Conditional Access policy sem notar „Block" sem grant control mun koma í veg fyrir aðgang, en gæti haft aðrar afleiðingar.

En til að milda er mikilvægt að skilja að þessi Conditional Access bypass er ekki heildstæð árás. Þetta er tækni sem, sem eitt skref, gerir kleift ýmsar árásir.

Möguleg árásarleið gæti verið

1. Account Compromise í gegnum Phishing og AiTM
2. Conditional Access Bypass
3. Könnun með til dæmis ROADrecon, GraphRunner eða AADInternals
4. Lateral Movement, Privilege Escalation eða Persistence í gegnum nýlega skráð tæki sem skráð er í Intune

Þar sem við getum ekki milduð Conditional Access bypassinn án þess að brjóta Intune enrollment, er meira en skynsamlegt að innleiða mótvægisaðgerðir á öðrum skrefum árásarleiðarinnar og einnig innleiða skynsamlegar greiningar.

Til að draga úr líkum og áhrifum leggjum við til að auka styrk annarra stýringa og innleiða eftirfarandi fljótlega:

• Framfylgdu MFA fyrir „All Users" og „All Cloud Apps" í gegnum Conditional Access. Ef þú framfylgir aðeins Device Compliance nægir Single Factor Authentication með þessari tækni.
• Ekki nota Device Compliance eða MFA í reglusettum þínum, framfylgdu alltaf báðum. Notkun OR myndi aldrei takmarka allan aðgang við compliant tæki, því access token með MFA í scope myndi nægja til að fá aðgang að tenantinum.
• Takmarkaðu Security Information Registration við Compliant Devices, Phishing Resistant Authentication eða TAP. Í prófunum okkar tókst okkur ekki að bypassa Device Compliance fyrir Security Info Registration.
• Krefstu Phishing Resistant Authentication eða TAP fyrir Join eða Register Devices. Án þess verður hægt að skrá tæki með til dæmis AADInternals og þessari tækni.
• Krefstu MFA og „Sign-in frequency every time" fyrir Microsoft Intune Enrollment. Þetta takmarkar þann tímaramma sem árásarmaður gæti notað fersk skilríki til að skrá nýtt tæki í Intune.

  🚧 Varúð: Sign-in frequency every time = á fimm mínútna fresti Microsoft gerir ráð fyrir fimm mínútum af clock skew þegar „every time" er valið í conditional access policy, þannig að notendur fái ekki prompt oftar en einu sinni á fimm mínútna fresti.

• Lokaðu á personally owned devices í Intune Enrollment takmörkunum. Án þessara takmarkana gæti árásarmaður skráð nýtt tæki og fengið aukna fótfestu.
• Stilltu device compliance á að falla þegar engin compliance policy er úthlutað á tæki í Intune. Sjálfgefið telst hvert tæki compliant, jafnvel þó engin policy sé í raun beitt. Breyttu þessu og gerðu device compliance policy að skilyrði.

Til lengri tíma litið viljum við hvetja þig til að fjárfesta í útbreiðslu password-less, phishing-resistant authentication eins og Windows Hello for Business og Passkeys (þar á meðal Platform Credentials með macOS Platform SSO). Þetta gerir þér kleift að framfylgja phishing resistant authentication í kjölfarið og loka fyrir AiTM árásir. Í stað lykilorðs skaltu leyfa notkun Temporary Access Pass (TAP) fyrir takmarkaðan tíma og sviðsmyndir, til dæmis onboarding á nýjum tækjum eða starfsfólki. Til að styðja notkun TAPs fyrir ýmsar notkunartilvik höfum við byggt MyWorkID.

Samantekt

Conditional Access sem Zero Trust vél Entra ID er í sjálfu sér þegar flókin. Innbyggðar undanþágur sem Microsoft bætir við í bakenda Entra gera það enn erfiðara fyrir marga að skilja áhrif policies og verndar. Samt heldur hugmyndin um Zero Trust og defense in depth velli.

Device compliance policy kemur í veg fyrir flestar AiTM árásir og multi-factor authentication gerir árásarmönnum erfiðara fyrir að misnota lekin eða á annan hátt hættuleg skilríki.

Þessar öryggisráðstafanir verða allar að nota saman og ekki eina í stað annarrar. Þetta tryggir öruggt umhverfi, jafnvel þó eitt varnarlagið sé átt við eða yfirstigið.

Við mælum eindregið með að innleiða veittu greininguna í Microsoft Defender XDR til að tryggja greiningu á hugsanlegri misnotkun. Gakktu úr skugga um að SOC þinn sé tilbúinn að rannsaka slík atvik og sjáðu þeim fyrir nauðsynlegum playbooks.