SAML Attacks
SAML Attacks
Basic Information
SAML BasicsTool
SAMLExtractor: Інструмент, який може взяти URL або список URL і вивести SAML consume URL.
XML round-trip
В XML підписана частина XML зберігається в пам'яті, потім виконується деяке кодування/декодування, і перевіряється підпис. В ідеалі це кодування/декодування не повинно змінювати дані, але на основі цього сценарію, дані, що перевіряються, і оригінальні дані можуть не бути однаковими.
Наприклад, перевірте наступний код:
Виконання програми проти REXML 3.2.4 або раніше призведе до наступного виходу замість цього:
Це те, як REXML побачив оригінальний XML документ з програми вище:
А це те, як він побачив його після етапу парсингу та серіалізації:
Для отримання додаткової інформації про вразливість та способи її використання:
Атаки на обгортку 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 EntitySAML відповіді є зменшеними та закодованими в base64 XML документами і можуть бути вразливими до атак XML External Entity (XXE). Маніпулюючи структурою XML SAML відповіді, зловмисники можуть намагатися експлуатувати вразливості XXE. Ось як така атака може бути візуалізована:
Tools
Ви також можете використовувати розширення Burp SAML Raider для генерації POC з SAML запиту для тестування на можливі вразливості XXE та SAML вразливості.
Перегляньте також цю доповідь: https://www.youtube.com/watch?v=WHn-6xHL7mI
XSLT via SAML
Для отримання додаткової інформації про XSLT перейдіть за посиланням:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)Перетворення розширювальної таблиці стилів (XSLT) можуть використовуватися для перетворення XML документів у різні формати, такі як HTML, JSON або PDF. Важливо зазначити, що перетворення XSLT виконуються до перевірки цифрового підпису. Це означає, що атака може бути успішною навіть без дійсного підпису; самопідписаний або недійсний підпис є достатнім для продовження.
Тут ви можете знайти POC для перевірки на такі вразливості, на сторінці hacktricks, згаданій на початку цього розділу, ви можете знайти корисні payloads.
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:
Перехопіть SAML Response.
Якщо відповідь містить підпис, надішліть сертифікат до SAML Raider Certs, використовуючи кнопку
Send Certificate to SAML Raider Certs
.У вкладці сертифікатів SAML Raider виберіть імпортований сертифікат і натисніть
Save and Self-Sign
, щоб створити самопідписаний клон оригінального сертифіката.Поверніться до перехопленого запиту в проксі Burp. Виберіть новий самопідписаний сертифікат з випадаючого списку XML Signature.
Видаліть будь-які існуючі підписи за допомогою кнопки
Remove Signatures
.Підпишіть повідомлення або підтвердження новим сертифікатом, використовуючи кнопку
(Re-)Sign Message
або(Re-)Sign Assertion
, відповідно.Перешліть підписане повідомлення. Успішна аутентифікація вказує на те, що 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.
XSS в функції виходу
Оригінальне дослідження можна знайти за цим посиланням.
Під час процесу брутфорсингу директорій була виявлена сторінка виходу за адресою:
При доступі до цього посилання відбулася переадресація на:
Це виявило, що параметр base
приймає URL. Враховуючи це, виникла ідея замінити URL на javascript:alert(123);
в спробі ініціювати атаку XSS (Cross-Site Scripting).
Масове використання
Інструмент SAMLExtractor був використаний для аналізу піддоменів uberinternal.com
для доменів, які використовують ту ж бібліотеку. Після цього був розроблений скрипт для націлювання на сторінку oidauth/prompt
. Цей скрипт тестує на наявність XSS (Cross-Site Scripting), вводячи дані та перевіряючи, чи відображаються вони в виході. У випадках, коли введені дані дійсно відображаються, скрипт позначає сторінку як вразливу.
Посилання
Last updated