AuthCodeFix aka ConsentFix

Eins og hefð er fyrir rétt fyrir áramót birtist nýr veikleiki eða snjallt árásarvektor, og verjendur sitja eftir og reyna að vernda notendur sína. Á meðan fylgjast aðrir árásaraðilar og red teamers náið með og aðlaga sig.

Í ár uppgötvaði PushSecurity árás sem þeir nefndu „ConsentFix", þróun á ClickFix-árásinni sem byggir á því að notandinn afhendi árásaraðilanum URI sem í raun réttir yfir lyklana að Entra-ríkinu. Aðferðin sem sást í reynd byggði á handvirkri copy-and-paste aðgerð notandans til að virka. Innan fárra daga birti John Hammond myndband sem sýndi endurbætta útgáfu árásarinnar sem krafðist ekki lengur copy-and-paste, í staðinn gat notandinn einfaldlega dregið og sleppt auth-kóðanum sínum yfir til árásaraðilans.

Þegar við skoðum tæknileg smáatriði um hvers vegna þessi árás virkar og virðist fara framhjá device compliance og öðrum Conditional Access kröfum, endum við í OAuth 2.0 authorization code flow.

Árásaraðilinn býr til Microsoft Entra login URI sem beinir sér að „Microsoft Azure CLI" client og „Azure Resource Manager" resource, og opnar þennan URI þegar notandinn heimsækir illgjarna vefsíðu.

Kortlagt á authorization code flow samsvarar þetta fyrsta þrepinu sem native public app eins og Azure CLI myndi venjulega kalla á til að auðkenna notandann. Forritið býr til listener á vélinni sem það er keyrt á, á handahófskenndri hárri port. Þessi port er notuð sem svokölluð reply URI.

Þú getur endurgert þetta auðveldlega sjálf/ur, til dæmis með því að nota TokenTacticsV2, eða með því að handsmíða URI-ið.

Eftir að notandinn skráir sig inn í Entra ID með góðum árangri er honum vísað áfram á reply URI-ið, t.d. http://localhost:3001. Í venjulegu tilviki myndi Azure CLI nú taka við kallinu á þennan URI og fá mikilvægar og gagnrýnar upplýsingar sem eru hluti af redirect-inu:

• code
  Þetta er authorization_code, sem forritið notar til að biðja um bearer token, sem samanstendur af access, ID, og valfrjálst refresh token.
  Samkvæmt skjölum er þessi kóði gildur í um það bil 10 mínútur og verður að innleysa hann innan þess tíma.
• state
  Þetta er valfrjáls stiki, og forritið á að staðfesta hvort hann sé eins í request og response.

Í árásarsviðsmyndinni er notandanum einnig vísað áfram, en þar sem ekkert forrit er í gangi á localhost lendir vafrinn í villu.

En URI-ið inniheldur enn viðkvæmu upplýsingarnar og það er þetta sem árásaraðilinn vill að notandinn afhendi honum. Ef notandinn gengur að því mun árásaraðilinn nú innleysa token-efnið og getur svo notað access og refresh token til að nálgast auðlindina, í þessu tilviki Azure Resource Manager.

Á þessari skjámynd sérðu hvernig má sækja bearer token með því að nota URI-ið sem notandinn afhenti.

Ef þú vilt prófa greiningarnar þínar, gættu þess að framkvæma síðasta þrepið úr öðru kerfi, á öðru neti.

Greiningarummerki

Þegar þú endurgerir árásina og skoðar SigninLogs og AADNonInteractiveUserSignInLogs, sérðu tvo atburði fyrir þessa einu innskráningaraðgerð. Fyrri atburðurinn táknar raunverulega innskráningu notandans, á meðan sá seinni kemur frá innviðum árásaraðilans.

Stóri munurinn er sá að fyrri atburðurinn er interactive sign-in atburður, en sá seinni er non-interactive. Þetta samsvarar þeim tveimur þrepum authentication flow-sins: fyrst notandinn, síðan forritið, eða í okkar tilviki árásaraðilinn.

Venjuleg hegðun Azure CLI væri sú að báðir innskráningaratburðirnir kæmu frá sömu IP-tölu. Í okkar tilviki eru IP-tölurnar hins vegar ólíkar og koma frá mismunandi löndum. Að sjálfsögðu er síðarnefnda ekki áreiðanleg vísbending, þar sem árásaraðilinn gæti verið í sama landi og fórnarlambið til að fela slóð sína.

Vantandi tengsl

Þegar leitað var að góðri leið til að tengja þessa tvo atburði, var fyrsta hugmyndin eðlilega að skoða Unique Token Identifier (UTI). Hins vegar notar Microsoft mismunandi gildi fyrir authorization code UTI og bearer token UTI, þannig að þessi aðferð virkar ekki sem áreiðanleg tenging.

Hins vegar er SessionId góð tenging á milli þeirra tveggja, þótt þetta sé langlíft ID og geti innihaldið margar slíkar samsetningar af atburðum, jafnvel löglegar.

Með viðbótarþekkingu á takmörkunum auth code flow-sins og með user og application id sem viðbótartengingar getur þú notað tíma sem mikilvægan greiningarþátt:

• Báðir atburðir deila sama SessionId
• Báðir atburðir deila sama ApplicationId
• Báðir atburðir deila sama UserId
• Seinni atburðurinn verður að vera á eftir fyrri atburðinum
• Seinni atburðurinn verður að vera innan um það bil 10 mínútna tímaramma eftir fyrri atburðinn. Þú ættir ekki að nota nákvæmlega 10 mínútur þar sem Microsoft skrifar „[...] they expire after about 10 minutes"
• Þú ættir aðeins að íhuga næsta seinni atburð, ekki þá sem á eftir koma

Fun fact
ResourceIdentity er ekki góð tenging, þar sem árásaraðilinn getur breytt resource-inu vegna þess að það er ekki bundið við auth code-inn. Application ID-inu sem beinist er að er ekki hægt að breyta.

Draga úr suði

Þessi þekking veitti okkur nú þegar góða virka greiningu, en það voru einnig benign positives í blöndunni. Nútíma þróunaraðilar nota cloud resources sem líta út eins og local instances, en leiða til óreglulegra innskráningarmynstra í loggunum.

Lykilmunurinn er tímaþátturinn. Á meðan árásin krefst notendasamskipta til að afrita og líma eða draga og sleppa URI-inu, er GitHub Codespace notkunartilvikið sem við auðkenndum sem uppruna benign positive-varnaðanna algjörlega sjálfvirkt og innleysir auth code-inn innan nokkurra sekúndna.

Að sía út allt sem framkvæmir þennan authentication-dans innan nokkurra sekúndna má því líklega fjarlægja sem benign.

Önnur uppspretta suðs gætu verið breytilegir egress-punktar fyrir internetumferðina þína, sérstaklega í SD-WAN, ZTNA eða Secure Web Gateway sviðsmyndum.

Fyrsta aðila forrit sem eiga í hlut

Þótt upphaflega skýrslan sýni „Microsoft Azure CLI" sem misnotaða forritið eru mörg mismunandi Microsoft first-party forrit með pre-consent í hverjum tenant sem bjóða upp á localhost sem redirect. Og ekki bara þau eru skotmark. Árásaraðilinn gæti einnig misnotað reply test- og dev-URL sem eru ekki opinberlega upplausnanlegar.

Hér er listi yfir athyglisverðustu forritin sem einnig hafa háar pre-consented heimildir á resources.

• 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)

Fullur listi yfir þessi forrit er nú innifalinn í EntraScopes.com hjá samstarfsmanni okkar Fabian Bader.

Mótvægisaðgerðir og varnir

Takmarka árásaryfirborð og áhorfendur

Valkostur 1: Krefjast User Assignment

Forkröfur:

• Bæta service principal fyrir viðkomandi first-party forrit með Microsoft Graph API eða PowerShell
• Beita user assignment kröfunni á service principal hlutinn með Microsoft Graph API eða PowerShell
• Koma á ferli til að úthluta notendum að beiðni með Access Packages, PIM-for-Groups (fyrir just-in-time aðgang), eða samsetningu af hvoru tveggja.

// 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

Kostur:

• Gerir kleift að stýra user assignments með Access Packages eða handvirkri hópaðild til að takmarka útsetningu fyrir þessari árásaraðferð.
• Möguleiki á að veita just-in-time aðgang samhliða eligible hópaðildarúthlutun, sem heimilar tímabundinn aðgang að CLI-verkfærum og minnkar þar með árásaryfirborðið enn frekar.
• Beitt áður en Conditional Access stefnur eru metnar.
• Takmarkar árásaryfirborðið einnig fyrir aðrar sviðsmyndir.

Ókostur:

• Er aðeins hægt að afmarka við tiltekna notendur og ekki hægt að sameina það öðrum kröfum eins og notkun tiltekinna tækja
• Verður að auðkenna alla lögmæta notendur CLI-verkfæra
• Meta þarf hliðarverkanir og skipulagsleg áhrif vandlega með því að fara yfir fyrri innskráningar.

Valkostur 2: Loka fyrir aðgang með Conditional Access stefnum

Forkröfur:

• Búa til Conditional Access stefnu til að loka fyrir aðgang að CLI-verkfærum, með undanþágu fyrir lögmæta notendur, með því að miða á „Microsoft Graph Command Line Tools" og „Windows Azure Service Management API"
• Stýra undanþágum með hópaðild, annaðhvort handvirkt eða í gegnum entitlement management (t.d. Access Packages).

Kostur:

• Kemur í veg fyrir útgáfu token fyrir ólögmæta eða óforréttindanotendur.
• Heimilar granular scoping út frá viðbótarskilyrðum eins og tæki eða neti.

Ókostur:

• Verður að auðkenna alla lögmæta notendur CLI-verkfæra og undanskilja þá.
• Meta þarf hliðarverkanir og skipulagsleg áhrif vandlega með því að fara yfir fyrri innskráningar og meta stefnuna í report-only mode.

Loka fyrir token-útgáfu í gegnum authorization code flow

Forkröfur:

• Microsoft Entra ID P1 leyfi
• Entra ID Registered Devices, Hybrid eða Entra ID-joined tæki á Windows platform
• Virkja Web Account Manager (WAM) í Azure CLI, Azure PowerShell og Microsoft Graph PowerShell (sjálfgefið í nýjustu útgáfum)
• Stilla Conditional Access sem beinist að:
  • Cloud App targeting á eftirfarandi forrit:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • Client apps undir Mobile apps and desktop clients til að krefjast Token Protection.
  • Velja Windows sem device platform til að beina stefnunni

Kostur:

Token protection Microsoft Entra krefst proof-of-possession (PoP), sem aðeins er hægt að framfylgja þegar client-inn hefur samskipti beint við trausta token broker eins og Web Account Manager (WAM) á Windows. Þar sem vafrar geta ekki komið á þessari öruggu rás er authorization code flow sem hafið er í vafra lokað undir token protection stefnum.

Þegar stefnan framfylgir token protection sem krefst broker-managed PoP, er ekki hægt að innleysa authorization code sem skilað er til vafra vegna þess að vafrinn getur ekki búið til nauðsynlegt broker-signed proof við kóða-til-token skiptin

Í þessu tilviki verða árásir með AuthCodeFix að fullu mildaðar svo lengi sem forritið er hægt að vernda með Token Protection.

Eins og sýnt er á skjámyndinni hér að neðan mildar Token Protection með góðum árangri innlausn á authorization code flow sem fórnarlambið kom af stað með phishing-aðgerð.

Ókostur:

• Aðeins eftirfarandi resources eru opinberlega studdar:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    Microsoft Graph API er óbeint þakinn af áðurnefndum resources og Microsoft Graph PowerShell er skráður sem studdur client. Í prófunum okkar gátum við staðfest að árásin fyrir þessa sviðsmynd verður milduð. „Windows Azure Service Management API" er ekki skráður sem studdur resource. Báðir CLI clients (Azure CLI og Azure PowerShell) styðja WAM sem er client-hliðar krafa til að nota Token Protection. Microsoft hefur tilkynnt í bloggfærslu að þeir muni útvíkka token protection getu fyrir Azure management sviðsmyndir.
• Sumir bugs í Microsoft Graph PowerShell neyða þig til að slökkva tímabundið á WAM-samþættingu
• Meta þarf hliðarverkanir og skipulagsleg áhrif vandlega með því að fara yfir fyrri innskráningar og meta stefnuna í report-only mode. Cloud app targeting mun einnig hafa áhrif á framleiðniaðgang að Microsoft 365.
• Takmarkað umfang vegna framboðs á studdum kerfum og Entra ID-samþættum tækjum.

Loka fyrir frekari token-útgáfu með compliant network check eða trusted network

Valkostur: Loka fyrir aðgang utan Compliant network með Global Secure Access

Forkrafa:

• Entra ID P1 leyfi
• Entra ID Registered Devices, Hybrid eða Entra ID-joined tæki á Windows, macOS, Android og iOS platform
• Global Secure Access Client á öllum viðkomandi clients og virkjaður Entra Internet Access fyrir M365 Traffic Profile
• Conditional Access stefnu til að framfylgja network compliant check ætti að beita á öll cloud apps

Kostur:

Loka fyrir viðbótar token-útgáfu með því að framfylgja trusted network check. Þessi mildun tryggir að árásaraðilar geti ekki fengið ný tokens með refresh token frá authorization code flow. Hins vegar kemur hún ekki í veg fyrir upphaflega innlausn authorization code eða útgáfu fyrsta access token, sem er áfram gildur utan compliant network vegna þess að hann var upphaflega umbeðinn af fórnarlambinu.

Að framfylgja GSA með Compliant Network skilyrðinu lokar einnig fyrir aðrar Token Replay sviðsmyndir og bætir við viðbótarloggum sem geta verið mjög gagnlegar fyrir detections og hunting.

Ókostur:

• Aðeins gildandi fyrir notendur og tæki með uppsettum Global Secure Access client
• Takmarkað umfang vegna framboðs á Entra ID-samþættum tækjum
• Að framfylgja Compliant Networks í gegnum CA mun þurfa nokkrar Exclusions eins og Intune til að forðast hænu-og-egg vandamál. Nákvæm prófun er nauðsynleg fyrir útrás

Veiðifyrirspurnir

Þegar allar forkröfur fyrir token theft mildun eru uppfylltar, svo sem að setja upp GSA client (þar á meðal ingestion á NetworkAccessTraffic loggum) og að nýta WAM authentication, fáum við viðbótarmöguleika fyrir threat hunting og staðfestingu.

Nýta GSA-logga og WAM Authentication fyrir hunting eða staðfestingu á áreiðanleika greiningarniðurstaðna

Þessi hunting-fyrirspurn nýtir sér NetworkAccessTraffic logga frá Global Secure Access (GSA), sem innihalda ferlið sem hóf samskiptin við Microsoft Entra token endpoint. Þetta hjálpar til við að ákvarða hvort token-beiðni kom beint frá vafra og einnig hvort einhverjar viðbótar token-beiðnir voru gerðar utan GSA-netsins.

Þessi fyrirspurn virkar og skilar aðeins áreiðanlegum niðurstöðum þegar forkröfur eru uppfylltar, annars leiðir hún til hás false-positive hlutfalls.

Af hverju þetta skiptir máli: Þegar skráð er inn í gegnum CLI eða PowerShell einingar með Web Account Manager (WAM) á Windows tækjum, felur flæðið ekki í sér browser-based authorization code. Þessi sign-in hegðun er sjálfgefin í nýjustu útgáfunni. Því, ef ferlið sem hóf beiðnina er browser-executable (t.d. msedge.exe), er þetta sterk vísbending um grunsamlega virkni. Á macOS er ferlið hafið af Company Portal forritinu (com.microsoft.CompanyPortalMac.ssoextension) þegar Platform SSO er notað.

Token Binding og PoP: WAM authentication bindur venjulega tokens við tækið með því að framfylgja Proof-of-Possession (PoP). Árásaraðilar geta ekki gefið út frekari bounded tokens án PoP, þannig að unbounded refresh token er önnur sterk vísbending.

Takmarkanir: Öll nefnd merki eru aðeins tiltæk þegar tækið sem er að nálgast er registered með eða joined til Microsoft Entra ID.

Confidence Score rökfræði: Fyrirspurnin sameinar mörg merki til að reikna confidence score:

• Nærvera browser-ferlis sem hefur token-beiðnir.
• Detection og down grade í unbounded tokens.
• Breytingar á network provider (þar á meðal Compliant í non-compliant) milli sign-ins.

Þessi merki er hægt að nota í fyrirspurninni til að leita að virkni eða til að leiða út confidence score í tilviki incident byggt á fyrri greiningu.

Eftirfarandi einkunn verður sýnd háð skilyrðunum:

Mjög hátt confidence score er sýnt þegar NetworkAccessTraffic loggar benda á kunnuglegt browser-ferli í stað þess að hefja token-beiðni, og downgrade á unbound token hefur verið greint.

Hátt confidence score er sýnt þegar innskráningin á sér stað frá öðrum Network Provider (ASN) og non-compliant network sem felur í sér unbound tokens.

Miðlungs confidence score er sýnt þegar aðeins breyting á Network Provider og compliant network er auðkennd, ásamt breytingu á token-gerðinni sem notuð er.

Þú finnur nýjustu útgáfu af hunting-fyrirspurninni á GitHub.

Veiða virkni út frá útgefnum tokens

Þú ættir að íhuga að útvíkka rannsókn þína út fyrir sign-in atburði til að fela í sér virkni sem framkvæmd er með tokens sem árásaraðilinn gaf út. Samstarfsmaður okkar Thomas Naunheim hefur birt KQL-fall sem heitir MicrosoftCloudActivity, sem getur aðstoðað í þessu útvíkkaða veiðiferli. Að auki er hægt að tengja viðkomandi SessionId við grunsamleg UniqueId gildi sem auðkennd voru við fyrri veiðar til dýpri greiningar.

Í þessu dæmi nýtti árásaraðilinn refresh token sem fékkst við árásina til að gefa út access token fyrir Microsoft Graph API. Þessi token var svo notaður til að viðhalda þrálátum aðgangi og lateral movement með því að bæta client secret við forrit sem fórnarlambið átti. Fyrirspurnin veitir upplýsingar um Graph API aðgerðina, þar á meðal token protection stöðuna og hvort aðgerðin átti sér stað utan Global Secure Access netsins.

Frekari lesning

• 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