SAML Attacks
Ataki SAML
Podstawowe informacje
pageSAML BasicsNarzę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:
Uruchomienie programu przeciwko REXML 3.2.4 lub wcześniejszej wersji spowoduje zamiast tego następujący wynik:
Oto, jak REXML widział oryginalny dokument XML z programu powyżej:
A oto, jak widział go po rundzie analizy i serializacji:
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.
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.
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.
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.
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.
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ę.
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.
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ę:
pageXXE - XEE - XML External EntityOdpowiedzi 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:
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:
pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)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.
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.
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:
Przechwyć odpowiedź SAML.
Jeśli odpowiedź zawiera podpis, wyślij certyfikat do SAML Raider Certs, używając przycisku
Send Certificate to SAML Raider Certs
.W karcie Certyfikatów SAML Raider, wybierz zaimportowany certyfikat i kliknij
Save and Self-Sign
, aby utworzyć samopodpisaną kopię oryginalnego certyfikatu.Wróć do przechwyconego żądania w Proxy Burp. Wybierz nowy certyfikat podpisany przez siebie z rozwijanego menu Podpisu XML.
Usuń istniejące podpisy za pomocą przycisku
Remove Signatures
.Podpisz wiadomość lub twierdzenie nowym certyfikatem, używając przycisku
(Re-)Sign Message
lub(Re-)Sign Assertion
, w zależności od sytuacji.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.
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:
Po uzyskaniu dostępu do tego linku nastąpiło przekierowanie na:
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
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ą.
Odnośniki
Last updated