Брут-форс веб-сайтов: инструкция по использованию patator, Hydra, Medusa

Брут-форс входа: эффективен даже на сайтах без уязвимостей

Брут-форс (перебор паролей) на веб-сайтах вызывает больше всего проблем у (начинающих) пентестеров. Если перебирать пароли на разных, например, FTP серверах, то команды, которыми запускаются программы, будут мало отличаться друг от друга – только различные цели. Если же мы переходим к перебору паролей в веб-формах, то тут всё по-другому: трудно найти два сайта, на которых был бы одинаковый набор полей формы с одинаковыми именами и одинаковое поведение при успешном или неуспешном входе.

Кроме этого разнообразия, даже без проактивной защиты веб-форма может быть создана разработчиком так, что в неё уже после нажатия на кнопку «Отправить» добавляются поля, без которых сервер не принимает форму. Анализом статичного кода это выяснить иногда очень непросто. Также на стороне веб-мастера очень легко реализовать такие анти-брутфорс меры как добавление скрытых полей со случайными значениями, анализ заголовка Referer и прочее. Всё это требует дополнительных сил на анализ.

Ну а если в дело вступают серьёьзные проактивные защиты, такие как капча, блокировка попыток входа при нескольких неудачных попытках, двухфакторная аутентификация и т.д., то даже у опытных пентестеров опускаются руки.

И тем не менее, брут-фос учётных данных на веб-сайтах очень интересен для тестеров на проникновение. Поскольку если ПО сервера и веб-приложения не содержит известных уязвимостей, то подбор пароля остаётся одним из немногих методов компрометации.

Программы patator, Hydra, Medusa могут перебирать пароли для разнообразных служб, но мы остановимся именно на веб-формах. В этом разделе мы познакомимся с этими программами поближе, узнаем, как получить полный список передаваемых формой полей и научимся перебирать пароли в этих веб-формах с помощью patator, Hydra, Medusa.

Брут-форс формы, передающей данные методом GET, я буду показывать на примере Damn Vulnerable Web Application (DVWA). А перебор паролей формы, передающей данные методом POST я буду показывать на примере OWASP Mutillidae II. Я буду работать с этими уязвимыми веб-приложениями, предустановленными в Web Security Dojo.

Да и, пожалуй, рассмотрим ещё брут-форс входа на нескольких актуальных версиях реальных веб-приложений.

Передача данных из формы аутентификации на веб-сервер

Методы отправки данных

Как уже было упомянуто, веб-формы могут отправлять данные методом GET или POST.

get

Этот метод предназначен для получения требуемой информации и передачи данных в адресной строке. Пары «имя=значение» присоединяются в этом случае к адресу после вопросительного знака и разделяются между собой амперсандом (символ &). Удобство использования метода get заключается в том, что адрес со всеми параметрами можно использовать неоднократно, сохранив его, например, в закладки браузера, а также менять значения параметров прямо в адресной строке.

post

Метод post посылает на сервер данные в запросе браузера. Это позволяет отправлять большее количество данных, чем доступно методу get, поскольку у него установлено ограничение в 4 Кб. Большие объемы данных используются в форумах, почтовых службах, заполнении базы данных, при пересылке файлов и др.

Пример формы, которая отправляет данные методом GET:

<form action="handler.php" method="get">

    <p><input type="text" name="str"></p>

    <p><input type="submit" value="Отправить"></p>

</form>

Обратите внимание на action="handler.php" – значение этого атрибута говорит о том, что данные будут отправлены файлу handler.php. Т.е. если я введу в текстовое поле, например hackware, то после нажатия на кнопку «Отправить» будет открыта страница ./handler.php?str=hackware

Пример формы, которая отправляет данные методом POST:

<form action="handler.php" method="post">

    <p><input type="text" name="str"></p>

    <p><input type="submit" value="Отправить"></p>

</form>

Если я введу в текстовое поле, например hackware, то после нажатия на кнопку «Отправить» будет открыта страница ./handler.php, т.е. в адресной строке передаваемые данные не отображаются.

Пусть вас не сбивает с толку формы, в которых отсутствуют атрибуты method и/или action. Они не являются обязательными. Если они отсутствуют, то используются значения по умолчанию. Для method это get, а для action – сама страница с формой (т.е. данные отправляются тому же скрипту/файлу, который показывает форму).

Отправляемые данные

Казалось бы, для формы вполне логично отправлять ровно два поля: имя пользователя и пароль. Тем не менее, часто формы содержат скрытые поля и поля, добавляемые на лету. Это важно знать, поскольку даже при верном логине и пароле форма выдаст ошибку входа, если отсутствуют другие требуемые данные.

Поведение веб-приложения при получении данных для входа

Проверка успешности входа

Как узнать, вошли ли мы? Т.е. как понять, что пароль успешно угадан? Для этого анализируется страница, которая присылается после попытки входа. Иногда мы не можем знать, что показывается залогиненому пользователю, поскольку у нас нет действительной учётной записи. Поэтому популярным стал метод от противного: мы пробуем ввести какой-либо логин и пароль и смотрим на ошибку. Нарпимер, это может быть «Account does not exist». Далее программа по перебору сравнивает выдаваемые ей страницы и если там отсутствует строка «Account does not exist», значит пароль подобран.

Также программы брут-форсинга могут работать и со строками, отображающимися при успешном входе.

Поведение веб-приложения при удачном или неудачном входе не ограничивается только показом сообщения. Также вместе или даже вместо показа какого-либо сообщения веб-приложение может:

осуществлять редирект (например, в случае удачного входа пользователь перенаправляется в админку или на свою страницу);
записывать кукиз (в случае верного логина и пароля сервер отправляет кукиз с данными сессии. И на основании этих кукиз веб-приложение показывает вошедшему пользователю кнопки редактирования, ссылку на админ.панель и т.д.).

И ещё по поводу отображаемых данных – многие популярные веб-приложения имеют поддержку многих языков. Это также важно учитывать, поскольку вы ожидаете от знакомого вам веб-приложения «Account does not exist», а с учётом своей локали оно будет показывать «ไม่มีบัญชีอยู่»…

Кукиз, заголовки, скрытые поля, случайные данные в скрытых полях

Нужно помнить о таких возможных моделях поведения веб-приложения как:

присваивать кукиз с сессией каждому, кто открыл веб-форму, а при получении из неё данных, проверять, имеется ли такая сессия. Если сессии нет, то не принимать даже верный пароль. Т.е. перед каждой попыткой требуется получить веб-страницу с формой, при этом сохранить полученные кукиз для отправки их вместе с кандидатами в логины и пароли;
при каждом обновлении страницы форма может содержать скрытые поля со случайными данными. Это требует перед каждой попыткой получение формы, извлечение этих случайных данных, добавление их в передаваемое с логином и паролем тело запроса;
могут быть упрощённые варианты: статичные кукиз и статичные данные в скрытых полях формы. Это не требует получения их при каждой попытки входа. Но нужно не забывать добавлять значение скрытых полей в тело запроса, а про кукиз помнить, что сессия может закончиться по таймауту и нужно получить новое куки.

Сбор имён пользователей

Некоторые веб-приложения содержат имена пользователей (логин) на страницах их профилей, иногда в качестве части адреса страницы профиля, иногда необходимо использовать дополнительные программы для выявления логинов (например, для WordPress это может делать WPScan). На это не нужно жалеть времени. Если удастся собрать валидные логины пользователей, то это очень-очень сильно сократит время подбора по сравнению если бы мы брали имена пользователей из словаря.

Мы ещё даже не начали знакомиться с программами для перебора, а матчасть получилась значительной. В этом и заключается сложность брут-форса входа веб-приложения – они все разные и каждое требует индивидуального подхода.

Подготовка Web Security Dojo

Установим необходимые нам программы и немного обновимся (это внутри Web Security Dojo):

sudo apt-get update

# sudo apt-get dist-upgrade # по желанию можно выполнить полное обновление системы. Если вы это сделали, то перезагрузитесь перед продолжением

sudo apt-get install python-pycurl libcurl4-openssl-dev automake autoconf m4 perl

sudo pip install --upgrade pip

sudo pip install --upgrade pycurl

Установим свежую версию Medusa из исходных кодов:

sudo apt-get remove medusa

git clone https://github.com/jmk-foofus/medusa

cd medusa/

autoreconf -f -i

./configure

make

sudo make install

/usr/local/bin/medusa --help

Установим свежую версию Hydra из исходных кодов:

sudo apt-get install libssl-dev libssh-dev libidn11-dev libpcre3-dev libgtk2.0-dev libmysqlclient-dev libpq-dev libsvn-dev firebird2.1-dev libncp-dev

git clone https://github.com/vanhauser-thc/thc-hydra.git

cd thc-hydra/

./configure

make

sudo make install

Скачаем последнюю версию скрипта patator:

wget https://raw.githubusercontent.com/lanjelot/patator/master/patator.py

chmod +x patator.py

./patator.py

Ещё обратите внимание, что я обновил Damn Vulnerable Web Application (DVWA) и Damn Vulnerable Web Application (DVWA) до последних версий. Как это сделать описано на соответствующих страницах по приведённым ссылкам.

Ещё нам понадобятся списки слов (словари). Скачаем парочку, если с ними не получится подобрать пароль, то позже скачаем ещё и другие словари:

wget https://raw.githubusercontent.com/1N3/BruteX/master/wordlists/namelist.txt

wget https://raw.githubusercontent.com/1N3/BruteX/master/wordlists/password_medium.txt

Самую свежую версию Burp Suite можно скачать по ссылке: https://portswigger.net/DownloadUpdate.ashx?Product=Free

Сбор данных о работе веб-формы

Нужно начать со сбора данных о работе веб-формы. Анализ статичных данных (HTML кода) может быть трудным и очень легко что-то пропустить. Поэтому мы будем анализировать «живые» данные, которые непосредственно отправляет браузер. Для подобного анализа нам нужен прокси. Мы воспользуемся Burp Suite Free Edition.

Настройка прокси в Burp Suite для анализа данных передаваемых из веб-формы

Запустите Burp Suite, это можно сделать из меню, либо, если вы скачали свежую версию, так:

java -jar ./Downloads/burpsuite_free_*.jar

Переходим во вкладку Proxy -> Options. Там в самом верху в Proxy Listeners нажимаем Add и добавляем новый прослушиватель: на любом не занятом порту, например, 7070. В качестве Specific Address выберите IP компьютера атакующего (т.е. той машины, где запущен Burp).

Здесь же перейдите во вкладку Request handling и поставьте галочку на Support invisible proxying (enable only if needed).

Когда добавите новый прослушиватель, поставьте галочку там, где Running (это будет означать, что он задействован в данное время).

Теперь спуститесь в самый низ, найдите Allow requests to web interface using fully-qualifyed DNS hostnames и поставьте там галочку.

Теперь перейдите в Proxy -> Intercept, отключите его.

Теперь в браузере открываете Настройки -> Advanced -> Network -> Connections Settings.

Там выберите Manual Proxy Configuration и в полях HTTP Proxy введите IP и порт прокси в Burp Suite.

Брут-форс веб-форм, использующих метод GET

В Web Security Dojo переходим к Damn Vulnerable Web Application (DVWA) по адресу http://localhost/dvwa/login.php:

Обратите внимание, для входа у нас запрашивается логин и пароль. Мы будем брутфорсить не эту форму (хотя ничего не помешало бы нам это сделать). Эта форма служит для доступа в DVWA, страницы которой содержат уязвимые веб-приложения, в том числе те, которые предназначены для входа, но от которых мы не знаем пароли. От этой формы мы знаем пару логин:пароль, введём их. Скорее всего, после этого в наш браузер будет записана куки. При каждом обращении к страницам DVWA, сервер будет запрашивать куки и сверять – имеется ли такая сессия. Если сессия имеется, то мы будем беспрепятственно просматривать страницы DVWA. Очень хорошо, что мы обратили на это внимание – ведь нам нужно настроить наши программы для брутфорса так, чтобы и они отправляли куки с валидной сессией, иначе они не смогут «общаться» с внутренними страницами DVWA, которые содержат веб-форму, которую мы хотим брут-форсить.

Перейдите в DVWA Security и поставьте низкий уровень безопасности (Low), сохраните сделанные изменения:

Переходим во вкладку Brute Force.

На самом деле, там под звёздочками уже имеется пароль пользователя admin. Но наша задача заключается узнать этот пароль с помощью брут-форса. Дополнительно в задании нам сообщили о четырёх пользователях, пароли которых также нужно узнать. Поэтому я дописываю к паролю одну цифру, чтобы сделать его заведомо неверным, нажимаю Отправить. На странице сайта мы видим:

Важной информацией является следующее:

при неверном пароле сервер выдаёт надпись «Username and/or password incorrect.»
судя по адресу http://localhost/dvwa/vulnerabilities/brute/?username=admin&password=password11&Login=Login# сервер использует отправку данных методом GET.

Кстати, то, что форма отправляет значения некоторых величин методом GET, вовсе не означает, что она одновременно не отправляет значения методом POST. Когда передо мной стояла задача реализации одновременной отправки данных методом GET и POST с помощью AJAX, то задача оказалась довольно простой в решении. В данном случае данные отправляются только методом GET, но нужно помнить, что могут быть более необычные варианты.

Теперь переходим в Burp Suite для анализа данных:

Важные строки:

GET /dvwa/vulnerabilities/brute/?username=admin&password=password11&Login=Login HTTP/1.1
Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2

Первая говорит о том, что данные передаются только методом GET, а также содержит строку запроса /dvwa/vulnerabilities/brute/?username=admin&password=password11&Login=Login

Вторая содержи куки, без которого нас не пустят на внутренние страницы сервера. Т.е. их также нужно обязательно указывать.

В некоторых случаях также важной могла бы оказаться строка с Referer:

Referer: http://localhost/dvwa/vulnerabilities/brute/

Но данное веб-приложение не проверяет Referer, поэтому в программе необязательно указывать этот заголовок.

Также посмотрим ответ веб-сервера:

Редиректа (Location:) и записи новых кукиз не происходит. А в ответе при неверном пароли присутствует слово «incorrect»:

Мы собрали достаточно данных, переходим к составлению команды для запуска брутфорса.

Использование patator для брут-форса веб-форм, передающих данные методом GET

Если предыдущий материал показался вам сложным, то у меня для вас плохая новость – сложное начинается только сейчас. Поэтому собрались! ))

patator предназначен для брут-форса большого количества разнообразных служб (и не только служб, кстати). Для брут-форса входа веб-приложений предназначен модуль http_fuzz.

Страница patator в Энциклопедии инструментов хакера является огромной. Это связано с большим количеством доступных модулей и примеров. Давайте выпишем только те опции, которые нам могут пригодиться для подбора пароля веб-сайтов:

Глобальные опции patator (применимы ко всем модулям, в том числе и для http_fuzz):

  Выполнение:

    -x arg              действия и условия, смотри Синтаксис ниже

    --resume=r1[,rN]*   возобновить предыдущий запуск

    -e arg              кодировать всё между двумя тэгами, смотри Синтаксис ниже

    -C str              разделитель строки в комбо файлах (по умолчанию это ':')

    -X str              разделитесь строки в условиях (по умолчанию это ',')

    --allow-ignore-failures

                        неудачи не могут быть проигнорированы с -x (это 

                        сделано специально во избежания ложных срабатываний)

                        эта опция переписывает это поведение

  Оптимизация:

    --rate-limit=N      ждать N секунд между каждым тестом (по умолчанию это 0)

    --timeout=N         ждать N секунд ответа перед повторной попыткой 

                        (по умолчанию 0)

    --max-retries=N     пропустить полезную нагрузку после N попыток (по 

                        умолчанию это 4) (-1 для бесконечности)

    -t N, --threads=N   количество потоков (по умолчанию это 10)

Синтаксис:

 -x действия:условия

    действия    := действие[,действие]*

    действие    := "ignore" | "retry" | "free" | "quit" | "reset"

    условия     := условие=значение[,условие=значение]*

    условие     := "code" | "size" | "time" | "mesg" | "fgrep" | "egrep"

    ignore      : не сообщать

    retry       : пробовать полезную нагрузку снова

    free        : отклонить будущие подобные полезные нагрузки

    quit        : прекратить выполнение сейчас

    reset       : закрыть текущее подключение для переподключения в следующий раз

    code        : соответствие коду статуса

    size        : соответствие размеру (N или N-M или N- or -N)

    time        : соответствие времени (N или N-M или N- or -N)

    mesg        : соответствие сообщению

    fgrep       : поиск строки в сообщении

    egrep       : поиск регулярного выражения в сообщении

Например, для игнорирования всех перенаправлений на домашнюю страницу:

... -x ignore:code=302,fgrep='Location: /home.html'

 -e тэг:кодировка

    тэг         := любая уникальная строка (например, T@G или _@@_ или ...)

    кодировка   := "unhex" | "sha1" | "b64" | "url" | "hex" | "md5"

    unhex       : декодировать из шестнадцатеричной

    sha1        : хэш в sha1

    b64         : кодировать в base64

    url         : url кодирование

    hex         : кодировать в шестнадцатеричную

    md5         : hash в md5

Например, для кодирования каждого пароля в base64:

... host=10.0.0.1 user=admin password=_@@_FILE0_@@_ -e _@@_:b64

Опции модуля http_fuzz:

url           : целевой url (схема://хост[:порт]/путь?запрос)

body          : данные тела

header        : использовать пользовательские заголовки

method        : метод для использования [GET | POST | HEAD | ...]

auto_urlencode: автоматически выполнять URL-кодирование [1|0]

user_pass     : имя пользователя и пароль для HTTP аутентификации (пользователь:пароль)

auth_type     : тип HTTP аутентификации [basic | digest | ntlm]

follow        : следовать любому редиректу Location [0|1]

max_follow    : предел редиректов [5]

accept_cookie : сохранить полученные кукиз для отправки их в следующих запросах [0|1]

http_proxy    : HTTP прокси для использования (host:port)

ssl_cert      : файл клиентского SSL сертификата (cert+key в PEM формате)

timeout_tcp   : секунд для ожидания TCP хендшейка [10]

timeout       : секунд для ожидания HTTP ответа [20]

before_urls   : разделённые запятой URL для запроса перед основным запросом

before_header : использовать пользовательский заголовок в запросе before_urls 

before_egrep  : извлечь данные из before_urls ответа для размещения в главный запрос

after_urls    : разделённые запятыми URL для запроса после главного запроса

max_mem       : сохранять не более чем N байт данных запроса+ответа в памяти [-1 (неограниченно)]

persistent    : использовать постоянные соединения [1|0]

Давайте начнём строить нашу команду для запуска перебора паролей с помощью patator.

Начинаться она будет с ./patator.py http_fuzz, здесь ./patator.py – это расположение файла скрипта, а http_fuzz – название используемого модуля.

Как мы помним, серверу передаётся строка /dvwa/vulnerabilities/brute/?username=admin&password=password11&Login=Login, которая является относительным адресом страницы. Абсолютный адрес в нашем случае выглядит так http://localhost/dvwa/vulnerabilities/brute/?username=admin&password=password11&Login=Login. Этот адрес мы указываем с опцией url: url="http://localhost/dvwa/vulnerabilities/brute/?username=admin&password=password11&Login=Login"

Слово admin мы заменяем на заполнитель FILE0 а вместо password11 указываем второй заполнитель FILE1. В итоге адрес, который мы будем запрашивать каждый раз на веб-сервере, и который мы указываем с опцией url становится таким: url="http://localhost/dvwa/vulnerabilities/brute/?username=FILE0&password=FILE1&Login=Login"

Также нам нужно указать расположение файлов с именами пользователей и паролями. Обратите внимание, вместо FILE0 и FILE1 используется сокращённая запись 0= и 1=. Файлы расположены в той же директории, что и скрипт patator, поэтому к нашей команде я добавляю 0=namelist.txt 1=password_medium.txt

Далее мы добавляем используемый метод: method=GET

Куки передаются в заголовках, поэтому добавляем наши куки строкой: header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2'

Теперь после опции -x нам нужно указать действие и условие таким образом, чтобы при успешном входе подобранные логин и пароль выводились нам, а неудачные попытки – нет. Неудачной попыткой являются те, когда в присылаемом от сервера ответе присутствует слово incorrect. В качестве действия мы выбираем ignore. Тогда получается -x ignore:fgrep='incorrect'.

Соберём всё вместе, в конечном счёте получается следующая команда:

./patator.py http_fuzz url="http://localhost/dvwa/vulnerabilities/brute/?username=FILE0&password=FILE1&Login=Login" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=namelist.txt 1=password_medium.txt -x ignore:fgrep='incorrect'

Обратите внимание, что если вы попытаетесь использовать эту же команду в Web Security Dojo в Damn Vulnerable Web Application (DVWA), скачаете эти же самые словари, которые я использую, то у вас всё равно ничего не получится! Поскольку вам значение 1n3b0ma83kl75996udoiufuvc2 (куки) нужно поменять на своё.

Перебор затянется на длительное время, логи Apache (чтобы убедиться, что процесс идёт), можно смотреть следующей командой:

tail /var/log/apache2/access.log -n 100

Чтобы посмотреть прогресс в самой программе, нажмите [ENTER]. Для просмотра всех доступных интерактивных команд, нажмите h.

Вот результат выполнения брут-форса:

28:56 patator    INFO - Starting Patator v0.7-beta (https://github.com/lanjelot/patator) at 2016-09-09 03:28 EDT

28:56 patator    INFO -                                                                              

28:56 patator    INFO - code size:clen       time | candidate                          |   num | mesg

28:56 patator    INFO - -----------------------------------------------------------------------------

30:51 patator    INFO - 200  5312:5002      0.030 | admin:password                     | 32964 | HTTP/1.1 200 OK

30:54 patator    INFO - 200  5312:5002      0.041 | admin:password                     | 32965 | HTTP/1.1 200 OK

51:34 patator    INFO - 200  5312:5002      0.046 | admin:password                     | 1400702 | HTTP/1.1 200 OK

51:35 patator    INFO - 200  5312:5002      0.041 | admin:password                     | 1400701 | HTTP/1.1 200 OK

41:13 patator    INFO - Hits/Done/Skip/Fail/Size: 4/2096668/0/0/2096668, Avg: 264 r/s, Time: 2h 12m 17s

С одной стороны, программу минимум мы выполнили и нашли пароль администратора. Но мы не нашли ни одного (из четырёх) паролей пользователя.

Скорость перебора составила 264 протестированных комбинации за секунду.

И ещё обратите внимание, что одну и ту же учётную запись мы взломали четыре раза. Это не ошибка patator – это проблема наших словарей, в которых одни и те же имена пользователя и/или пароли повторялись несколько раз. Для брут-форса веб-приложений это плохо. Кстати, давайте посчитаем,

Всего было протестировано 2096668 комбинации логин:пароль. Это можно проверить и самому. Посчитаем количество имён пользователя:

cat namelist.txt | wc -l

2908

Посчитаем количество паролей:

cat password_medium.txt | wc -l

721

Всего комбинаций: 2908*721=2096668

А теперь давайте удалим дубликаты и снова посчитаем количество комбинаций:

cat namelist.txt | sort | uniq > namelist_new.txt

cat password_medium.txt | sort | uniq > password_medium_new.txt

cat namelist_new.txt | wc -l

2486

cat password_medium_new.txt | wc -l

706

2486*706=1755116

Т.е. если бы мы догадались начать с удаления дубликатов, то количество комбинаций, необходимых для тестирования, сократилось бы примерно на 350 тысяч… Пусть это послужит нам уроком.

Мы не узнали данных ни одного из четырёх пользователей. Нам нужны новые словари для продолжения брут-форса, но давайте введём полученные данные учётной записи admin:password и продолжим исследование веб-приложения. Мы видим фотографию пользователя:

Фотография размещена по адресу http://localhost/dvwa/hackable/users/admin.jpg. А что если мы заглянем в папку http://localhost/dvwa/hackable/users/ ?..

Я почти уверен, что название файлов изображений соответствуют именам пользователей, т.е. это

1337
gordonb
pablo
smithy

Это отличный подарок для нас, поскольку в качестве новых словарей имён пользователя я собрался брать «First names facebook-firstnames.txt.bz2 (16,464,124 bytes)» отсюда. Это большой список и новый брут-форс сильно бы затянулся. Вместо этого я создаю файлик opened_names.txt и вписываю туда всего 4 строчки:

1337

gordonb

pablo

smithy

В качестве паролей я попробую словарик «500 самых плохих паролей»:

wget https://kali.tools/files/passwords/password_dictionaries/500-worst-passwords.txt.bz2

bunzip2 500-worst-passwords.txt.bz2

Теперь моя команда с новыми словарями выглядит так:

./patator.py http_fuzz url="http://localhost/dvwa/vulnerabilities/brute/?username=FILE0&password=FILE1&Login=Login" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=opened_names.txt 1=500-worst-passwords.txt -x ignore:fgrep='incorrect'

Результат:

21:04 patator    INFO - Starting Patator v0.7-beta (https://github.com/lanjelot/patator) at 2016-09-15 04:21 EDT

21:04 patator    INFO -                                                                              

21:04 patator    INFO - code size:clen       time | candidate                          |   num | mesg

21:04 patator    INFO - -----------------------------------------------------------------------------

21:06 patator    INFO - 200  5316:5006      0.027 | gordonb:abc123                     |   518 | HTTP/1.1 200 OK

21:08 patator    INFO - 200  5313:5003      0.031 | pablo :letmein                     |  1011 | HTTP/1.1 200 OK

21:11 patator    INFO - 200  5314:5004      0.011 | smithy:password                    |  1502 | HTTP/1.1 200 OK

21:12 patator    INFO - Hits/Done/Skip/Fail/Size: 3/2000/0/0/2000, Avg: 250 r/s, Time: 0h 0m 7s

Ну наконец-то и на моей улице праздник. Буквально за считанные секунды я взломал пароли для трёх учётных записей из четырёх.

Из файла opened_names.txt я убираю все строки, кроме 1337 (чтобы уже взломанные пользователи не отнимали время). Попробую с таким сочетанием:

./patator.py http_fuzz url="http://localhost/dvwa/vulnerabilities/brute/?username=FILE0&password=FILE1&Login=Login" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=opened_names.txt 1=password_medium_new.txt -x ignore:fgrep='incorrect'

Без результата.

Возьмём молоток побольше - Rockyou:

wget https://kali.tools/files/passwords/leaked_passwords/rockyou.txt.bz2

bunzip2 rockyou.txt.bz2

./patator.py http_fuzz url="http://localhost/dvwa/vulnerabilities/brute/?username=FILE0&password=FILE1&Login=Login" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=opened_names.txt 1=rockyou.txt -x ignore:fgrep='incorrect'

Результат получен на удивление быстро:

Недостающая пара: 1337:charley

Ещё из скриншота видны ложные срабатывания, когда в пароле присутствуют специальные символы. Это может означать наличие другой уязвимости, например, SQL-инъекции.

Использование Medusa для брут-форса веб-форм, передающих данные методом GET

У программы Medusa также очень большая страница справки, которая содержит информацию по всем модулям программы. Выпишем информацию по модулю web-form, поскольку именно он применяется для брут-форса форм входа веб-сайтов.

-h [ТЕКСТ]   : Имя хоста или IP адрес цели

-H [ФАЙЛ]    : Файл, содержащий целевые имена хостов или IP адреса

-u [ТЕКСТ]   : Имя пользователя для тестирования

-U [ФАЙЛ]    : Файл, содержащий имена пользователей для тестирования

-p [ТЕКСТ]   : Пароль для тестирования

-P [ФАЙЛ]    : Файл, содержащий пароль для тестирования

-C [ФАЙЛ]    : Файл, содержащий комбинированные записи. Подробности смотрите ниже.

-O [ФАЙЛ]    : Файл, в который добавляются записи журнала (логи)

-e [n/s/ns]  : Дополнительные проверки паролей ([n] Без пароля, [s] Пароль = Имя Пользователя)

-M [ТЕКСТ]   : Имя модуля для выполнения (без расширения .mod)

-m [ТЕКСТ]   : Параметры для передачи модулю. Эту опцию можно использовать несколько раз

              каждый раз с разными параметрами и они будут отправлены модулю (пример,

               -m Param1 -m Param2 и т.д..)

-d           : Вывести все известные модули

-n [ЧИСЛО]     : Использовать для TCP портов не по умолчанию

-s           : Включить SSL

-g [ЧИСЛО]   : Сдаться после попытки подключиться ЧИСЛО секунд (о умолчанию 3)

-r [ЧИСЛО]   : Засыпать на ЧИСЛО секунд между повтором попыток (по умолчанию 3)

-R [ЧИСЛО]   : Пытаться ЧИСЛО раз перед прекращением. Общее число попыток будет ЧИСЛО + 1.

-c [ЧИСЛО]   : Время ожидания в микросекундах верификации доступности сокета (по умолчанию 500 микросекунд).

-t [ЧИСЛО]   : Общее число логинов для одновременного тестирования

-T [ЧИСЛО]   : Общее число хостов для одновременного тестирования

-L           : Распараллеливание входов используя одно имя пользователя на поток. По умолчанию

               обрабатывать всё имя пользователя перед переходом к следующему.

-f           : Остановить сканирования хоста после первого найденного действительного имени пользователя/пароля.

-F           : Остановить аудит после первого найденного действительного имени пользователя/пароля на любом хосте.

-b           : Не выводить начальный баннер

-q           : Показать информацию об использовании модуля

-v [ЧИСЛО]   : Уровень вербальности [0 - 6 (больше)]

-w [ЧИСЛО]   : Уровень отладки ошибок [0 - 10 (больше)]

-V           : Показать версию

-Z [ТЕКСТ]   : Возобновить сканирование, основанное на карте возобновления предыдущего сканирования

web-form

Доступные опции модуля:

USER-AGENT:? Значение пользовательского агента (User-agent). По умолчанию: "I'm not Mozilla, I'm Ming Mong".
FORM:? Целевая форма для запроса. По умолчанию: "/"
DENY-SIGNAL:? Сообщение неудачной аутентификации. Попытка помечается как успешная, если этот текст отсутствует в ответе сервера. По умолчанию: "Login incorrect"
CUSTOM-HEADER:? Пользовательский HTTP заголовок.

Можно указать больше заголовков, используя эту опцию несколько раз.

FORM-DATA:?

Методы и поля для отправки веб-службе. Валидными методами являются GET и POST. Действительные данные, которые отправляет форма, также должны быть определены здесь. Особенно поля имя_пользователя и пароль. Поле имя_пользователя должно быть первым, за ним следует поле пароля. По умолчанию: "post?username=&password="

Пример использования: "-M web-form -m USER-AGENT:"g3rg3 gerg" -m FORM:"webmail/index.php" -m DENY-SIGNAL:"deny!" -m FORM-DATA:"post?user=&pass=&submit=True" -m CUSTOM-HEADER:"Cookie: name=value"

Если внимательно всмотреться в опции Medusa, то станет понятно, что программа patator является более гибкой и способной выполнять брут-форс веб-форм практически при любом поведении веб-приложения. Про Medusa этого сказать нельзя, но для нашей ситуации её функционала достаточно. Давайте составит команду для запуска брут-форса под наши условия.

Начинается команда с вызова бинарного файла Medusa – /usr/local/bin/medusa.
Далее после опции -h нам нужно указать адрес хоста, который будет брут-форситься: -h localhost
Теперь опциями -U и -P укажем файлы с именами пользователей и паролями: -U opened_names.txt -P 500-worst-passwords.txt
После опции -M нужно указать используемый модуль: -M web-form

Все остальные величины являются опциями модуля web-form и начинаются с -m.

После -m FORM указываем адрес формы, которой отправляются логин и пароль: -m FORM:"/dvwa/vulnerabilities/brute/"
С -m DENY-SIGNAL указываем фразу или слово, которые говорят о неудачной аутентификации: -m DENY-SIGNAL:"incorrect"
Метод отправки, а также сами отправляемые данные указываются после -m FORM-DATA. Здесь нужно быть особенно внимательным. В самом начале указывается метод передачи данных (post или get). Первым обязательно должно идти поле с именем пользователя, а вторым – поле с паролем. Заполнители не указываются. Для нашего примера верной является такая строка: -m FORM-DATA:"get?username=&password=&Login=Login"
С -m CUSTOM-HEADER указываются заголовки. Можно использовать много раз для передачи нескольких заголовков. В нашем случае обязательным являются только куки: -m CUSTOM-HEADER:"Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2"

Итак, собираем всё вместе в одну команду:

/usr/local/bin/medusa -h localhost -U opened_names.txt -P 500-worst-passwords.txt -M web-form -m FORM:"/dvwa/vulnerabilities/brute/" -m DENY-SIGNAL:"incorrect" -m FORM-DATA:"get?username=&password=&Login=Login" -m CUSTOM-HEADER:"Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2"

И всё в этой команде хорошо и правильно, кроме одного, Medusa вылетает с ошибкой не успев перебрать ни одного пароля:

Segmentation fault (core dumped)

Автор уже извещён о данной ошибке: https://github.com/jmk-foofus/medusa/issues/14. Будем надеяться, что он её поправит.

Использование THC-Hydra для брут-форса веб-форм, передающих данные методом GET

Как обычно, начнём знакомство с Hydra со страницы с опциями и выпишем те из них, которые нужны для брут-форса веб-форм.

Глобальные опции:

-R        восстановить предыдущую прерванную/оборванную сессию

-S        выполнить SSL соединение

-s ПОРТ   если служба не на порту по умолчанию, то можно задать порт здесь

-l ЛОГИН или -L ФАЙЛ с ЛОГИНАМИ (именами), или загрузить несколько логинов из ФАЙЛА

-p ПАРОЛЬ  или -P ФАЙЛ с паролями для перебора, или загрузить несколько паролей из ФАЙЛА

-x МИНИМУМ:МАКСИМУМ:НАБОР_СИМВОЛОВ  генерация паролей для брутфорса, наберите "-x -h" для помощи

-e nsr    "n" — пробовать с пустым паролем, "s" — логин в качестве пароля и/или "r" — реверс учётных данных

-u        зацикливаться на пользователя, а не на паролях (эффективно! подразумевается с использованием опции -x)

-C ФАЙЛ   формат где "логин:пароль" разделены двоеточиями, вместо опции -L/-P 

-M ФАЙЛ   список серверов для атак, одна запись на строку, после двоеточия ':' можно задать порт

-o ФАЙЛ   записывать найденные пары логин/пароль в ФАЙЛ вместо стандартного вывода

-f / -F   выйти, когда пара логин/пароль подобрана (-M: -f для хоста, -F глобально)

-t ЗАДАЧИ  количество запущенных параллельно ЗАДАЧ (на хост, по умолчанию: 16)

-w / -W ВРЕМЯ  время ожидания ответов (32 секунды) / между соединениями на поток

-4 / -6   предпочитать IPv4 (по умолчанию) или IPv6 адреса

-v / -V / -d  вербальный режим / показывать логин+пароль для каждой попытки / режим отладки 

-O        использовать старые SSL v2 и v3

-q        не печатать сообщения об ошибках соединения

-U        подробные сведения об использовании модуля

server    цель: DNS, IP или 192.168.0.0/24 (эта ИЛИ опция -M)

service   служба для взлома (смотрите список поддерживаемых протоколов)

OPT       некоторые модули служб поддерживают дополнительный ввод (-U для справки по модулю)

Опции модулей http-get-form, https-get-form, http-post-form, https-post-form

Модули требует страницу и параметры веб-формы.

По умолчанию этот модуль настроен следовать максимум пяти редиректам подряд. Он каждый раз собирает новое куки с того же URL без переменных. Параметр принимает три разделённых ":" значения, плюс опциональные значения.

(Примечание: если вам нужно двоеточие в строке опций в качестве значения, экранируйте его с "\:", но не экранируйте "\" с "\\".)

Синтаксис:

:<параметры формы>:<строка условия>[:<опционально>[:<опционально>]
Первое — это страница на сервере (URL) на которую отправляются данные методом GET или POST.
Второе — это переменные POST/GET получаемые либо из браузера, либо прокси и т. д. Имена пользователей и пароли будут подставлены вместо заполнителей "^USER^" и "^PASS^" (ПАРАМЕТРЫ ФОРМЫ).
Третье — это строка, которая проверяет неверный вход (по умолчанию). Перед условием неверного входа должна стоять "F=", перед условиям успешного входа должна стоять "S=". Это то место, где больше всего людей ошибаются. Вы должны проверить веб-приложение, на что похожа строка, которую он выдаёт при неуспешном входе и указать её в этом параметре!

Следующие параметры опциональны:

C=/page/uri

задаёт другую страницу с которой собрать начальные кукиз.

(h|H)=My-Hdr\: foo

для отправки с каждым запросом заданного пользователем HTTP заголовка

^USER^ и ^PASS^ также могут быть размещены в этих заголовках!

Примечание: 'h' добавит определённый пользователем заголовок в конец, независимо от того, отправила ли уже Hydra заголовок или нет.

'H' заменит значение этого заголовка, если оно существует, тем, которое указал пользователь или добавит заголовок в конец.

Помните, если вы собираетесь разместить двоеточие (:) в ваших заголовках, вам следует их экранировать обратным слэшем (\). Все двоеточия, которые не являются разделителями опций, должны быть экранированы .

Вы можете задать заголовок без экранирования двоеточий, но в этом случае вы не сможете разместить двоеточия в само значения заголовка, поскольку они будут интерпретироваться в hydra как разделители опций.

Примеры:

"/login.php:user=^USER^&pass=^PASS^:incorrect"

"/login.php:user=^USER^&pass=^PASS^&colon=colon\:escape:S=authlog=.*success"

"/login.php:user=^USER^&pass=^PASS^&mid=123:authlog=.*failed"

"/:user=^USER&pass=^PASS^:failed:H=Authorization\: Basic dT1w:H=Cookie\: sessid=aaaa:h=X-User\: ^USER^"

"/exchweb/bin/auth/owaauth.dll:destination=http%3A%2F%2F%2Fexchange&flags=0&username=%5C^USER^&password=^PASS^&SubmitCreds=x&trusted=0:reason=:C=/exchweb"

Собираем нашу команду:

Как всегда, она начинается с бинарного файла THC-Hydra: hydra
Опциями -L и -P задаём файлы со списками имён пользователя и паролей: -L opened_names.txt -P 500-worst-passwords.txt
Установим количество потоков: -t 10
Из четырёх схожих модулей выбираем http-get-form и через символы :// указываем адрес localhost. Здесь же через слеш нам нужно указать адрес страницы формы (/dvwa/vulnerabilities/brute/), передаваемые форме данные, где необходимо указать "^USER^" и "^PASS^" в тех местах, куда будут подставлены имена и пароли (username=^USER^&password=^PASS^&Login=Login) и третье это строка, которая проверяет верный или неверный ввод (incorrect). Все эти данные разделены двоеточиями. Получается:

"http-get-form://localhost/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:incorrect"

Не забываем, что нам обязательно нужно передать куки, для этого используем опцию h и через двоеточие ещё дописываем (если внутри заголовка присутствует своё двоеточие, то обязательно экранируем его): h=Cookie\: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2

В конечном счёте у нас получилось:

hydra -L opened_names.txt -P 500-worst-passwords.txt -t 10 "http-get-form://localhost/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:incorrect:h=Cookie\: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2"

И опять, хорошая команда, правильно составлено, но есть одно «но»:

Много ложных срабатываний и ни одного угаданного пароля… Я пробовал менять команду, в качестве условия устанавливал успешный вход с соответствующей строкой. Но результат всегда один: ложные срабатывания и ни одного угаданного пароля… Всё-таки слова автора patator:

Неудовлетворённость существующими программами была вызвана следующими их недостатками:

они не работают или работают ненадёжно (несколько раз в прошлом они выдавали ложноотрицательные результаты)

они недостаточно гибкие (как сделать перебор по всем спискам слов, подставить любой параметр модуля)

у них отсутствуют полезные функции (отображение прогресса или пауза во время выполнения)

Это не пустая болтовня о неудовлетворительном качестве альтернативных инструментов. Мы только что в этом убедились сами.

Брут-форс веб-форм, использующих метод POST

Если вы попробовали брут-форс веб-форм, когда они передают данные методом GET, и у вас всё получилось, то с методом POST также не должно возникнуть особых проблем. Теперь адрес страницы у нас будет статичным (не будет меняться), а для указания передаваемых данных мы будем использовать специальную опцию. Пожалуй, это и есть самое большое различие.

Использование patator для брут-форса веб-форм, передающих данные методом POST

Теперь давайте перейдём к брутфорсу веб-входа, когда данные передаются с использованием POST.

Я буду практиковаться в OWASP Mutillidae II, установленной в Web Security Dojo.

Там есть страничка входа http://localhost/mutillidae/index.php?page=login.php, она отправляет данные методом POST. Начнём, естественно, с анализа, введём произвольные данные в форму и нажмём отправить:

Как видим, вход не произошёл, из важного:

мы остались на странице http://localhost/mutillidae/index.php?page=login.php, т.е. скорее всего, данные отправляются этому файлу, причём скорее всего используется метод POST
при ошибке входа показывается надпись «Password incorrect».

Переходим теперь в Burp Suite:

Здесь важными являются строки:

POST /mutillidae/index.php?page=login.php
Referer: http://localhost/mutillidae/index.php?page=login.php
Cookie: showhints=1; PHPSESSID=1n3b0ma83kl75996udoiufuvc2
username=admin&password=password&login-php-submit-button=Login

Они говорят нам о том, что данные передаются методом POST странице /mutillidae/index.php?page=login.php. Также передаются кукиз, которые содержат «PHPSESSID=1n3b0ma83kl75996udoiufuvc2». Сами передаваемые данные имеют вид: «username=admin&password=password&login-php-submit-button=Login».

Анализирует ответ сервера:

Редиректов и записи новых куки нет.

Начинаем строить нашу команду.

Она начинается с ./patator.py http_fuzz (файл программы и указание используемого модуля).
Далее с опцией url мы указываем адрес страницы, на которую отправляются данные: url="localhost/mutillidae/index.php?page=login.php"
Опцией method мы задаём метод отправки данных: method=POST
С patator мы ещё не применяли опцию body, теперь пришло её время. В ней мы передаём те данные, которые оправляются серверу. Не забываем добавить заполнители FILE0 и FILE1: body='username=FILE0&password=FILE1&login-php-submit-button=Login'
С опциями 0= и 1= мы передаём в программу словари имён пользователя и паролей: 0=namelist_new.txt 1=500-worst-passwords.txt
Поскольку какие-то кукиз у нас уже есть, они были записаны автоматически, скорее всего, при первом открытии сайта. Непонятно, с какой периодичностью они будут изменяться, но ясно, что это будет происходить автоматически, как и в первый раз, поэтому мы указываем: accept_cookie=1. Эта опция означает принять кукиз от веб-приложения и отправить их при следующей проверке логина и пароля.
И опять мы выбираем игнорировать (не показывать нам) все попытки входа, если в ответе содержится слово incorrect: -x ignore:fgrep='incorrect'
После опции -t можно указать количество потоков: -t 50

Всё вместе:

./patator.py http_fuzz url="localhost/mutillidae/index.php?page=login.php" method=POST body='username=FILE0&password=FILE1&login-php-submit-button=Login' 0=namelist_new.txt 1=500-worst-passwords.txt accept_cookie=1 -x ignore:fgrep='incorrect' -t 50

Как видим, результаты есть:

При моих параметрах, иногда возникала ошибка 500 Internal Server Error, которая в данной ситуации означает лишь то, что я заDoS’ил сервер.

Брут-форс входа в phpMyAdmin, WordPress, Joomla!, Drupal

[ДОПИСЫВАЕТСЯ - БУДЕТ ДОБАВЛЕНО ПОЗЖЕ]

Заключение

Итак, из тройки patator, Hydra и Medusa полностью адекватно работающей оказалась только одна программа – patator.

Более того, гибкость patator позволяет проводить брут-форс в обстоятельствах, которые были бы не по зубам Hydra и Medusa (если бы они работали).

Если плачевные результаты Hydra и Medusa связаны с моими неправильными действиями, то просьба написать в комментариях, в чём именно мои ошибки.

[РЕШЕНО] Ошибка № ...

четверг