AuthCodeFix aka ConsentFix

Kuten perinteeksi on muodostunut aivan vuoden lopussa, esiin nousee uusi haavoittuvuus tai näppärä hyökkäysvektori, ja puolustajat jäävät yrittämään käyttäjiensä suojaamista. Samaan aikaan muut hyökkääjät ja red teamit seuraavat tilannetta tarkasti ja mukauttavat toimintaansa.

Tänä vuonna PushSecurity havaitsi hyökkäyksen, jolle he antoivat nimen "ConsentFix". Se on ClickFix-hyökkäyksen kehittyneempi muoto, joka nojaa siihen, että käyttäjä toimittaa hyökkääjälle URI:n, joka käytännössä luovuttaa avaimet koko Entra-valtakuntaan. Luonnossa käytetty menetelmä vaati toimiakseen, että käyttäjä kopioi ja liittää tiedon käsin. Muutamassa päivässä John Hammond julkaisi videon, jossa hän esitteli hyökkäyksestä parannellun version, joka ei enää vaatinut kopiointia ja liittämistä, vaan käyttäjä saattoi yksinkertaisesti raahata auth-koodinsa hyökkääjälle.

Kun tarkastelemme teknisiä yksityiskohtia siitä, miksi tämä hyökkäys toimii ja näennäisesti ohittaa laitteiden vaatimustenmukaisuuden sekä muut Conditional Access -vaatimukset, päädymme OAuth 2.0:n authorization code -flowhun.

Hyökkääjä luo Microsoft Entra -kirjautumis-URI:n, joka kohdistuu "Microsoft Azure CLI" -clientiin ja "Azure Resource Manager" -resurssiin, ja avaa tämän URI:n, kun käyttäjä vierailee haitallisella verkkosivustolla.

Authorization code -flowhun kartoitettuna tämä vastaa ensimmäistä vaihetta, jonka natiivi julkinen sovellus kuten Azure CLI normaalisti kutsuisi todentaakseen käyttäjän. Sovellus luo kuuntelijan koneelle, jolla se suoritetaan, satunnaiseen korkeaan porttiin. Tätä porttia käytetään niin sanottuna reply URI:na.

Voit helposti toistaa tämän itse esimerkiksi käyttämällä TokenTacticsV2:ta tai muotoilemalla URI:n käsin.

Kun käyttäjä on onnistuneesti kirjautunut Entra ID:hen, hänet ohjataan reply URI:hin, esim. http://localhost:3001. Normaalitilanteessa Azure CLI hyväksyisi nyt kutsun tähän URI:hin ja saisi tärkeät ja kriittiset tiedot, jotka ovat osa uudelleenohjausta:

• code
  Tämä on authorization_code, jonka sovellus käyttää bearer-tokenin pyytämiseen. Token koostuu access- ja ID-tokenista sekä valinnaisesti refresh-tokenista.
  Dokumentaation mukaan tämä koodi on voimassa noin 10 minuuttia ja se on lunastettava tämän ajan kuluessa.
• state
  Tämä on valinnainen parametri, ja sovelluksen tulisi tarkistaa, onko se identtinen pyynnössä ja vastauksessa.

Hyökkäystilanteessa käyttäjä ohjataan myös uudelleen, mutta koska localhostissa ei ole sovellusta käynnissä, selain kohtaa virheen.

URI sisältää kuitenkin edelleen arkaluontoiset tiedot, ja juuri tämän hyökkääjä haluaa käyttäjän hänelle toimittavan. Jos käyttäjä suostuu, hyökkääjä lunastaa nyt token-materiaalin ja voi sen jälkeen käyttää access- ja refresh-tokenia päästäkseen resurssiin, tässä tapauksessa Azure Resource Manageriin.

Tässä kuvakaappauksessa näet, miten bearer-token noudetaan käyttäjän toimittaman URI:n avulla.

Jos haluat testata havaitsemismenetelmiäsi, varmista, että suoritat viimeisen vaiheen eri järjestelmästä ja eri verkosta.

Havaitsemisen jäljet

Kun toistat hyökkäyksen ja tarkistat SigninLogs- ja AADNonInteractiveUserSignInLogs-lokit, näet kaksi tapahtumaa tälle yhdelle kirjautumistoiminnolle. Ensimmäinen tapahtuma edustaa varsinaista käyttäjän kirjautumista, kun taas toinen on peräisin hyökkääjän infrastruktuurista.

Suuri ero on siinä, että ensimmäinen tapahtuma on interaktiivinen kirjautumistapahtuma, kun taas toinen on ei-interaktiivinen. Tämä vastaa todennus-flow'n kahta vaihetta: ensin käyttäjä, sitten sovellus tai meidän tapauksessamme hyökkääjä.

Azure CLI:n normaali käyttäytyminen olisi, että molemmat kirjautumistapahtumat ovat peräisin samasta IP-osoitteesta. Meidän tapauksessamme IP-osoitteet ovat kuitenkin erilaiset ja peräisin eri maista. Jälkimmäinen ei tietenkään ole luotettava indikaattori, sillä hyökkääjä voisi oleskella samassa maassa kuin uhri peittääkseen jälkensä.

Puuttuva linkki

Kun etsimme hyvää tapaa yhdistää nämä kaksi tapahtumaa, luonteva ensimmäinen ajatus oli tarkistaa Unique Token Identifier (UTI). Microsoft käyttää kuitenkin eri arvoja authorization coden UTI:lle ja bearer-tokenin UTI:lle, joten tämä lähestymistapa ei toimi luotettavana linkkinä.

SessionId on kuitenkin hyvä linkki näiden kahden välillä, joskin se on pitkäkestoinen tunniste ja voi sisältää useita tällaisia tapahtumayhdistelmiä, myös legitiimejä.

Kun lisätietona on auth code -flow'n rajoitukset sekä käyttäjä- ja sovellustunniste lisälinkkeinä, voit käyttää aikaa tärkeänä havaitsemistekijänä:

• Molemmilla tapahtumilla on sama SessionId
• Molemmilla tapahtumilla on sama ApplicationId
• Molemmilla tapahtumilla on sama UserId
• Toisen tapahtuman on oltava ensimmäisen tapahtuman jälkeen
• Toisen tapahtuman on oltava noin 10 minuutin aikaikkunassa ensimmäisen tapahtuman jälkeen. Älä käytä tasan 10 minuuttia, sillä Microsoft kirjoittaa "[...] they expire after about 10 minutes"
• Ota huomioon vain aivan seuraava toinen tapahtuma, ei myöhempiä

Hauska fakta
ResourceIdentity ei ole hyvä linkki, sillä hyökkääjä voi vaihtaa resurssia, koska sitä ei ole sidottu auth-koodiin. Kohteena olevaa application ID:tä ei voi vaihtaa.

Kohinan vähentäminen

Tämä tieto tarjosi meille jo hyvin toimivan havaitsemismenetelmän, mutta joukossa oli myös hyvänlaatuisia osumia (benign positives). Nykyaikaiset kehittäjät käyttävät pilviresursseja, jotka näyttävät paikallisilta instansseilta mutta johtavat epäsäännöllisiin kirjautumiskuvioihin lokeissa.

Keskeinen ero on aikakomponentti. Siinä missä hyökkäys vaatii käyttäjän toimintaa URI:n kopioimiseksi ja liittämiseksi tai raahaamiseksi, tunnistamamme GitHub Codespace -käyttötapaus, joka oli hyvänlaatuisten hälytysten lähde, on täysin automatisoitu ja lunastaa auth-koodin muutamassa sekunnissa.

Näin ollen kaikki, mikä suorittaa tämän todennustanssin muutamassa sekunnissa, voidaan mitä todennäköisimmin suodattaa pois hyvänlaatuisena.

Toinen kohinan lähde voivat olla internet-liikenteesi vaihtuvat ulostulopisteet (egress), erityisesti SD-WAN-, ZTNA- tai Secure Web Gateway -ympäristöissä.

Kohteena olevat first-party-sovellukset

Vaikka alkuperäinen raportti näyttää väärinkäytettynä sovelluksena "Microsoft Azure CLI":n, jokaisessa tenantissa on paljon erilaisia Microsoftin first-party-sovelluksia, joilla on pre-consent ja jotka tarjoavat localhostin uudelleenohjauksena. Eivätkä vain ne ole kohteina. Hyökkääjä voisi väärinkäyttää myös reply-, testi- ja dev-URL-osoitteita, jotka eivät ole julkisesti selvitettävissä.

Tässä on lista huomionarvoisimmista sovelluksista, joilla on myös korkeat pre-consent-oikeudet resursseihin.

• Microsoft Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46)
• Microsoft Azure PowerShell (1950a258-227b-4e31-a9cf-717495945fc2)
• Visual Studio (04f0c124-f2bc-4f59-8241-bf6df9866bbd)
• Visual Studio Code (aebc6443-996d-45c2-90f0-388ff96faa56)
• MS Teams PowerShell Cmdlets (12128f48-ec9e-42f0-b203-ea49fb6af367)

Täydellinen lista näistä sovelluksista löytyy nyt kollegamme Fabian Baderin ylläpitämästä EntraScopes.com-palvelusta.

Torjuntatoimet ja suojaukset

Rajoita hyökkäyspintaa ja kohdeyleisöä

Vaihtoehto 1: Vaadi käyttäjämääritys (Require User Assignment)

Edellytykset:

• Lisää service principal kohteena oleville first-party-sovelluksille Microsoft Graph API:n tai PowerShellin avulla
• Aseta käyttäjämääritysvaatimus service principal -objektiin Microsoft Graph API:n tai PowerShellin avulla
• Luo prosessi, jolla käyttäjät määritetään pyynnöstä Access Packageilla, PIM-for-Groupsilla (just-in-time-käyttöä varten) tai näiden yhdistelmällä.

// Example for Microsoft Graph PowerShell
Connect-MgGraph -Identity
$AppId = "04b07795-8ddb-461a-bbee-02f9e1bf7b46" // Microsoft Azure CLI
$sp = Get-MgServicePrincipal -Filter "appId eq '$AppId'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AppRoleAssignmentRequired:$false

Hyöty:

• Mahdollistaa käyttäjämääritysten hallinnan Access Packageilla tai manuaalisella ryhmäjäsenyydellä tälle hyökkäystekniikalle altistumisen rajoittamiseksi.
• Mahdollisuus tarjota just-in-time-käyttöä yhdistettynä eligible-ryhmäjäsenyyden määritykseen, mikä sallii tilapäisen pääsyn CLI-työkaluihin ja pienentää siten hyökkäyspintaa entisestään.
• Sovelletaan ennen Conditional Access -käytäntöjen arviointia.
• Rajoittaa hyökkäyspintaa myös muissa skenaarioissa.

Haitta:

• Voidaan kohdistaa vain tiettyihin käyttäjiin, eikä sitä voi yhdistää muihin vaatimuksiin kuten tiettyjen laitteiden käyttöön
• Kaikki legitiimit CLI-työkalujen käyttäjät on tunnistettava
• Sivuvaikutukset ja organisatoriset vaikutukset on arvioitava huolellisesti tarkastelemalla aiempia kirjautumisia.

Vaihtoehto 2: Estä pääsy Conditional Access -käytännöillä

Edellytykset:

• Luo Conditional Access -käytäntö, joka estää pääsyn CLI-työkaluihin, legitiimejä käyttäjiä lukuun ottamatta, kohdistamalla se sovelluksiin "Microsoft Graph Command Line Tools" ja "Windows Azure Service Management API"
• Hallitse poikkeuksia ryhmäjäsenyyden kautta joko manuaalisesti tai entitlement management -toiminnolla (esim. Access Packages).

Hyöty:

• Estää tokenien myöntämisen ei-legitiimeille tai ei-etuoikeutetuille käyttäjille.
• Mahdollistaa tarkan kohdennuksen lisäehtojen kuten laitteen tai verkon perusteella.

Haitta:

• Kaikki legitiimit CLI-työkalujen käyttäjät on tunnistettava ja jätettävä käytännön ulkopuolelle.
• Sivuvaikutukset ja organisatoriset vaikutukset on arvioitava huolellisesti tarkastelemalla aiempia kirjautumisia ja arvioimalla käytäntö report-only-tilassa.

Estä tokenien myöntäminen authorization code -flow'n kautta

Edellytykset:

• Microsoft Entra ID P1 -lisenssit
• Entra ID Registered -laitteet, Hybrid- tai Entra ID-joined-laitteet Windows-alustalla
• Ota käyttöön Web Account Manager (WAM) Azure CLI:ssä, Azure PowerShellissä ja Microsoft Graph PowerShellissä (oletus uusimmissa versioissa)
• Määritä Conditional Access -kohdennus:
  • Cloud App -kohdennus seuraaviin sovelluksiin:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • Client apps -kohdassa Mobile apps and desktop clients vaatimaan Token Protection.
  • Valitse Windows arvoksi device platform käytännön kohdentamiseksi

Hyöty:

Microsoft Entran token protection vaatii proof‑of‑possession (PoP), joka voidaan pakottaa vain silloin, kun client kommunikoi suoraan luotetun token brokerin kuten Windowsin Web Account Managerin (WAM) kanssa. Koska selaimet eivät voi muodostaa tätä suojattua kanavaa, selaimessa käynnistetty authorization code -flow estetään token protection -käytäntöjen alaisena.

Kun käytäntö pakottaa token protectionin, joka vaatii brokerin hallinnoiman PoP:n, selaimeen palautettua authorization codea ei voi lunastaa, koska selain ei pysty tuottamaan vaadittua brokerin allekirjoittamaa todistetta code‑to‑token‑vaihdon aikana

Tässä tapauksessa AuthCodeFix-hyökkäykset torjutaan täysin niin kauan kuin sovellusta voidaan suojata Token Protectionilla.

Kuten alla olevassa kuvakaappauksessa näkyy, Token Protection torjuu onnistuneesti uhrin kalastelutoiminnan kautta käynnistämän authorization code -flow'n lunastuksen.

Haitta:

• Vain seuraavat resurssit ovat virallisesti tuettuja:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    Microsoft Graph API on epäsuorasti katettu edellä mainittujen resurssien kautta, ja Microsoft Graph PowerShell on listattu tuetuksi clientiksi. Pystyimme testeissämme varmistamaan, että tämän skenaarion hyökkäys torjutaan. "Windows Azure Service Management API" ei ole listattu tuetuksi resurssiksi. Molemmat CLI-clientit (Azure CLI ja Azure PowerShell) tukevat WAM:ia, joka on client-puolen edellytys Token Protectionin käytölle. Microsoft on ilmoittanut blogikirjoituksessa laajentavansa token protection -ominaisuuksia Azure-hallinnan skenaarioihin.
• Jotkin Microsoft Graph PowerShellin virheet pakottavat poistamaan WAM-integraation tilapäisesti käytöstä
• Sivuvaikutukset ja organisatoriset vaikutukset on arvioitava huolellisesti tarkastelemalla aiempia kirjautumisia ja arvioimalla käytäntö report-only-tilassa. Cloud app -kohdennus vaikuttaa myös tuottavuuskäyttöön Microsoft 365:ssä.
• Rajallinen kattavuus, koska saatavuus koskee vain tuettuja alustoja ja Entra ID -integroituja laitteita.

Estä tokenien lisämyöntäminen compliant network -tarkistuksella tai luotetulla verkolla

Vaihtoehto: Estä pääsy Compliant network -verkon ulkopuolelta Global Secure Accessilla

Edellytys:

• Entra ID P1 -lisenssi
• Entra ID Registered -laitteet, Hybrid- tai Entra ID-joined-laitteet Windows-, macOS-, Android- ja iOS-alustoilla
• Global Secure Access Client kaikilla kohteena olevilla clienteilla ja käyttöön otettu Entra Internet Access M365 Traffic Profile -profiilille
• Conditional Access -käytäntö verkon compliant-tarkistuksen pakottamiseksi tulisi soveltaa kaikkiin cloud app -sovelluksiin

Hyöty:

Estä tokenien lisämyöntäminen pakottamalla luotetun verkon tarkistus. Tämä torjuntatoimi varmistaa, etteivät hyökkääjät voi hankkia uusia tokeneita authorization code -flow'n refresh-tokenilla. Se ei kuitenkaan estä authorization coden alkuperäistä lunastusta eikä ensimmäisen access-tokenin myöntämistä, joka pysyy voimassa compliant-verkon ulkopuolella, koska sen pyysi alun perin uhri.

GSA:n pakottaminen Compliant Network -ehdolla estää myös muita Token Replay -skenaarioita ja tuottaa lisälokeja, jotka voivat olla erittäin hyödyllisiä havaitsemiseen ja metsästykseen.

Haitta:

• Soveltuu vain käyttäjille ja laitteille, joilla on käyttöön otettu Global Secure Access -client
• Rajallinen kattavuus, koska saatavuus koskee vain Entra ID -integroituja laitteita
• Compliant Networks -pakottaminen CA:n kautta tarvitsee joitakin poikkeuksia kuten Intunen välttääkseen muna-kana-ongelmat. Ennen käyttöönottoa tarvitaan yksityiskohtaista testausta

Metsästyskyselyt

Kun kaikki tokenvarkauden torjuntatoimien edellytykset täyttyvät, kuten GSA-clientin käyttöönotto (mukaan lukien NetworkAccessTraffic-lokien keräys) ja WAM-todennuksen hyödyntäminen, saamme lisää vaihtoehtoja uhkien metsästykseen ja varmennukseen.

GSA-lokien ja WAM-todennuksen hyödyntäminen metsästyksessä tai havaitsemistulosten luottamustason varmistamisessa

Tämä metsästyskysely hyödyntää Global Secure Accessin (GSA) NetworkAccessTraffic-lokeja, jotka sisältävät Microsoft Entran token-endpointin kanssa käytävän kommunikaation käynnistävän prosessin. Tämä auttaa selvittämään, onko token-pyyntö peräisin suoraan selaimesta ja tehtiinkö lisää token-pyyntöjä GSA-verkon ulkopuolella.

Tämä kysely toimii ja tuottaa luotettavia tuloksia vain, kun edellytykset täyttyvät; muutoin se johtaa korkeaan väärien positiivisten osumien määrään.

Miksi tällä on merkitystä: Kun kirjaudutaan CLI:n tai PowerShell-moduulien kautta käyttäen Web Account Manageria (WAM) Windows-laitteilla, flow ei sisällä selainpohjaista authorization codea. Tämä kirjautumiskäyttäytyminen on oletus uusimmassa versiossa. Näin ollen, jos käynnistävä prosessi on selaimen suoritettava tiedosto (esim. msedge.exe), tämä on vahva indikaattori epäilyttävästä toiminnasta. macOS:ssä prosessin käynnistää Company Portal -sovellus (com.microsoft.CompanyPortalMac.ssoextension), kun käytetään Platform SSO:ta.

Token Binding ja PoP: WAM-todennus sitoo tokenit tyypillisesti laitteeseen pakottamalla Proof-of-Possessionin (PoP). Hyökkääjät eivät voi myöntää uusia sidottuja tokeneita ilman PoP:ia, joten sitomaton refresh-token on toinen vahva indikaattori.

Rajoitukset: Kaikki mainitut signaalit ovat saatavilla vain, kun pääsyä käyttävä laite on rekisteröity Microsoft Entra ID:hen tai liitetty siihen.

Luottamuspisteiden logiikka: Kysely yhdistää useita signaaleja laskeakseen luottamuspisteet:

• Token-pyyntöjä käynnistävän selainprosessin läsnäolo.
• Havaitseminen ja alentuminen sitomattomiin tokeneihin.
• Verkko-operaattorin muutokset (mukaan lukien compliant-tilasta non-compliant-tilaan) kirjautumisten välillä.

Näitä signaaleja voidaan käyttää kyselyssä toiminnan metsästämiseen tai luottamuspisteiden johtamiseen tapahtuman sattuessa aiemman havaitsemisen perusteella.

Ehdoista riippuen näytetään seuraava pisteytys:

Erittäin korkea luottamuspistemäärä näytetään, kun NetworkAccessTraffic-lokit osoittavat tutun selainprosessin token-pyynnön käynnistämisen sijaan ja sitomattoman tokenin alennus on havaittu.

Korkea luottamuspistemäärä näytetään, kun kirjautuminen tapahtuu eri verkko-operaattorilta (ASN) ja non-compliant-verkosta, johon liittyy sitomattomia tokeneita.

Keskitason luottamuspistemäärä näytetään, kun tunnistetaan vain verkko-operaattorin ja compliant-verkon muutos sekä käytetyn token-tyypin muutos.

Löydät metsästyskyselyn uusimman version GitHubista.

Myönnetyillä tokeneilla tehtyjen toimintojen metsästys

Kannattaa harkita tutkinnan laajentamista kirjautumistapahtumien ulkopuolelle kattamaan toiminnot, jotka on suoritettu hyökkääjän myöntämillä tokeneilla. Kollegamme Thomas Naunheim on julkaissut KQL-funktion nimeltä MicrosoftCloudActivity, joka voi auttaa tässä laajennetussa metsästysprosessissa. Lisäksi kyseinen SessionId voidaan korreloida aiemmissa metsästyksissä tunnistettujen epäilyttävien UniqueId-arvojen kanssa syvempää analyysiä varten.

Tässä esimerkissä hyökkääjä hyödynsi hyökkäyksen aikana saatua refresh-tokenia myöntääkseen access-tokenin Microsoft Graph API:lle. Tätä tokenia käytettiin sitten pysyvän pääsyn ja lateraaliliikkeen ylläpitämiseen lisäämällä client secret uhrin omistamaan sovellukseen. Kysely tarjoaa tietoja Graph API -operaatiosta, mukaan lukien token protection -tilan ja sen, tapahtuiko operaatio Global Secure Access -verkon ulkopuolella.

Lisälukemista

• ConsentFix: Analysing a browser-native ClickFix-style attack that hijacks OAuth consent grants - PushSecurity
• Hacking Endpoint to Identity (Microsoft 365): "ConsentFix" - YouTube
• Microsoft identity platform and OAuth 2.0 authorization code flow
• Microsoft Azure CLI on entrascpes.com