Перевод: TryHackMe: Burp Suite: Repeater - Прохождение

Перевод: TryHackMe: Burp Suite: Repeater - Прохождение

@Ent_TranslateIB

Привет! Я пишу эти руководства, чтобы поддерживать мотивацию к изучению кибербезопасности и гарантировать, что я запомнил знания, полученные в учебных комнатах THM.

Присоединяйтесь ко мне в изучении кибербезопасности. Я постараюсь объяснить концепции по ходу дела, чтобы отличаться от других прохождений.

URL комнаты: https://tryhackme.com/room/burpsuiterepeater

Предварительные условия: https://tryhackme.com/room/burpsuitebasics

Задание 1 (Конспект)

В этой комнате рассматривается базовое использование Burp Suite: Repeater.

Больше здесь делать нечего, так что переходим к части 2.

Вопросы

Разверните машину (и атакующую машину AttackBox, если вы не используете свою собственную атакующую виртуальную машину), и давайте начнем!

Ответ: Ответ не требуется

Часть 2 (Что такое Repeater?)

Burp Suite Repeater позволяет нам создавать и/или передавать перехваченные запросы цели по своему усмотрению. Говоря простым языком, это означает, что мы можем взять запрос, перехваченный в Proxy, отредактировать его и отправить тот же самый запрос столько раз, сколько захотим.

Эта возможность редактировать и повторно отправлять один и тот же запрос несколько раз делает Repeater идеальным для любого вида ручной работы с конечной точкой, предоставляя нам красивый графический интерфейс пользователя (GUI) для написания полезной нагрузки запроса и множество представлений (включая механизм рендеринга для графического представления) ответа, чтобы мы могли видеть результаты нашей работы в действии.

Вопросы

Ознакомьтесь с интерфейсом Repeater.

Ответ: Ответ не требуется

Часть 3 (Базовое использование)

Хотя мы можем создавать запросы вручную, гораздо более распространенным является простой захват запроса в прокси, а затем отправка его в Repeater для редактирования/передачи.

Захватив запрос в прокси, мы можем отправить его в Repeater, щелкнув правой кнопкой мыши на запросе и выбрав "Send to Repeater" или нажав Ctrl + R. Переключившись обратно в Repeater, мы видим, что наш запрос теперь доступен. Элементы target и Inspector теперь также отображают информацию; однако у нас еще нет ответа. Когда мы нажмем кнопку "Send", раздел Response быстро заполнится:

Если мы хотим изменить что-либо в запросе, мы можем просто ввести текст в окне запроса и снова нажать кнопку "Send"; это обновит ответ справа. Например, если изменить заголовок "Connection" на open, а не close, то в ответ появится заголовок "Connection" со значением keep-alive. Затем мы также можем использовать кнопки истории справа от кнопки "Send" для перехода вперед и назад в истории изменений.

Вопросы

Захватите запрос на <ip> в прокси и отправьте его в Repeater. Потренируйтесь изменять и повторно отправлять запрос множество раз.

Ответ: Ответ не требуется

Часть 4 (Представления)

Repeater предлагает нам различные способы представления ответов на наши запросы - от шестнадцатеричного вывода до полностью отрисованной версии страницы. Мы можем увидеть доступные варианты, посмотрев на поле ответа:

  • Pretty: Это вариант по умолчанию. Он берет необработанный ответ и пытается немного украсить его, делая его более удобным для чтения.
  • Raw: чистый, не украшенный ответ сервера.
  • Hex: Это представление берет необработанный ответ и дает нам его побайтовое представление - особенно полезно, если ответ представляет собой двоичный файл.
  • Render: Представление рендеринга отображает страницу так, как она будет выглядеть в вашем браузере. Хотя это и не очень полезно, учитывая, что при использовании Repeater нас обычно интересует исходный код, тем не менее, это очень интересный трюк.

В большинстве случаев опция "Pretty" является вполне адекватной, однако все же стоит знать, как использовать остальные три опции.

Вопросы

Поэкспериментируйте с доступными вариантами представления.

Ответ: Ответ не требуется

Какой вариант представления отображает ответ в том же формате, что и браузер?

Ответ: рендеринг (Render)

Часть 5 (Inspector)

Во многих отношениях Inspector полностью дополняет поля запроса и ответа в окне Repeater. Если вы понимаете, как читать и редактировать HTTP-запросы, то вы можете заметить, что вообще редко используете Inspector.

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

Другие разделы, доступные для просмотра и/или редактирования, следующие:

  • Query Parameters, которые относятся к данным, отправляемым на сервер в URL. Например, в GET-запросе к https://admin.tryhackme.com/?redirect=false есть параметр запроса "redirect" со значением "false".
  • Body Parameters, которые делают то же самое, что и параметры запроса, но для POST-запросов. Все, что мы отправляем в качестве данных в POST-запросе, отображается в этом разделе, что позволяет нам изменить параметры перед повторной отправкой.
  • Request Cookies содержат, как и следовало ожидать, изменяемый список файлов cookie, которые отправляются с каждым запросом.
  • Request Headers позволяют нам просматривать, получать доступ и изменять (включая прямое добавление или удаление) любые заголовки, отправляемые с нашими запросами. Их редактирование может быть очень полезным при попытке узнать, как веб-сервер будет реагировать на неожиданные заголовки.
  • Response Headers показывают нам заголовки, которые сервер отправил в ответ на наш запрос. Их нельзя редактировать (поскольку мы не можем контролировать заголовки, которые сервер возвращает нам!) Обратите внимание, что этот раздел отображается только после того, как мы отправили запрос и получили ответ.

Вопросы

Освойтесь с Inspector и попрактикуйтесь в добавлении/удалении элементов из различных разделов запроса.

Ответ: Ответ не требуется

Часть 6 (пример)

Repeater лучше всего подходит для задач, в которых нам нужно отправить один и тот же запрос много раз, обычно с небольшими изменениями между запросами. Например, мы можем захотеть вручную проверить уязвимость SQL Injection (что мы сделаем в одном из следующих заданий), попытаться обойти фильтр брандмауэра веб-приложения или просто добавить или изменить параметры в форме отправки.

А пока давайте начнем с очень простого примера: использование Repeater для изменения заголовков запроса, который мы отправляем цели.

Вопросы

Захватите запрос на http://10.10.8.164/ в прокси и отправьте его в Repeater.

Щелкните правой кнопкой мыши на запросе и отправьте его в Repeater. После этого перейдите на вкладку Repeater.

Ответ: Ответ не требуется

Отправив запрос один раз с Repeater, вы должны увидеть исходный HTML-код запрашиваемой страницы на вкладке ответа. Попробуйте просмотреть его в одном из других вариантов просмотра (например, Rendered).

Ответ: Ответ не требуется

Используя Inspector (или вручную, если хотите), добавьте заголовок FlagAuthorised и установите для него значение True. Отправьте запрос. Какой флаг вы получите?

Добавьте FlagAuthorised в заголовок запроса следующим образом:

Нажмите "Send" и получите в ответ флаг:

Ответ: THM{Yzg2MWI2ZDhlYzdlNGFiZTUzZTIzMzVi}

Часть 7 (Задача)

В предыдущем задании мы использовали Repeater для добавления заголовка и отправки запроса; это должно послужить примером использования Repeater - теперь пришло время для очень простой задачи!

Отключив прокси, перейдите на сайт http://10.10.185.96/products/ и попробуйте щелкнуть по нескольким ссылкам "See More".

Заметили ли вы, что при нажатии на ссылку "See More" вас перенаправляет на конечную точку с числовым значением (например, /products/3)?

Эта конечная точка должна быть проверена, чтобы убедиться, что число, на которое вы пытаетесь перейти, существует и является действительным целым числом; однако, что произойдет, если она не будет проверена должным образом?

Вопросы

Захватите запрос к одной из конечных точек числовых продуктов в прокси, затем перешлите его в Repeater.

Посетите одну из конечных точек продукта:

Захватите запрос в прокси и перешлите его на repeater, щелкнув правой кнопкой мыши запрос в меню прокси и выбрав "Send to Repeater":

Ответ: Ответ не требуется

Попробуйте заставить сервер выдать ошибку с кодом "500 Internal Server Error", изменив число в конце запроса на крайние значения. Какой флаг вы получаете, когда вызываете ошибку 500 в конечной точке?

Ответ: THM{N2MzMzFhMTA1MmZiYjA2YWQ4M2ZmMzhl}

Часть 8 (SQLi с Repeater)

В этом задании содержится дополнительная задача, что означает, что это немного более сложное, реальное применение для Burp Repeater. Если вы чувствуете себя комфортно, выполняя ручную SQL Injection самостоятельно, вы можете пропустить последний вопрос и попробовать выполнить это задание вслепую; в противном случае ниже будет дано руководство.

Существует уязвимость Union SQL Injection в параметре ID конечной точки /about/ID. Найдите эту уязвимость и выполните атаку, чтобы получить записи о генеральном директоре, хранящиеся в базе данных.

Вопросы

Мы знаем, что существует уязвимость, и знаем, где она находится. Теперь нам просто нужно ее использовать! Давайте начнем с перехвата запроса к http://MACHINE_IP/about/2 в Burp Proxy. Захватив запрос, отправьте его в Repeater с помощью Ctrl + R или щелкнув правой кнопкой мыши и выбрав "Send to Repeater".

Ответ: Ответ не требуется

Теперь, когда мы подготовили запрос, давайте подтвердим, что уязвимость существует. Добавление одного апострофа (') обычно достаточно, чтобы сервер выдал ошибку при наличии простого SQLi, поэтому, используя Inspector или отредактировав путь запроса вручную, добавьте апостроф после "2" в конце пути и отправьте запрос:

Вы должны увидеть, что сервер отвечает "500 Internal Server Error", указывая на то, что мы успешно выполнили запрос:

Ответ: Ответ не требуется

Если мы просмотрим тело ответа сервера, то увидим кое-что очень интересное примерно в строке 40. Сервер сообщает нам, какой запрос мы пытались выполнить:

Это чрезвычайно полезное сообщение об ошибке, которое сервер не должен посылать нам, но тот факт, что оно у нас есть, значительно упрощает нашу работу.

Сообщение сообщает нам пару вещей, которые будут неоценимы при эксплуатации этой уязвимости:

Таблица базы данных, из которой мы делаем выборку, называется people.

Запрос выбирает пять столбцов из таблицы: FirstName, LastName, pfpLink, role и bio. Мы можем предположить, где они расположены на странице, что будет полезно при выборе места для размещения наших ответов.

Ответ: Ответ не требуется

Хотя нам удалось избавиться от необходимости перечисления, нам все равно нужно найти имя целевого столбца.

Поскольку мы знаем имя таблицы и количество строк, мы можем использовать запрос объединения, чтобы выбрать имена столбцов для таблицы people из таблицы columns в базе данных information_schema default.

Простой запрос для этого выглядит следующим образом:

/about/0 UNION ALL SELECT имя_столбца,null,null,null,null,null FROM information_schema.columns WHERE имя_столбца="people".

Это создает запрос объединения и выбирает нашу цель, а затем четыре нулевых столбца (чтобы избежать ошибки запроса). Обратите внимание, что мы также изменили ID, который мы выбираем, с 2 на 0. Установив ID на недопустимое число, мы гарантируем, что мы ничего не получим с оригинальным (легитимным) запросом; это означает, что первая строка, возвращенная из базы данных, будет нашим желаемым ответом от внедренного запроса.

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

Ответ: Ответ не требуется

Мы успешно извлекли имя первого столбца из базы данных, но теперь у нас возникла проблема. На странице отображается только первый совпадающий элемент - нам нужно увидеть все совпадающие элементы.

К счастью, мы можем использовать наш SQLi для группировки результатов. Мы по-прежнему можем получить только один результат за раз, но, используя функцию group_concat(), мы можем объединить все имена столбцов в один результат:

/about/0 UNION ALL SELECT group_concat(column_name),null,null,null,null FROM information_schema.columns WHERE table_name="people"

Ответ: Ответ не требуется

Мы успешно определили восемь столбцов в этой таблице: id, FirstName, LastName, pfpLink, role, shortRole, bio и notes.

Учитывая нашу задачу, можно с уверенностью сказать, что наш целевой столбец - это notes.

Наконец, мы готовы взять флаг из этой базы данных - у нас есть вся необходимая информация:

  • Имя таблицы: people.
  • Имя целевого столбца: notes.
  • ID генерального директора - 1; его можно найти, просто кликнув на профиль Джеймсона Вулфа на странице /about/ и проверив ID в URL.

Давайте составим запрос для извлечения этого флага:

0 UNION ALL SELECT notes,null,null,null,null FROM people WHERE id = 1

Отправьте запрос, и вы получите флаг!

Ответ: Ответ не требуется

Эксплуатируйте уязвимость union SQL injection на сайте. Что за флаг?

Ответ: THM{ZGE3OTUyZGMyMzkwNjJmZjg3Mzk1NjJh}.

Задание 9 (Заключение задачи)

Мы подошли к концу работы с задачей Burp Repeater. Надеюсь, вам было удобно пользоваться программой. Не забывайте продолжать практиковать свои вновь приобретенные навыки.

Вопросы

Я могу использовать Burp Suite Repeater!

Ответ: Ответ не требуется

Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.


Перевод статьи был выполнен проектом перевод энтузиаста:

  • 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
  • 🔥 @Ent_Translate - Инстаграм проекта

Report Page