Содержание статьи
Обойти сетевой файервол
Решение
Предположим, что в защищенном файерволом сегменте сети находится некая цель. Также допустим, что входящие соединения с этой целью запрещены, а исходящие от нее разрешены. При всем при этом файервол использует для подключения динамическую фильтрацию keep-state, с которой для начала нам и нужно разобраться. Проще говоря, динамическая фильтрация — это такая фильтрация, при которой для заданного правила автоматически создается обратное. Например, если есть правило «разрешить трафик от хоста А на хост Б с порта XYZ на ZYX по протоколу TCP», то для того, чтобы данные могли пройти обратно (от хоста Б к А), файервол также должен использовать соответствующее правило. При динамической фильтрации обратное правило создается автоматически, как только задействуется первое.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Теперь, когда мы определились с терминами, можно переходить непосредственно к обходу файервола. Теоретически мы никак не можем добраться до цели, так как любые наши попытки подключения (TCP-пакеты с SYN-флагом) будут блокироваться. Как ты наверняка знаешь, TCP/IP-протоколы очень гибкие, а RFC описывают далеко не все тонкости. На этом мы и сыграем.
Отдельные операционные системы, позволяют устанавливать соединения посредством TCP-пакета с некоторыми дополнительными флагами, за исключением SYN (как ты помнишь, для установки соединения по RFC должен присутствовать только этот флаг). К таким ОС относится как Windows, так и Linux (правда, не все версии). Полный список можно посмотреть по адресу goo.gl/9mu12. Какие именно дополнительные флаги нужны? Такие, которые являются легитимными при установленном соединении, то есть, к примеру, FIN, ACK, RST (этот список можно продолжать).
Итак, мы выбрали один из указанных выше флагов. Перейдем ко второму этапу, на котором нам нужно найти в файерволе определенный баг. Он заключается в том, что файер не проверяет присутствие SYN-флага для уже «установленного» соединения, то есть во входящем пакете не виден RST-флаг.
Думаю, теперь общий принцип атаки понятен. Мы должны подключиться к хосту с помощью TCP-пакета SYN + FIN, который не будет блокирован файерволом, так как тот сочтет, что мы используем установленное ранее соединение, а не инициализируем новое, запрещенное правилами. Атакуемый хост (наша цель) отправляет ответ SYN + ACK, а далее идут ACK'и, которые файервол и не должен блокировать, так как исходящий трафик от нашей цели разрешен.
Важный вопрос здесь заключается в том, как часто такие «дырки» встречаются в файерволах. Лично я не сталкивался с такими уязвимостями в живой природе, но видел на бескрайних просторах интернета несколько упоминаний о них. В любом случае идея мне кажется довольно интересной, так что дерзай!
Хакер #157. Деньги на багах в Chrome
Взломать сайт на WordPress
Решение
WordPress является одной из самых распространенных CMS в мире. Она имеет множество плагинов, тем и настроек, что позволяет с легкостью создавать самые специфические ресурсы, как большие, так и маленькие. Конечно, эта особенность привлекает к WordPress внимание и белых, и черных «шапок». Как это часто бывает, после обнаружения какого-либо критичного бага проносится волна взломов. Но если основной движок уже не преподносит таких сюрпризов, то его плагины — регулярно.
Для каждого популярного продукта или технологии существуют свои сканеры безопасности, позволяющие автоматизировать и облегчить труд хакера или ИБ-исследователя. Вот и для WordPress не так давно появился специализированный софт под названием WPScan. Автором этого творения является Ryan Dewhurst.
Функционал программы не так широк, как хотелось бы некоторым, однако в нем присутствует всё самое необходимое. Во-первых, это определение версии и имеющихся в ней паблик-уязвимостей. Во-вторых, определение плагинов (в базе WPScan'а их 2220) и, опять же, их уязвимостей. В качестве бонуса присутствует многопоточный брутфорсер имен и паролей. С точки зрения применяемых алгоритмов здесь всё тривиально: перебор и парсинг ответов. Следует учитывать, что это возможности лишь первой версии. По заверениям автора, в последующих будут присутствовать и сами эксплойты для найденных уязвимостей, что, согласись, приятно.
Пользоваться тулзой достаточно просто. (Надеюсь, на твоей машинке установлен Ruby? :))
ruby ./wpscan.rb --url www.example.com --enumerate p
Здесь "--url www.example.com" — это сканируемый хост, а параметр "--enumerate p" указывает на то, что модуль для определения плагинов подключен. Кстати, с помощью этой тулзы можно попробовать просканировать и свой ресурс, но лучше всё же воспользоваться специальными плагинами для WordPress вроде WP Security Scan.
Прокачать вывод из Nmap
Решение
Все мы знаем и используем в своих легальных и не очень делах такую утилиту, как Nmap. Одним из преимуществ этой программы являются способы вывода информации. У Nmap их четыре:
- nmap (-oN) — по дефолту.
- gnmap (-oG) — вывод в строку для удобного применения в grep.
- xml (-oX) — вывод в формате XML.
- $crIpt KiDDi3 (-oS) — для фанов leet speak.
Кроме того, используя аргумент -oA, можно организовать вывод сразу в первых трех перечисленных форматах. По факту самым юзабельным для операций поиска является формат gnmap, а для анализа — XML (через ZenMap, например). Но что если нам хочется приложить красивый лог скана к какому-нибудь отчету о проделанной работе? Ни один из приведенных форматов для этого не подходит. Можно, конечно, распарсить XML, но мы поступим проще!
Итак, идем на xmlsoft.org/XSLT/xsltproc.html и качаем там маленькую программку под названием xsltproc (кстати, она входит в комплект BackTrack), затем пишем в консоли следующую команду:
xsltproc nmap_scan.xml -o nmap_scan.html
Здесь первый параметр — это скан nmap в XML-формате, а второй — имя итогового файла. На выходе получаем симпатичный удобочитаемый HTML-документ. Отмечу, что, хотя всё это и выглядит довольно просто, описанная тулза имеет довольно широкие возможности — ее можно использовать для форматирования других типов XML-файлов.
Командовать сразу всеми шеллами из MSF
Решение
Хочу рассказать тебе об одном маленьком, но крайне юзабельном трюке. Если мы проникли сразу на несколько машин, то, чтобы не писать команды в каждой из полученных сессий, мы можем воспользоваться радостями доступа к Ruby прямо из консоли MSF, запустив постмодуль сразу во всех сессиях:
msf> use post/windows/gather/enum_domain_tokens
msf enum_domain_tokens> irb
framework.sessions.each_key do |session|
run_single("set SESSION #{session}")
print_status("Running #{active_module.fullname} against #{session}")
run_single("run")
sleep 1
end
Код получился тяжеловатым, но мы можем вписать его в rc-файл и при необходимости запускать с помощью следующих команд:
msf> use post/windows/gather/enum_domain_tokens
msf enum_domain_tokens> resource runall.rc
Всё! Постмодуль запущен на всех поовненных машинах. За эту идею респектуем Jcran'у.
ЗаDoSить сервер с помощью SSL
Решение
Продолжаем мучить SSL. В позапрошлом выпуске рубрики мы разбирали уязвимость под названием SSL Renegation vuln в SSLv3/TLS-протоколе. Информация о ней была обнародована в далеком 2009 году, поэтому в большинстве случаев она давно прикрыта. Как бы то ни было, официальные патчи уже есть, а renegation (то есть переинициализация того же защищенного TCP-соединения) уже не является опасной фичей, а потому у многих включена.
Теперь давай рассмотрим другую интересную особенность SSL-протоколов. При установке защищенного соединения сервер затрачивает гораздо больше процессорного времени (то есть больше использует процессор), чем клиент. Как ясно из задачи, этой особенностью можно воспользоваться в деструктивных целях. 🙂 К слову сказать, о ней известно довольно давно, но лишь недавно группа THC представила тулзу, которая реализует описываемый тип DoS-атаки для SSL. Атака фактически организуется путем множественных операций переинициализации защищенных соединений (renegation) в контексте одного SSL-соединения.
Какова мощь такой атаки? Всё достаточно сурово. Представители THC пишут, что сервер затрачивает на установку соединения в 15 раз больше ресурсов, чем клиент, а средний сервер может поддерживать порядка 300 инициализаций-соединений в секунду. Таким образом, имея всего лишь один атакующий хост с нормальным каналом связи (DSL), мы сможем завалить приличный сервер.
Насколько это соответствует действительности? Здесь есть интересные нюансы. ИБ-специалист Vincent Bernat провел исследование, посвященное способам защиты от SSL DoS'а. В ходе исследования он выяснил, что затраты процессорного времени сильно зависят от используемого алгоритма шифрования и, как видно из картинки, не настолько велики, хотя разница всё же заметна. Следовательно, успешность атаки теоретически определяется алгоритмом шифрования.
Что касается атаки на практике, то здесь всё просто. Берем известную тулзу от THC и запускаем ее следующим образом:
thc-ssl-dos.exe 127.1.1.1 443 --accept
Здесь 127.1.1.1 — IP нашей жертвы, 443 — порт атакуемого сервиса (поддержка SSL обязательна), "--accept" — подтверждение того, что мы не делаем ничего плохого. 🙂
Кстати, функция renegation вовсе не обязательна для атакуемого сервера. Атаковать можно и без нее, просто создав множество SSL-соединений, однако нагрузка на канал и клиентскую машину при этом увеличится в разы. Также атаку можно провернуть и без тулзы. Вот небольшой bash-скрипт от той же THC:
thc-ssl-dosit() { while :; do (while :; do echo R; done) |\
openssl s_client -connect 127.1.1.1:443 2>/dev/null; done }\
for x in `seq 1 100`; do thc-ssl-dosit & done
Хотелось бы также отметить, что атакуемым сервисом необязательно должен быть HTTPS. Подойдет любой другой порт, поддерживающий SSL (FTPs, POP3s), потому как сервер один и процессорное время тоже одно. Если же говорить о защите, то здесь потребуется как минимум отключить функции клиентского renegation'а, использовать менее навороченные алгоритмы шифрования и ограничить количество инициализаций-соединений с одного IP. Подробности ты найдешь по ссылке.
Обойти WAF
Решение
Как тебе уже наверняка известно, WAF (web application firewall) — это файервол, который работает на уровне приложения модели OSI. В простейшем виде эта штука нацелена на блокирование таких запросов к web-серверу, которые пытаются выполнить SQL-инъекцию или XSS. WAF уже давно превратился из модной фичи для гиков в необходимую для любого более-менее крупного веб-проекта вещь. Хотя на практике даже у тех организаций, которые, казалось бы, просто обязаны заботиться о безопасности пользовательских данных (банки, магазины), WAF'ы если и имеются, то только для галочки. То есть они или совершенно устарели, или просто не настроены, или же настроены, но неправильно. Предположим однако, что наша цель всё же защищена нормальным WAF. Что делать? Есть несколько основных способов их обхода. Одним из таких способов является модификация запросов к серверу. Обойти защиту с его помощью удается за счет того, что, хотя протокол HTTP стандартизирован и описан в множестве RFC, обработчики запросов для разных веб-серверов реализованы очень по-разному. Насколько сильно они отличаются, мы увидим дальше.
Одним из классических примеров издевательства над HTTP является прием HPP (HTTP Parameter Pollution). Что это? Для ответа обратимся к теории. Во-первых, к данным, которые пользователь передает серверу, присоединяется так называемая Query String. Она следует за символом «?». Во-вторых, данные пользователя разделяются на пары вида «имя_параметра=значение». В-третьих, эти пары конкатенируются друг с другом с помощью символа «&» или «;». Если пользовательские данные содержат спецсимволы, то они должны быть закодированы специальным образом (например, urlencode в PHP). Пример правильных запросов:
#GET
GET /foo?par1=val1&par2=val2 HTTP/1.1
#POST
POST /foo HTTP/1.1
Content-Length: 19
par1=val1&par2=val2
Итак, HPP представляет собой повторение имен параметров с разными значениями. Так как подобное поведение, по идее, не определено в RFC, то разные веб-сервера будут обрабатывать такие входные данные по-разному. Вот пример типичного «загрязнения параметров HTTP»:
GET /foo?par1=val1&par1=val2&par1=val3 HTTP/1.1
Этому запросу соответствуют следующие входные параметры:
- для ASP и ASP.NET — значения, разделенные запятыми (par1=val1,val2,val3);
- для Apache и PHP — последнее значение (par1=val3);
- для Apache и Perl — массив (ARRAY[0x8b9059c]);
- для Apache Tomcat — первое значение (par1=val1).
Чем эта информация может быть нам полезна? Как минимум позволит определить тип веб-сервера и используемую технологию. Максимум того, что она помогает выяснить, очень сильно зависит как от самого сервера, так и от того, как работают и каким функционалом обладают сами скрипты. Более подробно HPP описан в презентации от Luca Carettoni и Stefano di Paola. А теперь давай вернемся к обходу WAF и посмотрим, как применяется техника HPP, на примере ModSecurity для ASP:
#Такой запрос блокируется
index.aspx?page=select 1,2,3 from table where id=1/
#А такой — нет
index.aspx?page=select 1&page=2,3 from table where id=1
Следует учитывать, что HPP уже давно не является новой технологией. Указанная выше презентация датируется 2009 годом. Можно придумать бесконечное множество подобных HPP-трюков, чем и занялся Ivan Markovic из Network Solution (netsec.rs), который в итоге опубликовал небольшую whitepaper про HTTP Parameter Contamination (HPC). Чтобы лучше понять новый метод, давай снова обратимся к теории.
Итак, согласно RFC, для HTTP определены две группы символов:
- Зарезервированные, или специальные — a–z, A–Z, 0–9 and _ . ! ~ * ' ( ).
- Незарезервированные — ; / ? : @ & = + $ ,.
Однако если ты прямо сейчас посмотришь на свою клавиатуру, то обнаружишь там еще и символы { } | \ ^ [ ] `. Вот на них-то наш сербский друг и акцентировал свое внимание. Он вставлял эти символы в имена и значения параметров. Итоги его работы ты воочию сможешь увидеть на прилагаемом скриншоте.
В качестве доказательства эффективности HPC приведу несколько примеров обхода WAF.
- ModSecurity. Запрос вида http://localhost/?xp_cmdshell блокируется, а запрос http://localhost/?xp[cmdshell — нет.
- Обход dir traversal URLScan Запрос вида http://192.168.2.105/test.asp?file=../bla.txt блокируется, а запрос http://192.168.2.105/test.asp?file=.%./bla.txt — нет.
HTTP Parameter Contamination
