SAML Attacks
Last updated
Last updated
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
SAMLExtractor: Chombo ambacho kinaweza kuchukua URL au orodha ya URL na kuchapisha URL ya SAML consume.
Katika XML sehemu iliyosainiwa ya XML huhifadhiwa kwenye kumbukumbu, kisha baadhi ya uandishi/ufafanuzi unafanywa na saini inakaguliwa. Kwa kawaida, uandishi/ufafanuzi huo haupaswi kubadilisha data lakini kulingana na hali hiyo, data inayokaguliwa na data ya awali huenda isiwe sawa.
Kwa mfano, angalia msimbo ufuatao:
Kukimbia programu dhidi ya REXML 3.2.4 au mapema kutasababisha matokeo yafuatayo badala yake:
This is how REXML saw the original XML document from the program above:
And this is how it saw it after a round of parsing and serialization:
For more information about the vulnerability and how to abuse it:
Katika XML Signature Wrapping attacks (XSW), maadui wanatumia udhaifu unaotokea wakati hati za XML zinaposhughulikiwa kupitia hatua mbili tofauti: uthibitishaji wa saini na kuitwa kwa kazi. Mashambulizi haya yanahusisha kubadilisha muundo wa hati ya XML. Kwa haswa, mshambuliaji anatia vitu vilivyotengenezwa ambavyo havihatarishi uhalali wa Saini ya XML. Manipulasi hii inalenga kuunda tofauti kati ya vitu vinavyotathminiwa na mantiki ya programu na vile vinavyokaguliwa na moduli ya uthibitishaji wa saini. Kama matokeo, wakati Saini ya XML inabaki kuwa halali kiufundi na inapita uthibitishaji, mantiki ya programu inashughulikia vitu vya udanganyifu. Kwa hivyo, mshambuliaji anafanikiwa kupita ulinzi wa uaminifu wa Saini ya XML na uthibitishaji wa asili, kuruhusu kuingiza maudhui yasiyo na mipaka bila kugundulika.
Mashambulizi yafuatayo yanategemea hiki kipande cha blog na hati hii. Hivyo angalia hizo kwa maelezo zaidi.
Mkakati: Kipengele kipya cha mzizi kinachoshikilia saini kinaongezwa.
Matokeo: Mthibitishaji anaweza kuchanganyikiwa kati ya "Jibu halali -> Dhamana -> Mtu" na "jibu mbaya la mshambuliaji -> Dhamana -> Mtu", na kusababisha matatizo ya uaminifu wa data.
Tofauti na XSW #1: Inatumia saini isiyo na kifurushi badala ya saini inayofunika.
Matokeo: Muundo "mbaya", kama XSW #1, unalenga kudanganya mantiki ya biashara baada ya uthibitisho wa uaminifu.
Mkakati: Dhamana mbaya inaundwa katika kiwango sawa cha hierarchal kama dhamana ya asili.
Matokeo: Inakusudia kuchanganya mantiki ya biashara kutumia data mbaya.
Tofauti na XSW #3: Dhamana ya asili inakuwa mtoto wa dhamana iliyoongezeka (mbaya).
Matokeo: Kama XSW #3 lakini inabadilisha muundo wa XML kwa nguvu zaidi.
Sifa Maalum: Wala Saini wala Dhamana ya asili hazifuatani na mipangilio ya kawaida (iliyofunikwa/iliyofunika/isiyo na kifurushi).
Matokeo: Dhamana iliyokopwa inafunika Saini, ikibadilisha muundo wa hati inayotarajiwa.
Mkakati: Kuingiza mahali sawa kama XSW #4 na #5, lakini kwa mabadiliko.
Matokeo: Dhamana iliyokopwa inafunika Saini, ambayo kisha inafunika Dhamana ya asili, ikiumba muundo wa udanganyifu wa ndani.
Mkakati: Kipengele cha Extensions kinatiwa na Dhamana iliyokopwa kama mtoto.
Matokeo: Hii inatumia muundo wa chini wa kikomo wa kipengele cha Extensions ili kupita hatua za uthibitishaji wa muundo, hasa katika maktaba kama OpenSAML.
Tofauti na XSW #7: Inatumia kipengele kingine cha XML chenye kikomo kidogo kwa toleo la shambulizi.
Matokeo: Dhamana ya asili inakuwa mtoto wa kipengele chenye kikomo kidogo, ikirudisha muundo ulio tumika katika XSW #7.
Unaweza kutumia nyongeza ya Burp SAML Raider kuchambua ombi, kutekeleza shambulizi lolote la XSW unalotaka, na kulizindua.
Ikiwa hujui ni aina gani za mashambulizi ni XXE, tafadhali soma ukurasa ufuatao:
XXE - XEE - XML External EntitySAML Responses ni hati za XML zilizopunguzwa na zilizokodishwa kwa base64 na zinaweza kuwa hatarini kwa mashambulizi ya XML External Entity (XXE). Kwa kubadilisha muundo wa XML wa Jibu la SAML, washambuliaji wanaweza kujaribu kutumia udhaifu wa XXE. Hapa kuna jinsi shambulizi kama hilo linaweza kuonyeshwa:
Unaweza pia kutumia nyongeza ya Burp SAML Raider kuunda POC kutoka kwa ombi la SAML ili kujaribu uwezekano wa udhaifu wa XXE na udhaifu wa SAML.
Angalia pia mazungumzo haya: https://www.youtube.com/watch?v=WHn-6xHL7mI
Kwa maelezo zaidi kuhusu XSLT tembelea:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)Mabadiliko ya Lugha ya Mtindo wa Kupanua (XSLT) yanaweza kutumika kubadilisha hati za XML kuwa fomati mbalimbali kama HTML, JSON, au PDF. Ni muhimu kutambua kwamba mabadiliko ya XSLT yanafanywa kabla ya uthibitisho wa saini ya dijitali. Hii inamaanisha kwamba shambulio linaweza kufanikiwa hata bila saini halali; saini iliyojitengeneza au isiyo halali inatosha kuendelea.
Hapa unaweza kupata POC ya kuangalia aina hii ya udhaifu, katika ukurasa wa hacktricks ulioelezwa mwanzoni mwa sehemu hii unaweza kupata payloads.
Unaweza pia kutumia nyongeza ya Burp SAML Raider kuunda POC kutoka kwa ombi la SAML ili kujaribu uwezekano wa udhaifu wa XSLT.
Angalia pia hotuba hii: https://www.youtube.com/watch?v=WHn-6xHL7mI
XML Signature Exclusion inatazama tabia ya utekelezaji wa SAML wakati kipengele cha Signature hakipo. Ikiwa kipengele hiki hakipo, uthibitishaji wa saini huenda usifanyike, na kufanya iwe hatarini. Inawezekana kujaribu hili kwa kubadilisha maudhui ambayo kawaida yanathibitishwa na saini.
Unaweza pia kutumia nyongeza ya Burp SAML Raider. Kamatia Jibu la SAML na bonyeza Remove Signatures. Kwa kufanya hivyo, vipengele vyote vya Signature vinatolewa.
Pamoja na saini zilizondolewa, ruhusu ombi liendelee kwa lengo. Ikiwa Signature haitahitajika na Huduma
Certificate Faking ni mbinu ya kujaribu ikiwa Mtoa Huduma (SP) anathibitisha ipasavyo kwamba Ujumbe wa SAML umetiwa saini na Mtoa Kitambulisho anayeaminika (IdP). Inahusisha kutumia *cheti kilichojisaini kutia saini Jibu la SAML au Dhamana, ambayo husaidia katika kutathmini mchakato wa uthibitishaji wa uaminifu kati ya SP na IdP.
Hatua zifuatazo zinaelezea mchakato wa kutumia nyongeza ya SAML Raider ya Burp:
Kamatia Jibu la SAML.
Ikiwa jibu lina saini, tuma cheti kwa SAML Raider Certs kwa kutumia kitufe cha Send Certificate to SAML Raider Certs.
Katika tab ya Cheti za SAML Raider, chagua cheti kilichosafirishwa na bonyeza Save and Self-Sign ili kuunda nakala ya cheti kilichojisaini.
Rudi kwenye ombi lililokamatwa katika Proxy ya Burp. Chagua cheti kipya kilichojisaini kutoka kwenye orodha ya XML Signature.
Ondoa saini zozote zilizopo kwa kutumia kitufe cha Remove Signatures.
Tia saini ujumbe au dhamana kwa kutumia cheti kipya kwa kutumia kitufe cha (Re-)Sign Message au (Re-)Sign Assertion, kama inavyofaa.
Peleka ujumbe ulio saini. Uthibitisho wa mafanikio unaonyesha kwamba SP inakubali ujumbe ulio saini na cheti chako kilichojisaini, ikifunua udhaifu wa uwezekano katika mchakato wa uthibitishaji wa ujumbe wa SAML.
Token Recipient Confusion na Service Provider Target Confusion zinahusisha kuangalia ikiwa Mtoa Huduma anathibitisha ipasavyo mpokeaji aliye kusudiwa wa jibu. Kwa msingi, Mtoa Huduma anapaswa kukataa jibu la uthibitisho ikiwa lilikuwa linakusudiwa kwa mtoa huduma tofauti. Kipengele muhimu hapa ni Recipient, kinachopatikana ndani ya kipengele cha SubjectConfirmationData cha Jibu la SAML. Kipengele hiki kinaelezea URL inayoonyesha mahali ambapo Dhamana inapaswa kutumwa. Ikiwa mpokeaji halisi hauendani na Mtoa Huduma aliye kusudiwa, Dhamana inapaswa kuonekana kuwa batili.
Ili shambulio la SAML Token Recipient Confusion (SAML-TRC) liweze kufanyika, masharti fulani yanapaswa kutimizwa. Kwanza, lazima kuwe na akaunti halali kwenye Mtoa Huduma (inayojulikana kama SP-Legit). Pili, Mtoa Huduma anayelengwa (SP-Target) lazima akubali tokeni kutoka kwa Mtoa Kitambulisho yule yule anayehudumia SP-Legit.
Mchakato wa shambulio ni rahisi chini ya masharti haya. Kikao halali kinaanzishwa na SP-Legit kupitia Mtoa Kitambulisho aliyeshirikiwa. Jibu la SAML kutoka kwa Mtoa Kitambulisho hadi SP-Legit linakamatwa. Jibu hili la SAML lililokamatwa, ambalo awali lilikuwa linakusudiwa kwa SP-Legit, kisha linapelekwa kwa SP-Target. Mafanikio katika shambulio hili yanapimwa kwa SP-Target kukubali Dhamana, ikitoa ufikiaji wa rasilimali chini ya jina la akaunti ile ile iliyotumika kwa SP-Legit.
Utafiti wa asili unaweza kupatikana kupitia kiungo hiki.
Wakati wa mchakato wa kulazimisha saraka, ukurasa wa kutoka uligunduliwa katika:
Upon accessing this link, a redirection occurred to: Baada ya kufikia kiungo hiki, uelekezaji ulitokea kwa:
Hii ilifunua kwamba parameter ya base inakubali URL. Kwa kuzingatia hili, wazo lilitokea kubadilisha URL na javascript:alert(123); katika jaribio la kuanzisha shambulio la XSS (Cross-Site Scripting).
Zana ya SAMLExtractor ilitumika kuchambua subdomains za uberinternal.com kwa ajili ya maeneo yanayotumia maktaba ile ile. Baadaye, script ilitengenezwa kulenga ukurasa wa oidauth/prompt. Script hii inajaribu XSS (Cross-Site Scripting) kwa kuingiza data na kuangalia kama inajitokeza katika matokeo. Katika hali ambapo ingizo linaonekana, script inatambua ukurasa kama dhaifu.
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
