Compliant Device Bypass: kaikki olennainen

Mitä tähän mennessä on tapahtunut?

• Joulukuussa 2024 Yuya Chudo piti esityksensä “Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise” Black Hat Europe -konferenssissa. Esityksessä hän näytti, kuinka laitteiden vaatimustenmukaisuutta koskevaa, harvoin tunnettua kovakoodattua poikkeusta Conditional Accessissa (CA) voi käyttää väärin yhdessä Entra ID:n dokumentoimattoman “FOCI-ominaisuuden” kanssa. Esityksessä hän esitteli myös Microsoftin MSRC:n vastauksen (VULN-123240), jonka mukaan tämä toiminta on tarkoituksellista ja välttämätöntä uusien laitteiden onnistuneelle Intune-liittämiselle (Enrollment).
• Muutama päivä konferenssin jälkeen Sunny Chau julkaisi proof-of-concept-työkalun TokenSmith sekä siihen liittyvän blogikirjoituksen, mikä teki tekniikasta laajemman yleisön saatavilla olevan.
• Lisäksi on julkaistu PowerShellillä kirjoitettu PoC.
• Joulukuun lopusta lähtien me glueckkanja AG:llä olemme tutkineet, kuinka tämän tekniikan voi estää ja tunnistaa. Tässä blogikirjoituksessa haluamme jakaa näkemyksiämme hyökkäyksestä ja käsitellä torjunta- ja tunnistusvaihtoehtoja.

TL;DR

Conditional Accessissa on tiettyjen ongelmien ratkaisemiseksi joitakin resursseja, joihin on sisäänrakennettu poikkeus tiettyihin Grant Controls -kontrolleihin tai ehtoihin. Yksi näistä on Company Portal -sovelluksen poikkeus laitteiden vaatimustenmukaisuudesta, mikä ratkaisee muna-kana-ongelman: laitteet on saatava liitettyä Intuneen ennen kuin niitä pidetään vaatimustenmukaisina. Tämä toiminta on dokumentoitu tässä. Tämä tarkoittaa, että voit saada tämän sovelluksen access- ja refresh-tokenit hallitsemattomalta laitteelta, vaikka CA-käytäntö pakottaisi laitteen vaatimustenmukaisuuden kaikille resursseille (“All resources”).

{: .post__screenshot}

Microsoft on toteuttanut ominaisuuden nimeltä Family of Client IDs (FOCI), joka sallii Microsoftin OAuth-asiakassovellusten ryhmän hankkia access-tokeneita minkä tahansa muun perheen jäsenen puolesta niiden refresh-tokenin avulla. Tämä on toiminta, jota OAuth2-standardi ei muutoin salli. Lue Secureworksin alkuperäinen työ saadaksesi lisätietoja. Koska Company Portal -sovellus on “perheenjäsen”, sille pyydettyjä refresh-tokeneita voidaan käyttää tokenien hankkimiseen muille perheen sovelluksille.

FOCI-ominaisuus on rajattu, ja asiakas-id:n ja resurssin välinen suostumus (consent) on määritettävä ja myönnettävä nimenomaisesti. Company Portal -sovelluksen tapauksessa tämä suostumus on myönnetty muun muassa Microsoft Graphin käyttöön rajoitetulla scopella sekä Azure AD Graph API:in nykyisen käyttäjän oikeuksilla. Tämä tarkoittaa, että Company Portalin refresh-tokenia voidaan käyttää esimerkiksi Azure AD Graph API:n access-tokenien hankkimiseen scopella user_impersonation, mikä mahdollistaa monenlaisia toimia esimerkiksi AADInternalsin tai ROADreconin avulla.

Hyökkäyksen toteuttamiseksi hyökkääjä tarvitsee joko uhrin voimassa olevat tunnistetiedot sekä kyvyn suorittaa MFA, jos Conditional Access sitä edellyttää, tai voimassa olevan refresh-tokenin.

Mikä riski ja vaikutusalue tähän liittyy?

Mihin mahdollisista resursseista (scopeista) vaatimustenmukaisuuden poikkeus vaikuttaa?

Hyökkääjällä on mahdollisuus pyytää tokeneita toiselle FOCI-sovellukselle, kuten edellä on kuvattu. Microsoft on kuitenkin toteuttanut laitteiden vaatimustenmukaisuusvaatimuksen ohituksen vain tiettyjen resurssisovellusten eri API-oikeuksien scopejen tokenien käyttöä varten. Erityisesti seuraavat delegoidut API-oikeudet ovat arkaluonteisia ja hyökkääjiä kiinnostavia:

Koska myönnetyt oikeudet eivät koske itse sovellusta, vaikutus riippuu kutsujan (käyttäjätilin) oikeuksista ja siitä, mitkä delegoidut oikeus-scopet on valtuutettu suorittamaan API-kutsuja kyseisellä scopella.

Tarkastellaan lähemmin näytettyjen delegoitujen oikeus-scopejen kriittisyyttä ja mahdollista valtuutusta kutsua arkaluonteisia API-rajapintoja.

Mitkä oikeudet ja delegoidut scopet ovat kriittisiä?

Azure AD Graph API

Tämä vanha ohjelmointirajapinta tarjoaa monia API-rajapintoja Entra ID:n (Azure AD) hakemistoasetusten ja -objektien hallintaan. Tähän kuuluvat Conditional Access -käytännöt, hakemistoroolit, ryhmien ja laitteiden CRUD-operaatiot sekä kirjautuneeseen käyttäjään kohdistuvat toiminnot, kuten salasanan vaihto. Täydellinen lista kaikista tuetuista operaatioista löytyy Azure AD Graph API -referenssistä. Tämä API poistuu kokonaan käytöstä 30. kesäkuuta 2025 (Microsoftin viimeisimpien ilmoitusten mukaan).

Määritetty delegoitu scope “user_impersonation” sallii sovelluksen (tässä tapauksessa Company Portal) toimia käyttäjän puolesta. Näin jokaista oikeutta, joka kirjautuneella käyttäjällä on Entra-objektiin, scopeen tai hakemistotasolle, voidaan käyttää valtuutuksena API-kutsuissa. Käyttäjä voi olla Entra ID -objektin (sovelluksen, ryhmän tai muun objektin) omistaja, tai hänelle on voitu myöntää oikeuksia Entra ID -roolimääritysten kautta. Aktiivisten korkeasti valtuutettujen roolimääritysten tapauksessa tämä sallisi hyökkääjän muokata objekteja tai vaarantaa koko tenantin. Vähintäänkin, jopa ilman mitään oikeuksia, käyttäjän oletusoikeuksia voidaan käyttää hakemisto-objektien laajaan tiedusteluun ja luettelointiin tenantissa.

Näin ollen Azure AD Graph API:n väärinkäytön skenaariot ja vaikutus riippuvat kohteena olevan käyttäjän aktiivisista tai pysyvistä oikeuksista. API-rajapinnat Microsoft 365 -palveluihin (esimerkiksi OneDriven eksfiltraatioon) eivät sisälly Azure AD Graphiin.

Microsoft Graph API

Azure AD Graphiin verrattuna Microsoft Graph API:n delegoitu scope on rajattu tiettyyn laajuuteen. OpenID-scopejen (openid, email, profile) ja käyttäjän puolesta tehtävien perustason lukutoimintojen (ServicePrincipalEndpoint.Read.All, User.Read) ohella.

Kaikkien laiteobjektien listaus ja luku onnistuu kutsumalla Microsoft Graphin “device”-endpointia oletusoikeuksilla käyttämällä oikeutta “Device.Read.All". Tämä voi auttaa hyökkääjiä saamaan tietoa laiteobjekteista.

Jos vaarantuneelle käyttäjälle on määritetty “Intune Administrator” -rooli tai mikä tahansa delegointi Microsoft Intunen RBAC:ssa, seuraavia myönnettyjä delegoituja API-oikeuksia tulisi pitää ongelmallisina:

• ”DeviceManagementConfiguration.Read.All”
• “DeviceManagementConfiguration.ReadWrite.All”

Nämä delegoidut oikeudet mahdollistavat CRUD-operaatiot esimerkiksi laitteiden vaatimustenmukaisuus- ja konfiguraatiokäytännöille, mutta myös hallintaskriptien käyttöönoton kohdelaitteilla lisähaitallista toimintaa varten.

Device Registration Service

Tällä oikeudella hyökkääjä voi liittää tai rekisteröidä laitteen Entra ID:hen. Tämä puolestaan sallisi hänen jopa liittää laitteen Intuneen ja Intune-konfiguraatiosta riippuen saada voimassa olevan ja vaatimustenmukaisen laitteen, jolla päästä käsiksi vieläkin suojatumpiin palveluihin.

Muut FOCI-sovellukset

Pääsyn pyytäminen muihin valtuutettuihin rajapintoihin, esimerkiksi Azure Resource Manager API:in, kuuluu FOCI:n piiriin ja kiinnostaa hyökkääjää. Tämä resurssi on kuitenkin edelleen suojattu, eikä sen kohdalla ohiteta Conditional Accessin “compliant device” -grant controlia.

Voimmeko tunnistaa tämän hyökkäystekniikan?

Kuten edellä on kuvattu, suurin riski liittyy pääsyyn MS Graphiin ja Azure AD Graphiin.

Koska tässä tapauksessa käytetään aina Microsoft Intune Company Portal -sovelluksen application ID:tä, tunnistuksen luomisen päätehtävänä on sulkea pois laillinen käyttö, kuten laiterekisteröinnit. Havaintojemme mukaan tämä ero näkyy siinä, mihin resursseihin istunnossa ensin päästään käsiksi → hyökkäyksen tapauksessa yleensä MS Graphiin tai Azure AD Graphiin.

Tässä on toimiva tunnistus, jonka olemme testanneet useissa eri kokoisissa ympäristöissä:

Kuinka meidän tulisi reagoida havaitessamme epäilyttävää toimintaa?

Käynnistä incident response -prosessisi määritellyn playbookin avulla, joka sisältää:

• Vaarantuneen käyttäjän epäilyttävän tai poikkeavan toiminnan etsintä (hunting)
  • Yhteenveto ei-interaktiivisista kirjautumisista resurssisovelluksiin, mukaan lukien IP-osoitteet ja UserAgentit sessionId:n perusteella
  • Tarkista, näkyykö Microsoft Entran auditlokeissa käyttäjän tai IP-osoitteiden tekemiä kriittisiä operaatioita (esimerkiksi tunnistetietojen lisääminen omistettuihin sovellusrekisteröinteihin)
  • Selvitä, onko käyttäjä rekisteröinyt laitteita kyseisessä istunnossa
  • Tarkista Intunen auditlokeista “Company Portal” -sovelluksen ja kyseisen käyttäjän tekemät operaatiot
• Kyseisiin entiteetteihin liittyvien hälytysten etsintä
  • Hae entiteettejä AlertEvidence-taulusta tunnistaaksesi muita hälytyksiä SessionId:n, IP-osoitteiden ja käyttäjän perusteella
• Määritä käyttäjän kriittisyys (oikeuksien perusteella) Exposure Managementissa
• Käy läpi huntingin tulokset ja varmista, oliko toiminta laillista osana laitteen liittämistä.
• Tunnista alkuperäinen hyökkäysvektori ja nollaa käyttäjän tunnistetiedot ja tarvittaessa laitteet.

Voimmeko torjua hyökkäyksen?

Koska määritetty poikkeus on välttämätön Intune-liittämiselle, ei ole olemassa torjuntakeinoa, joka ei rikkoisi muita Microsoft 365:n osia. Pääsyä Azure AD Graph -resurssiin ei voi rajata scopeilla tai estää suoraan. Mikä tahansa Conditional Access -käytäntö, jossa grant controlina on “Block”, estää pääsyn, mutta sillä voi olla muita seurauksia.

Torjunnan kannalta on kuitenkin olennaista ymmärtää, että tämä Conditional Access -ohitus ei ole täydellinen hyökkäys. Se on tekniikka, joka yhtenä vaiheena mahdollistaa joukon hyökkäyksiä.

Hyökkäyspolku voisi olla

1. Tilin vaarantaminen phishingin ja AiTM:n avulla
2. Conditional Accessin ohitus
3. Tiedustelu esimerkiksi ROADreconin, GraphRunnerin tai AADInternalsin avulla
4. Sivuttaisliike (lateral movement), oikeuksien laajentaminen tai pysyvyys (persistence) Intuneen liitetyn, juuri rekisteröidyn laitteen kautta

Koska emme pysty torjumaan Conditional Accessin ohitusta rikkomatta Intune-liittämistä, on enemmän kuin perusteltua toteuttaa torjuntatoimet hyökkäyspolun muissa vaiheissa ja ottaa käyttöön järkevät tunnistukset.

Todennäköisyyden ja vaikutuksen pienentämiseksi suosittelemme muiden kontrollien vahvistamista ja seuraavien toteuttamista pian:

• Pakota MFA kaikille käyttäjille (“All Users”) ja kaikille pilvisovelluksille (“All Cloud Apps”) Conditional Accessin kautta. Jos pakotat vain laitteen vaatimustenmukaisuuden, yksivaiheinen todennus riittää tällä tekniikalla.
• Älä käytä säännöissäsi laitteen vaatimustenmukaisuutta tai MFA:ta erikseen, pakota aina molemmat. OR-ehdon käyttö ei koskaan rajaisi kaikkea pääsyä vaatimustenmukaiseen laitteeseen, koska access-token, jonka scopessa MFA on, riittäisi pääsyyn tenantiin.
• Rajaa Security Information -rekisteröinti vaatimustenmukaisiin laitteisiin, phishing-kestävään todennukseen tai TAP:iin. Testeissämme emme onnistuneet ohittamaan laitteen vaatimustenmukaisuutta Security Info -rekisteröinnissä.
• Vaadi phishing-kestävää todennusta tai TAP:ia laitteiden liittämiseen tai rekisteröintiin. Ilman sitä laitteen voi rekisteröidä esimerkiksi AADInternalsilla ja tällä tekniikalla.
• Vaadi MFA ja “Sign-in frequency every time” Microsoft Intune -liittämiseen. Tämä rajoittaa ajanjaksoa, jonka aikana hyökkääjä voisi käyttää tuoreita tunnistetietoja uuden laitteen liittämiseen Intuneen.

  🚧 Varoitus: Sign-in frequency every time = joka viides minuutti Microsoft huomioi viiden minuutin kelloheiton, kun Conditional Access -käytännössä valitaan “every time”, jotta käyttäjiä ei pyydetä todentautumaan useammin kuin kerran viidessä minuutissa.

• Estä henkilökohtaisesti omistetut laitteet Intunen liittämisrajoituksissa. Ilman näitä rajoituksia hyökkääjä voisi liittää uuden laitteen ja saada lisäjalansijaa.
• Aseta laitteen vaatimustenmukaisuus epäonnistumaan, kun laitteelle ei ole määritetty yhtään vaatimustenmukaisuuskäytäntöä Intunessa. Oletuksena jokaista laitetta pidetään vaatimustenmukaisena, vaikka mitään käytäntöä ei todellisuudessa sovellettaisi. Muuta tämä ja tee laitteen vaatimustenmukaisuuskäytännöstä pakollinen.

Pidemmällä aikavälillä kannustamme sinua panostamaan salasanattoman, phishing-kestävän todennuksen käyttöönottoon, kuten Windows Hello for Business ja Passkeys (mukaan lukien Platform Credentials macOS Platform SSO:n avulla). Näin voit myöhemmin pakottaa phishing-kestävän todennuksen ja estää AiTM-hyökkäykset. Salasanan sijaan salli Temporary Access Passin (TAP) käyttö rajatun ajan ja rajatuissa tilanteissa, esimerkiksi uusien laitteiden tai työntekijöiden käyttöönotossa. Tukeaksemme TAP:ien käyttöä erilaisissa käyttötapauksissa olemme rakentaneet MyWorkID:n.

Yhteenveto

Conditional Access on Entra ID:n Zero Trust -moottorina jo itsessään monimutkainen. Microsoftin Entran taustajärjestelmään lisäämät sisäänrakennetut poikkeukset tekevät monille vielä vaikeammaksi ymmärtää käytäntöjen ja suojausten vaikutusta. Silti Zero Trustin ja syvyyssuuntaisen puolustuksen (defense in depth) ajatus pitää edelleen.

Laitteen vaatimustenmukaisuuskäytäntö estää suurimman osan AiTM-hyökkäyksistä, ja monivaiheinen todennus tekee vuodettujen tai muuten vaarantuneiden tunnistetietojen väärinkäytön hyökkääjälle vaikeammaksi.

Kaikkia näitä turvatoimia on käytettävä yhdessä, ei toista toisen sijaan. Näin varmistat turvallisen ympäristön, vaikka yhtä puolustuskeinoa peukaloitaisiin tai se murrettaisiin.

Suosittelemme vahvasti annetun tunnistuksen käyttöönottoa Microsoft Defender XDR:ssä, jotta mahdollinen väärinkäyttö tunnistetaan. Varmista, että SOC:si on valmis tutkimaan nämä tapaukset, ja anna heille tarvittavat playbookit.