<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, 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** 🐦 [**@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.
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Narzędzie, które może przyjąć adres URL lub listę adresów URL i zwraca adres URL do konsumpcji SAML.
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**.
W **atakach na Podpisy XML (XSW)** przeciwnicy wykorzystują podatność wynikającą z przetwarzania dokumentów XML w dwóch różnych fazach: **walidacji podpisu** i **wywołania funkcji**. Te ataki 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**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **i** [**tej publikacji**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Więc sprawdź je dla dalszych szczegółów.
* **Strategia**: Dodanie nowego elementu głównego zawierającego podpis.
* **Konsekwencje**: Walidator może się pogubić między prawidłowym "Odpowiedź -> Twierdzenie -> Podmiot" a "złowrogią nową Odpowiedzią -> Twierdzeniem -> Podmiotem" atakującego, prowadząc do problemów z integralnością danych.
* **Strategia**: Wstawienie elementu Rozszerzenia 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.
Możesz użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e), aby przeanalizować żądanie, zastosować wybrany atak XSW i go uruchomić.
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:
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) do generowania POC z żądania SAML w celu przetestowania potencjalnych podatności na XXE oraz podatności SAML.
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 nieprawidłowy 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 ładunki.
Możesz również użyć rozszerzenia Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) do generowania POC z żądania SAML w celu przetestowania potencjalnych podatności XSLT.
**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 system podatnym. Można to przetestować poprzez zmianę zawartości, która zazwyczaj jest weryfikowana przez podpis.
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 Podpisu są usuwane.
Fałszowanie Certyfikatu to technika testowania, czy **Usługodawca (SP) prawidłowo 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.
2. Jeśli odpowiedź zawiera podpis, prześ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 rozwijanej listy 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`**, odpowiednio.
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 i Dezorientacja Celu Usługodawcy polegają na sprawdzeniu, czy **Usługodawca poprawnie weryfikuje zamierzonego odbiorcę odpowiedzi**. W zasadzie 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.
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, którą użyto dla SP-Legit.
To ujawniło, że parametr `base` akceptuje adres URL. Biorąc to pod uwagę, pojawił się pomysł podmiany adresu URL na `javascript:alert(123);` w celu próby wywołania ataku XSS (Cross-Site Scripting).
Do analizy subdomen `uberinternal.com` pod kątem 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 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ą.
<summary><strong>Nauka hakowania AWS od zera do bohatera z</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, 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** 🐦 [**@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.
