Az - Federation
Taarifa za Msingi
Kutoka kwenye nyaraka:Federation ni mkusanyiko wa domains ambazo zimeanzisha trust. Kiwango cha trust kinaweza kutofautiana, lakini kwa kawaida hujumuisha authentication na karibu kila mara hujumuisha authorization. Federation ya kawaida inaweza kujumuisha idadi ya mashirika ambayo yameanzisha trust kwa shared access kwa seti ya rasilimali.
Unaweza kufederate mazingira yako ya on-premises na Azure AD na kutumia federation hii kwa authentication na authorization. Njia hii ya kuingia inahakikisha kuwa authentication yote ya mtumiaji inafanyika on-premises. Njia hii inaruhusu wasimamizi kutekeleza viwango vya juu vya udhibiti wa ufikiaji. Federation na AD FS na PingFederate inapatikana.
Kimsingi, katika Federation, authentication yote inafanyika katika mazingira ya on-prem na mtumiaji hupata uzoefu wa SSO katika mazingira yote yenye trust. Kwa hivyo, watumiaji wanaweza kufikia programu za cloud kwa kutumia credentials zao za on-prem.
Security Assertion Markup Language (SAML) hutumika kwa kubadilishana taarifa zote za authentication na authorization kati ya watoa huduma.
Katika mpangilio wowote wa federation kuna pande tatu:
Mtumiaji au Mteja
Identity Provider (IdP)
Service Provider (SP)
(Picha kutoka https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
Awali, programu (Service Provider au SP, kama AWS console au vSphere web client) inafikiwa na mtumiaji. Hatua hii inaweza kurukwa, ikimpeleka mteja moja kwa moja kwa IdP (Identity Provider) kulingana na utekelezaji maalum.
Baadaye, SP inatambua IdP sahihi (mfano, AD FS, Okta) kwa authentication ya mtumiaji. Kisha inatengeneza SAML (Security Assertion Markup Language) AuthnRequest na kumrejesha mteja kwa IdP iliyochaguliwa.
IdP inachukua hatua, ikimthibitisha mtumiaji. Baada ya authentication, SAMLResponse inatengenezwa na IdP na kupelekwa kwa SP kupitia mtumiaji.
Hatimaye, SP inatathmini SAMLResponse. Ikiwa imeidhinishwa kwa mafanikio, ikimaanisha uhusiano wa trust na IdP, mtumiaji anapewa ufikiaji. Hii inakamilisha mchakato wa kuingia, ikimruhusu mtumiaji kutumia huduma.
Ikiwa unataka kujifunza zaidi kuhusu SAML authentication na mashambulizi ya kawaida nenda kwa:
Pivoting
AD FS ni mfano wa utambulisho unaotegemea madai.
"..madai ni kauli tu (kwa mfano, jina, utambulisho, kikundi), zinazotolewa kuhusu watumiaji, ambazo hutumika hasa kwa kuidhinisha ufikiaji wa programu zinazotegemea madai zilizoko popote kwenye Intaneti."
Madai kwa mtumiaji huandikwa ndani ya tokeni za SAML na kisha kusainiwa ili kutoa usiri na IdP.
Mtumiaji hutambulishwa na ImmutableID. Ni ya kipekee duniani na imehifadhiwa katika Azure AD.
ImmutableID imehifadhiwa on-prem kama ms-DS-ConsistencyGuid kwa mtumiaji na/au inaweza kutolewa kutoka kwa GUID ya mtumiaji.
Golden SAML attack:
Katika ADFS, SAML Response inasainiwa na cheti cha token-signing.
Ikiwa cheti kimevunjwa, inawezekana kuingia kwenye Azure AD kama mtumiaji YEYOTE aliyesawazishwa na Azure AD!
Kama vile unyanyasaji wetu wa PTA, mabadiliko ya nenosiri kwa mtumiaji au MFA hayataathiri kwa sababu tunatengeneza majibu ya authentication.
Cheti kinaweza kutolewa kutoka kwa seva ya AD FS na DA privileges na kisha kinaweza kutumika kutoka kwa mashine yoyote iliyounganishwa na intaneti.
Golden SAML
Mchakato ambapo Identity Provider (IdP) inazalisha SAMLResponse kuidhinisha kuingia kwa mtumiaji ni muhimu. Kulingana na utekelezaji maalum wa IdP, majibu yanaweza kuwa yamesainiwa au yamefichwa kwa kutumia ufunguo wa siri wa IdP. Utaratibu huu unamwezesha Service Provider (SP) kuthibitisha uhalali wa SAMLResponse, kuhakikisha kuwa ilitolewa na IdP yenye trust.
Mfano unaweza kuchorwa na golden ticket attack, ambapo ufunguo unaothibitisha utambulisho na ruhusa za mtumiaji (KRBTGT kwa golden tickets, token-signing private key kwa golden SAML) unaweza kudanganywa ili kutengeneza kitu cha authentication (TGT au SAMLResponse). Hii inaruhusu kuiga mtumiaji yeyote, ikitoa ufikiaji usioidhinishwa kwa SP.
Golden SAMLs hutoa faida fulani:
Zinaweza kuundwa kwa mbali, bila hitaji la kuwa sehemu ya domain au federation husika.
Zinabaki kuwa na ufanisi hata ikiwa Two-Factor Authentication (2FA) imewezeshwa.
Ufunguo wa token-signing haujibadilishi kiotomatiki.
Kubadilisha nenosiri la mtumiaji hakubatilishi SAML iliyotengenezwa tayari.
AWS + AD FS + Golden SAML
Active Directory Federation Services (AD FS) ni huduma ya Microsoft inayowezesha kubadilishana kwa usalama wa taarifa za utambulisho kati ya washirika wa biashara wenye trust (federation). Kimsingi inaruhusu huduma ya domain kushiriki utambulisho wa watumiaji na watoa huduma wengine ndani ya federation.
Kwa AWS kuamini domain iliyovunjwa (katika federation), udhaifu huu unaweza kutumiwa kupata ruhusa yoyote katika mazingira ya AWS. Shambulio linahitaji ufunguo wa siri unaotumika kusaini vitu vya SAML, sawa na hitaji la KRBTGT katika golden ticket attack. Ufikiaji wa akaunti ya mtumiaji wa AD FS unatosha kupata ufunguo huu wa siri.
Mahitaji ya kutekeleza shambulio la golden SAML ni pamoja na:
Ufunguo wa siri wa token-signing
Cheti cha umma cha IdP
Jina la IdP
Jina la jukumu (role la kuchukua)
Domain\username
Jina la kikao cha jukumu katika AWS
Amazon account ID
Vitu vilivyo katika bold pekee ndivyo vya lazima. Vingine vinaweza kujazwa kama inavyotakiwa.
Ili kupata ufunguo wa siri, ufikiaji wa akaunti ya mtumiaji wa AD FS ni muhimu. Kutoka hapo, ufunguo wa siri unaweza kutolewa kutoka kwa duka la kibinafsi kwa kutumia zana kama mimikatz. Ili kukusanya taarifa nyingine zinazohitajika, unaweza kutumia Microsoft.Adfs.Powershell snapin kama ifuatavyo, kuhakikisha umeingia kama mtumiaji wa ADFS:
Kwa habari zote, inawezekana kusahau SAMLResponse halali kama mtumiaji unayetaka kuiga kwa kutumia shimit:
On-prem -> cloud
Pia inawezekana kuunda ImmutableID ya watumiaji wa wingu pekee na kuiga wao
Marejeo
Last updated