Итак, опять представим себе ситуацию. Есть сервер с административным веб-интерфейсом, есть админ и есть мы, а хотим мы поовнить данный сервачок. Предположим, что каких-то сверхкритичных уязвимостей на вебе найдено не было, а только, скажем, XSS’Ka. И вроде бы все отлично: хватай ХББ’кой куки, и вперед! Но как бы не так.Как минимум,проблемой может стать установленный сервером для кукисов флаг HTTPOnly, который не даст нам возможность вынуть их из браузера админа. Другой проблемой может стать фильтрация по IP доступа к веб-серверу или к самой админке. И что же тогда делать? Организовать туннель через XSS. Что бы там ни говорилось о продвинутом использовании XSS’ok, но самым мощным payload’oM, я думаю, является как раз XSS-туннель. Зачем нам аутентификационные куки, когда мы можем напрямую выполнять какие-то действия на сайте от имени нашей жертвы?
Но постой. Давай посмотрим, что же такое XSS-туннелинг. Если говорить в общем, то это специальный JavaScript, который подгружается ХББ’кой нашей жертве. Далее этот JS открывает какую-нибудь страницу на атакуемом сайте и полностью ее нам пересылает. Мы видим ее в своем браузере, кликаем, куда нужно, но наши действия не выполняются браузером, а передаются обратно в этот JS, который и произведет необходимые действия на атакуемом сайте, но от имени жертвы. Причем жертва об этом не будет догадываться.
Описание, конечно, очень общее, для понимания идеи. На практике все происходит несколько сложнее,количество элементов несколько больше, и это мы сейчас рассмотрим на примере BeEF.
BeEF — это специальный фреймворк для проведения мощных и глубоких атак на браузеры с использованием XSS’ok. На самом деле, может быть, не очень хорошо получается, что описывать такую прекрасную вещь, как BeEF, мне приходится в несколько строк, ведь она заслуживает отдельной статьи. Но я думаю, что в следующих выпусках мы это поправим.
Итак, BeEF представляет собой трехкомпонентную систему: 1. Браузеры жертв — hoocked browsers. Браузеры, в которые нам удалось подгрузитьсвой, аточнее BeEF’a, JavaScript-код. Ядро BeEF’a — главное связующее и всеобрабатывающее звено. Интерфейс BeEF’a, к которому атакующий подключается, используя свой браузер, и через который он может«управлять» жертвами. На самом деле не совсем управлять, а скорее за пускать те или иные атакующие модули.
Если посмотреть на это в процессе, то атакующий с помощью XSS’ok или просто заманив жертву себе на сайт, подгружает ей в браузер JS BeEF’a. Данный JS «устанавливает соединение»  с ядром фреймворка и ждет от него команд [систематически стучится]. Атакующий через интерфейс может указать действие для какого-нибудь из браузеров жертв, выполнить сканирование портов например. Ядро, получив от атакующего команду, переправит к жертве еще дополнительный кусок JS, который исполнит указанную команду (то есть сканирование портов], а результат отправится обратно в ядро. Кроме сканирования портов, можно в любой момент подгрузить какой-нибудь эксплойт, например, и захватить контроль над тачкой. На самом деле это очень мощная штука. Получается, что люди как бы садятся на крючок…

Но вернемся к туннелю. Одним из атакующих модулей BeEF’a является Tunnel Proxy (aka XSS-туннель].
Для того чтобы сделать XSS-туннель, нам потребуется прописать в нашем браузере специальный прокси-сервер от BeEF’a (по умолчанию 127.0.0.1, порт 6789). После этого все клики в нашем браузере (то есть HTTP-запросы! будут обрабатываться этим прокси. Данный прокси, получая запрос от атакующего, модифицирует его специальным образом и переправляет JS модулю BeEF’a в браузере жертвы. Этот модуль выполняет запрос на атакуемый сервер, но от имени заХЗБ’енной жертвы. Результаты запроса (HTML-страничка! получаются этим JS-модулем BeEF’a и переправляются обратно в ядро BeEF’a. Оттуда данные конвертируются и передаются на BeEF-прокси, который, в свою очередь, отображает страницу для браузера атакующего. То есть фактически атакующий видитто, что «видит» жертва. Далее атакующий может выполнить еще какое-то действие, например ввести какую-нибудь форму и отправить ее. Все эта операция повторится, JS BeEF’a отправит от имени жертвы данный запрос, и результаты его попадут обратно атакующему.

Взаимодействия в Сети, является одним из главных админских интерфейсов. И если атаки на другие интерфейсы (Web, SSL, RDPl мы уже разбирали в Easy Hack, то SSH почему-то обошли стороной. Что ж, исправляемся.
Итак, давай представим простую ситуацию: есть сетка, есть админ, есть сервер с открытым SSH, которым активно пользуется админ для удаленного администрирования. Нам же необходимо получить доступ к данному серваку. И как же это сделать? Ответ: сейчас чаще всего — никак. Ну, в смысле не совсем никак, но точно не через SSH. Здесь слабое звено стоит искать либо в других сервисах’сервера, либо в самом админе… Причины — высокая защищенность последней версии SSH на уровне протокола и малое количество эксплойтов под ПО… Хотя я, наверное, перегибаю палку, говоря «никак». Все же пути есть.
Конечно, первое, что приходит на ум, — bruteforce. Тогда ТНС Hydra нам в руки и в бой! Но возможно, это и не потребуется, если нам повезет. А наше везение во многом зависит оттого, насколько стар атакуемый сервер.
Наш шанс в том, что он будет поддерживать SSH версии 1. Эта версия протокола SSH имеет серьезную проблему, которая позволяет нам, атакующим, провести классическую man-in-the-middle атаку и в итоге видеть незашифрованный трафик. В общем виде атака представляет собой следующий процесс:
1. Мы проводим ARP-спуфинг между админом и сервером и таким образом контролируем передаваемый трафик.
2. Админ коннектится на сервер noSSH.
3. Серверотправляетсвой открытый ключ клиенту.
4. Мы подменяем этотключик на свой.
5. КлиентЭБИ админа выбираетшифрование, генеритсессионный ключ, шифрует его открытым ключом сервера и отправляет его.

6. Та к ка к клиентзашифровал сессионный ключ нашим открытым ключом, то мы его расшифровываем и передаем дальше серверу.
7. Зашифрованное соединение на основе сессионного ключа установлено. Но мы знаем этот ключ, а потому можем расшифровывать проходящий через нас трафик.
Этот процесс и показан на рисунке. Фактически данную атаку можно реализовать с помощью Ettercap или Cain.
Теперь же самое важное — как много осталось серверов, которые поддерживают SSH v1? Точно я не скажу, но во время проведения пентестов они систематически попадаются. Сама атака стала общеизвестна году так в 2000-2001-м. А потому почти все новые серваки и железки поставляются уже с правильной версией SSH. Но в то же время всякое пятилетнее оборудование может быть уязвимо. Особенно это относится к сетевому оборудованию и всевозможным нестандартным железкам (например, контроллерам], безопасностью которых производители плохо занимаются.

В прошлый раз мы начали разбирать классические и не очень классические DoS-атаки на веб-серверы. Сегодня продолжим, поэтому я опускаю вводную часть.
Итак, позвольте рассказать про атаку slow HTTP POST DoS. Название ее определенно говорящее. Идея атаки в том, чтобы уложить HTTP-сервер за счет использования «медленных» P0ST-запросов на сервер. Так, в заголовке POST-запроса клиент передает серверу Content-Length большого значения, а после удачного запроса начинает очень медленно передавать данные. Веб-сервер получаеттакой POST-запрос, видит в нем Content-Length и ждет соответствующее значение данных в теле запроса, но, как я уже сказал, данные приходят к нему медленно, по чуть-чуть.
Таким образом, атакующий, имея под своим контролем небольшое количество хостов (возможно, даже один], может создавать такие «висящие коннекты» и израсходовать ресурсы сервера, так что тот не сможет отвечать легитимным клиентам. Исчерпавшиеся ресурсы могут быть различны. Например, можно занять все потоки или занять ими всю память.

Как видно, данная атака основывается на «уязвимостях» самого протокола HTTP. Ведь мы не вылезаем за рамки протокола, а эмулируем множественное подключение медленных клиентов. То есть с точки зрения логов, если все настроить правильно, жертва может долго не догадываться о причинах падения ее сервака. Такая «нормальность» атаки рождает достаточно неприятную проблему — от нее непросто защититься.

Если посмотреть более общим взглядом, то можно заметить, что данная атака во многом похожа на описанный в прошлом номере Slowloris. Да и вообще вспоминаются разнообразные олдскульные атаки, типа SYN-flood’a, — история повторяется на новом уровне. Но даже с учетом большого сходства Slowloris и Slow POST’a они достаточно различны с точки зрения атакующего потенциала. Как минимум если, используя Slowloris, можно завалить в основном Apache-подобные веб-серверы, то slow POST’y подвержены почти все основные серверы. Это и тот же Apache, и все версии IIS, и что-то альтернативное вроде lighttpd. Что касается nginx, то ситуация с ним не совсем ясна. Чисто теоретически он не должен быть подвержен такой атаке, но фактически, с учетом тех или иных настроек его самого и ОС, на которой он крутится, иногда получается его завалить.

Данный пост трудно назвать задачей, скорее это некая приятность для пентестера, которой я и хочу поделиться.
Ползая между различными проксиками типа Webscarab, ZAP, Burp и так далее, я в итоге (или пока что) остановился именно на Burp’e. Имхо, Webscarab подводит количество багов и отсутствие новых версий, a ZAP — некая недоразвитость… В то же время такая тулза, как sqlmap, которая используется для продвинутой раскрутки SQL-инъекций, тоже очень хороша и местами приятно выделяется на фоне конкурентов. Хотя с ней есть некоторые трудности. А именно — с увеличением функционала количество консольных параметров разрослось до неадекватного . То есть без GUI с ней работать не очень удобно. Хотя надо отметить, что пучок сторонних гуев к ней имеется. Но дело не в этом. Чисто по-человечески приятно, когда у тебя «все под рукой» и когда работа по возможности автоматизирована. И похоже, не я один так думаю.
Как и у собратьев Burp’a, у него самого есть система добавления дополнительных плагинов, что иногда очень выручает [но об этом лучше написать отдельную статью). Так, добрый пенте-стер под ником crOhn взял и реализовал аддон к Burp’y — GUI-прослойку для sqlmap. Теперь, прикрутив плагин, мы должны всего лишь выбрать необходимый URL, кликнуть правой кнопкой и отправить его в гуишку. А далее уже работать с sqlmap через этот гуи. В качестве дополнительного бонуса гуя сейчас имеется поиск по выводу и его экспорт в файл (то есть лучше обыкновенной виндовой консоли).

Wireshark — анализатор протоколов (или сниффер). Прекрасная тул-за, во многом незаменимая. Она не случайно входит в десятку самых необходимых хак-софтин. Конечно, ее главным плюсом являются разнообразнейшие диссекторы, то есть «парсеры» тех или иных протоколов, которые Wireshark «интеллектуально» применяет в зависимости от протоколов, портов и прочего. Но если с низкими протоколами (IP, TCP, ARP, Ethernet) чаще всего все достаточно просто, то с верхними, уровня приложений, частенько возникаюттрудности. Особенно когда используются нестандартные связки [инкапсуляция) протоколов или нестандартные порты. На самом деле это небольшая проблема. Хотя некоторые и не в курсе, но Wireshark позволяет четко указывать, какой уровень и каким диссектором парсить. Все, что требуется, — выделить «странный» пакет по правой кнопке, выбрать «Decode as…» и указать необходимый протокол. В качестве практического примера могу отправить к разбору процедуры аутентификации клиентом на MS SQL сервере без включенного обязательного шифрования трафика.

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!