SAML Attacks
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
SAMLExtractor: Chombo ambacho kinaweza kuchukua URL au orodha ya URL na kuchapisha URL ya SAML inayotumiwa.
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 zisifanane.
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 hakika, mshambuliaji anatia vitu vilivyotengenezwa ambavyo havihatarishi uhalali wa Saini ya XML. Manipulation 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.
Madhara: Mthibitishaji anaweza kuchanganyikiwa kati ya "Majibu halali -> Uthibitisho -> Mtu" na "Majibu mabaya ya mshambuliaji -> Uthibitisho -> Mtu", na kusababisha matatizo ya uaminifu wa data.
Tofauti na XSW #1: Inatumia saini isiyo na kifurushi badala ya saini inayofunika.
Madhara: Muundo "mbaya", kama XSW #1, unalenga kudanganya mantiki ya biashara baada ya uthibitisho wa uaminifu.
Mkakati: Uthibitisho mbaya unaundwa katika kiwango sawa cha hierarchal na uthibitisho wa asili.
Madhara: Unalenga kuchanganya mantiki ya biashara kutumia data mbaya.
Tofauti na XSW #3: Uthibitisho wa asili unakuwa mtoto wa uthibitisho ulioiga (mbaya).
Madhara: Kama XSW #3 lakini inabadilisha muundo wa XML kwa nguvu zaidi.
Sifa Maalum: Wala Saini wala Uthibitisho wa asili haufuati mipangilio ya kawaida (iliyofunikwa/iliyofunika/isiyo na kifurushi).
Madhara: Uthibitisho ulioiga unafunika Saini, ukibadilisha muundo wa hati inayotarajiwa.
Mkakati: Kuingiza mahali sawa kama XSW #4 na #5, lakini kwa mabadiliko.
Madhara: Uthibitisho ulioiga unafunika Saini, ambayo kisha inafunika Uthibitisho wa asili, kuunda muundo wa udanganyifu wa ndani.
Mkakati: Kipengele cha Extensions kinaingizwa na uthibitisho ulioiga kama mtoto.
Madhara: Hii inatumia muundo wa chini wa Extensions ili kupita hatua za uthibitishaji wa muundo, hasa katika maktaba kama OpenSAML.
Tofauti na XSW #7: Inatumia kipengele kingine cha XML chenye masharti hafifu kwa toleo la shambulizi.
Madhara: Uthibitisho wa asili unakuwa mtoto wa kipengele chenye masharti hafifu, ukirejesha 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 uthibitishaji wa saini ya dijitali. Hii inamaanisha kwamba shambulio linaweza kufanikiwa hata bila saini halali; saini ya kujisaini au saini 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 Saini vinatolewa.
Pamoja na saini zilizondolewa, ruhusu ombi liendelee kwa lengo. Ikiwa Saini 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 chenye saini binafsi kutiwa 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 kilichosajiliwa na bonyeza Save and Self-Sign ili kuunda nakala ya cheti chenye saini binafsi.
Rudi kwenye ombi lililokamatwa katika Proxy ya Burp. Chagua cheti kipya chenye saini binafsi kutoka kwenye orodha ya XML Signature.
Ondoa saini zozote zilizopo kwa kutumia kitufe cha Remove Signatures.
Tiwa saini ujumbe au dhamana kwa cheti kipya kwa kutumia kitufe cha (Re-)Sign Message au (Re-)Sign Assertion, kama inavyofaa.
Peleka ujumbe ulio saini. Uthibitishaji wa mafanikio unaonyesha kwamba SP inakubali ujumbe ulio saini na cheti chako chenye saini binafsi, 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 uthibitishaji ikiwa lilikuwa linakusudiwa kwa mtoa huduma tofauti. Kipengele muhimu hapa ni Recipient field, 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 logout 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, skripti ilitengenezwa kulenga ukurasa wa oidauth/prompt. Skripti hii inajaribu XSS (Cross-Site Scripting) kwa kuingiza data na kuangalia kama inajitokeza katika matokeo. Katika hali ambapo ingizo linaonekana, skripti 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)
