# SAML Attacks
## SAML Attacks
{% hint style="success" %}
Ucz się i ćwicz Hacking AWS:
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Ucz się i ćwicz Hacking GCP: 
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Wsparcie dla HackTricks
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegram**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Podziel się sztuczkami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
{% endhint %}
## Podstawowe informacje
{% content-ref url="saml-basics.md" %}
[saml-basics.md](saml-basics.md)
{% endcontent-ref %}
## Narzędzie
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Narzędzie, które może przyjąć URL lub listę URL i zwrócić SAML consume URL.
## XML round-trip
W XML podpisana część XML jest zapisywana w pamięci, następnie wykonywane jest kodowanie/dekodowanie i sprawdzany jest podpis. Idealnie, to kodowanie/dekodowanie nie powinno zmieniać danych, ale w oparciu o ten scenariusz, **dane sprawdzane i oryginalne dane mogą nie być takie same**.
Na przykład, sprawdź poniższy kod:
```ruby
require 'rexml/document'
doc = REXML::Document.new <]>
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 przeciwko REXML 3.2.4 lub wcześniejszym wersjom skutkowałoby następującym wynikiem zamiast tego:
```
First child in original doc: Y
First child after round-trip: Z
```
To jest to, jak REXML widział oryginalny dokument XML z powyższego programu:
.png>)
A tak to widział po rundzie analizy i serializacji:
.png>)
Aby uzyskać więcej informacji na temat podatności i sposobów jej wykorzystania:
* [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
* [https://joonas.fi/2021/08/saml-is-insecure-by-design/](https://joonas.fi/2021/08/saml-is-insecure-by-design/)
## Ataki na Owijanie Podpisów XML
W **atakach na Owijanie Podpisów XML (XSW)**, przeciwnicy wykorzystują podatność, która pojawia się, gdy dokumenty XML są przetwarzane w dwóch odrębnych fazach: **walidacji podpisu** i **wywołania funkcji**. Ataki te polegają na modyfikacji struktury dokumentu XML. Konkretnie, atakujący **wstrzykuje fałszywe elementy**, które nie naruszają ważności Podpisu XML. Ta manipulacja ma na celu stworzenie rozbieżności między elementami analizowanymi przez **logikę aplikacji** a tymi sprawdzanymi przez **moduł weryfikacji podpisu**. W rezultacie, podczas gdy Podpis XML pozostaje technicznie ważny i przechodzi weryfikację, logika aplikacji przetwarza **fałszywe elementy**. W konsekwencji, atakujący skutecznie omija **ochronę integralności** i **uwierzytelnianie pochodzenia** Podpisu XML, umożliwiając **wstrzykiwanie dowolnej treści** bez wykrycia.
Poniższe ataki opierają się na [**tym wpisie na blogu**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **i** [**tym artykule**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Sprawdź je, aby uzyskać więcej szczegółów.
### XSW #1
* **Strategia**: Dodawany jest nowy element root zawierający podpis.
* **Implikacja**: Walidator może się pomylić między legalnym "Response -> Assertion -> Subject" a "złym nowym Response -> Assertion -> Subject" atakującego, co prowadzi do problemów z integralnością danych.
.png>)
### XSW #2
* **Różnica od XSW #1**: Wykorzystuje podpis odłączony zamiast podpisu opakowującego.
* **Implikacja**: "Zła" struktura, podobnie jak w XSW #1, ma na celu oszukanie logiki biznesowej po sprawdzeniu integralności.
.png>)
### XSW #3
* **Strategia**: Tworzony jest zły Assertion na tym samym poziomie hierarchicznym co oryginalny assertion.
* **Implikacja**: Ma na celu wprowadzenie w błąd logiki biznesowej, aby używała złośliwych danych.
.png>)
### XSW #4
* **Różnica od XSW #3**: Oryginalny Assertion staje się dzieckiem powielonego (złego) Assertion.
* **Implikacja**: Podobnie jak w XSW #3, ale bardziej agresywnie zmienia strukturę XML.
.png>)
### XSW #5
* **Unikalny aspekt**: Ani Podpis, ani oryginalny Assertion nie przestrzegają standardowych konfiguracji (opakowany/opakowujący/odłączony).
* **Implikacja**: Skopiowany Assertion opakowuje Podpis, modyfikując oczekiwaną strukturę dokumentu.
.png>)
### XSW #6
* **Strategia**: Podobne wstawienie lokalizacji jak w XSW #4 i #5, ale z twistem.
* **Implikacja**: Skopiowany Assertion opakowuje Podpis, który następnie opakowuje oryginalny Assertion, tworząc zagnieżdżoną strukturę oszukańczą.
.png>)
### XSW #7
* **Strategia**: Wstawiany jest element Extensions z skopiowanym Assertion jako dzieckiem.
* **Implikacja**: Wykorzystuje mniej restrykcyjną schemę elementu Extensions, aby obejść środki przeciwdziałania walidacji schematu, szczególnie w bibliotekach takich jak OpenSAML.
.png>)
### XSW #8
* **Różnica od XSW #7**: Wykorzystuje inny mniej restrykcyjny element XML dla wariantu ataku.
* **Implikacja**: Oryginalny Assertion staje się dzieckiem mniej restrykcyjnego elementu, odwracając strukturę używaną w XSW #7.
.png>)
### Narzędzie
Możesz użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby przeanalizować żądanie, zastosować dowolny atak XSW, który wybierzesz, i go uruchomić.
## XXE
Jeśli nie wiesz, jakie rodzaje ataków to XXE, przeczytaj następującą stronę:
{% content-ref url="../xxe-xee-xml-external-entity.md" %}
[xxe-xee-xml-external-entity.md](../xxe-xee-xml-external-entity.md)
{% endcontent-ref %}
Odpowiedzi SAML to **skompresowane i zakodowane w base64 dokumenty XML** i mogą być podatne na ataki XML External Entity (XXE). Manipulując strukturą XML Odpowiedzi SAML, atakujący mogą próbować wykorzystać podatności XXE. Oto jak taki atak może być zobrazowany:
```xml
]>
...
...
...
[...]
```
## Tools
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby wygenerować POC z żądania SAML w celu przetestowania możliwych luk XXE i luk SAML.
Sprawdź także ten wykład: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## XSLT via SAML
Aby uzyskać więcej informacji na temat XSLT, przejdź do:
{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %}
[xslt-server-side-injection-extensible-stylesheet-language-transformations.md](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
{% endcontent-ref %}
Rozszerzalne przekształcenia arkuszy stylów (XSLT) mogą być używane do przekształcania dokumentów XML w różne formaty, takie jak HTML, JSON lub PDF. Ważne jest, aby zauważyć, że **przekształcenia XSLT są wykonywane przed weryfikacją podpisu cyfrowego**. Oznacza to, że atak może być skuteczny nawet bez ważnego podpisu; wystarczający jest podpis własnoręczny lub nieważny podpis, aby kontynuować.
Tutaj możesz znaleźć **POC** do sprawdzenia tego rodzaju luk, na stronie hacktricks wspomnianej na początku tej sekcji możesz znaleźć ładunki.
```xml
...
...
```
### Tool
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby wygenerować POC z żądania SAML w celu przetestowania możliwych podatności XSLT.
Sprawdź także ten wykład: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## XML Signature Exclusion
**XML Signature Exclusion** obserwuje zachowanie implementacji SAML, gdy element Signature jest nieobecny. Jeśli ten element jest brakujący, **walidacja podpisu może nie wystąpić**, co czyni go podatnym. Można to przetestować, zmieniając zawartość, która zazwyczaj jest weryfikowana przez podpis.
.png>)
### Tool
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Przechwyć odpowiedź SAML i kliknij `Remove Signatures`. W ten sposób **wszystkie** elementy Signature zostaną usunięte.
Po usunięciu podpisów, pozwól, aby żądanie przeszło do celu. Jeśli podpis nie jest wymagany przez usługę
## Certificate Faking
## Certificate Faking
Certificate Faking to technika testowania, czy **Dostawca Usług (SP) prawidłowo weryfikuje, że wiadomość SAML jest podpisana** przez zaufanego Dostawcę Tożsamości (IdP). Polega na użyciu \***certyfikatu samopodpisanego** do podpisania odpowiedzi SAML lub asercji, co pomaga w ocenie procesu walidacji zaufania między SP a IdP.
### Jak przeprowadzić Certificate Faking
Poniższe kroki przedstawiają proces przy użyciu rozszerzenia Burp [SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):
1. Przechwyć odpowiedź SAML.
2. Jeśli odpowiedź zawiera podpis, wyślij certyfikat do SAML Raider Certs, używając przycisku `Send Certificate to SAML Raider Certs`.
3. W zakładce Certyfikaty SAML Raider wybierz zaimportowany certyfikat i kliknij `Save and Self-Sign`, aby utworzyć samopodpisany klon oryginalnego certyfikatu.
4. Wróć do przechwyconego żądania w Proxy Burp. Wybierz nowy certyfikat samopodpisany z rozwijanej listy XML Signature.
5. Usuń wszelkie istniejące podpisy za pomocą przycisku `Remove Signatures`.
6. Podpisz wiadomość lub asercję nowym certyfikatem, używając przycisku **`(Re-)Sign Message`** lub **`(Re-)Sign Assertion`**, w zależności od potrzeb.
7. Prześlij podpisaną wiadomość. Sukces autoryzacji wskazuje, że SP akceptuje wiadomości podpisane przez twój certyfikat samopodpisany, ujawniając potencjalne podatności w procesie walidacji wiadomości SAML.
## Token Recipient Confusion / Service Provider Target Confusion
Token Recipient Confusion i Service Provider Target Confusion polegają na sprawdzeniu, czy **Dostawca Usług prawidłowo weryfikuje zamierzonego odbiorcę odpowiedzi**. W istocie, Dostawca Usług powinien odrzucić odpowiedź autoryzacyjną, jeśli była przeznaczona dla innego dostawcy. Krytycznym elementem jest tutaj pole **Recipient**, znajdujące się w elemencie **SubjectConfirmationData** odpowiedzi SAML. To pole określa URL, wskazujący, gdzie asercja musi być wysłana. Jeśli rzeczywisty odbiorca nie odpowiada zamierzonemu Dostawcy Usług, asercja powinna być uznana za nieważną.
#### **Jak to działa**
Aby atak Token Recipient Confusion (SAML-TRC) był wykonalny, muszą być spełnione określone warunki. Po pierwsze, musi istnieć ważne konto na Dostawcy Usług (nazywanym SP-Legit). Po drugie, docelowy Dostawca Usług (SP-Target) musi akceptować tokeny od tego samego Dostawcy Tożsamości, który obsługuje SP-Legit.
Proces ataku jest prosty w tych warunkach. Autentyczna sesja jest inicjowana z SP-Legit za pośrednictwem wspólnego Dostawcy Tożsamości. Odpowiedź SAML od Dostawcy Tożsamości do SP-Legit jest przechwytywana. Ta przechwycona odpowiedź SAML, pierwotnie przeznaczona dla SP-Legit, jest następnie przekierowywana do SP-Target. Sukces tego ataku mierzy się tym, że SP-Target akceptuje asercję, przyznając dostęp do zasobów pod tą samą nazwą konta używaną dla SP-Legit.
```python
# 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 funkcji wylogowywania
Oryginalne badania można znaleźć pod [tym linkiem](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/).
Podczas procesu brutalnego wymuszania katalogów odkryto stronę wylogowania pod:
```
https://carbon-prototype.uberinternal.com:443/oidauth/logout
```
Po uzyskaniu dostępu do tego linku 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 ujawniono, że parametr `base` akceptuje URL. Biorąc to pod uwagę, pojawił się pomysł, aby zastąpić URL `javascript:alert(123);` w próbie zainicjowania ataku XSS (Cross-Site Scripting).
### Masowe Wykorzystanie
[Z tych badań](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/):
Narzędzie [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) zostało użyte do analizy subdomen `uberinternal.com` dla domen wykorzystujących tę samą bibliotekę. Następnie opracowano skrypt, który celował w stronę `oidauth/prompt`. Ten skrypt testuje XSS (Cross-Site Scripting) poprzez wprowadzanie danych i sprawdzanie, czy są one odzwierciedlane w wyjściu. W przypadkach, gdy dane wejściowe są rzeczywiście odzwierciedlane, skrypt oznacza stronę jako podatną.
```python
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)
```
## Odniesienia
* [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-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-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://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/](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)
{% hint style="success" %}
Ucz się i ćwicz Hacking AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Ucz się i ćwicz Hacking GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Wsparcie HackTricks
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Dziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
{% endhint %}