Приветствую, Codeby.net!
Пришло время, опубликовать следующую часть цикла статей посвящённых Burp Suite.
Предыдущие материалы по этой теме:
В одной из предыдущих статей, я описывал метод атаки перебором, с помощью Intruder и типа атаки Sniper. Но в этой статье, я бы хотел подробнее рассказать о Sniper и применить его ещё раз, для атаки на действующий сайт.
После установки WordPress на сервер, в корневой папке сайта вы можете обнаружить файл xmlrpc.php. Именно с ним связана последующая атака на сайт.
Проверим, обратившись к сайту по адресу:
XML-RPC - принимает только POST запросы.
Проверим, какие методы для общения с ним, нам доступны и получим их список, отправив на сайт немного модифицированный POST.
Выберем из доступных методов обращения к xmlrpc, тот, который может принять в качестве значений логин/пароль и ответить нам валидная ли связка использовалась.
Такой метод - wp.getUsersBlogs – на нём и будет строиться наша Brute Force атака далее.
Попробуем послать запрос на сервер, подставив в метод некорректный логин с паролем.
Сервер, в свою очередь, отвечает нам, что пароль неверный, ответ с кодом 200 ОК.
Каждый раз вручную менять значения и отправлять запрос на сервер – это непродуктивно, поэтому подключаем wpscan, чтобы перечислить имена пользователей WordPress.
Теперь, когда у нас есть валидное имя пользователя, мы можем использовать Intruder для атаки методом перебора паролей.
Модифицируем запрос на POST, добавляем в него нужные для работы методы и выбираем позицию для атаки:
Для выбранной позиции загружаем словарь в Burp Suite и нажимаем Start Attack.
Спустя, примерно 2-3 сек, программа закончит обрабатывать список из 500 паролей.
Результатом будет список из ответов, примерно такой:
Все они имеют статус 200 и длину ответа 631, результаты на скриншоте выше – это реакция сервера на неправильные пароли, в теле каждого из них будет присутствовать такая информация:
Но в словаре был и правильный пароль, чтобы отыскать его, необходимо отфильтровать результаты по длине ответов:
Как видно, один из результатов имеет достаточно большую длину (826), чтобы выделяться из общего списка, заглянем внутрь ответа:
Получив такой ответ от сервера, мы можем быть уверены, что он подошёл для логина в WordPress и на этом атаку можно закончить.
Заглянем в логи аутентификации, чтобы посмотреть, насколько такая атака заметна для администратора:
Система зафиксировала 23 попытки входа из 500, и ни одной успешной не показала.
Если сравнить работу Intruder с такой же атакой, только через WPScan, то различие лишь в том, что из словаря на 20 паролей после проведения атаки в логах отобразилось 15 попыток логина, из 500 намного больше + были проблемы с MySQL, с какой-то момент она отвалилась, даже DoS получился небольшой.
На этом я заканчиваю эту статью, в следующих частях сфокусируемся на различных атаках на уязвимые web-приложения с помощью Burp Suite.
Спасибо за внимание.
Пришло время, опубликовать следующую часть цикла статей посвящённых Burp Suite.
Предыдущие материалы по этой теме:
- [0] Burp Suite. Тестирование web-приложений на проникновение
- [1] Burp Suite. Знакомство с основным инструментарием
- [2] Burp Suite. Атаки с помощью Intruder
- [3] Burp Suite. Установление доверия по HTTPS
- [4] Burp Suite. Настройка параметров проекта
В одной из предыдущих статей, я описывал метод атаки перебором, с помощью Intruder и типа атаки Sniper. Но в этой статье, я бы хотел подробнее рассказать о Sniper и применить его ещё раз, для атаки на действующий сайт.
- Sniper - использует один набор полезных нагрузок. Он нацеливается на каждую позицию полезной нагрузки по очереди и помещает каждую нагрузку в эту позицию по очереди. Позиции, не предназначенные для данного запроса, не затрагиваются - маркеры позиций удаляются, и любой вложенный текст, который появляется между ними в шаблоне, остается неизменным. Этот тип атаки полезен для фаззинга нескольких параметров запроса по отдельности для общих уязвимостей. Общее количество запросов, сгенерированных при атаке, является произведением количества позиций и количества полезных нагрузок в Payload Sets.
После установки WordPress на сервер, в корневой папке сайта вы можете обнаружить файл xmlrpc.php. Именно с ним связана последующая атака на сайт.
- XML-RPC— стандарт/протокол вызова удалённых процедур, использующий XML для кодирования своих сообщений и HTTP в качестве транспортного механизма[1]. Является прародителем SOAP, отличается исключительной простотой в применении. XML-RPC, как и любой другой интерфейс Remote Procedure Call (RPC), определяет набор стандартных типов данных и команд, которые программист может использовать для доступа к функциональности другой программы, находящейся на другом компьютере в сети.
- xmlrpc.php - в WordPress используется для удаленного доступа к вашему сайту, через сторонние приложения. Данный инструмент появился, когда WordPress только зарождался, и скорость интернета не позволяла быстро создавать и публиковать записи на сайт. Существовал офлайн-клиент, в котором администратор создавал и редактировал записи, а затем через xmlrpc.php записи публиковались на сайт.
Проверим, обратившись к сайту по адресу:
Код:
yoursite.com/xmlrpc.comXML-RPC - принимает только POST запросы.
Проверим, какие методы для общения с ним, нам доступны и получим их список, отправив на сайт немного модифицированный POST.
Код:
POST /xmlrpc.php HTTP/1.1
Host: xxx.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 90
<methodCall> <methodName>system.listMethods</methodName> <params></params> </methodCall>Выберем из доступных методов обращения к xmlrpc, тот, который может принять в качестве значений логин/пароль и ответить нам валидная ли связка использовалась.
Такой метод - wp.getUsersBlogs – на нём и будет строиться наша Brute Force атака далее.
Попробуем послать запрос на сервер, подставив в метод некорректный логин с паролем.
Код:
<methodCall> <methodName>wp.getUsersBlogs</methodName> <params> <param><value>admin</value></param> <param><value>pass</value></param> </params> </methodCall>Сервер, в свою очередь, отвечает нам, что пароль неверный, ответ с кодом 200 ОК.
Каждый раз вручную менять значения и отправлять запрос на сервер – это непродуктивно, поэтому подключаем wpscan, чтобы перечислить имена пользователей WordPress.
Теперь, когда у нас есть валидное имя пользователя, мы можем использовать Intruder для атаки методом перебора паролей.
Модифицируем запрос на POST, добавляем в него нужные для работы методы и выбираем позицию для атаки:
Для выбранной позиции загружаем словарь в Burp Suite и нажимаем Start Attack.
Спустя, примерно 2-3 сек, программа закончит обрабатывать список из 500 паролей.
Результатом будет список из ответов, примерно такой:
Все они имеют статус 200 и длину ответа 631, результаты на скриншоте выше – это реакция сервера на неправильные пароли, в теле каждого из них будет присутствовать такая информация:
Но в словаре был и правильный пароль, чтобы отыскать его, необходимо отфильтровать результаты по длине ответов:
Как видно, один из результатов имеет достаточно большую длину (826), чтобы выделяться из общего списка, заглянем внутрь ответа:
Получив такой ответ от сервера, мы можем быть уверены, что он подошёл для логина в WordPress и на этом атаку можно закончить.
Заглянем в логи аутентификации, чтобы посмотреть, насколько такая атака заметна для администратора:
Система зафиксировала 23 попытки входа из 500, и ни одной успешной не показала.
Если сравнить работу Intruder с такой же атакой, только через WPScan, то различие лишь в том, что из словаря на 20 паролей после проведения атаки в логах отобразилось 15 попыток логина, из 500 намного больше + были проблемы с MySQL, с какой-то момент она отвалилась, даже DoS получился небольшой.
На этом я заканчиваю эту статью, в следующих частях сфокусируемся на различных атаках на уязвимые web-приложения с помощью Burp Suite.
Спасибо за внимание.
Последнее редактирование:
