3 февр.3 мин. чтения

BugBounty для новичка. С чего начать? | Часть 2

Долгожданное продолжение 🔥ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ

Привет, ребята!

Это долгожданное продолжение первой части моего материала. Если вы пропустили первую часть, то настоятельно рекомендую с ней ознакомиться, а уже потом переходить к изучению второй: BugBounty для новичка. С чего начать? | Часть 1

Ну, а теперь давайте продолжим!

«Быстрый старт» на настоящих примерах

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

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

Уделим внимание внедрению кода, а именно — SQL Injection.

Эту уязвимость рассмотрим на примере MantisBT версии 2.24.3. Эксплойт этой уязвимости CVE-2020-28413 опубликован в специализированном разделе на сайте MantisBT. Поэтому воспроизвести атаку с использованием BurpSuite для перехвата запроса и его повторения, а также sqlmap для более автоматизированного получения информации из базы данных может каждый желающий.

Имеется учетная запись пользователя observer:SEk7AnRiF5 с ролью доступа «Наблюдатель»:

Необходимо настроить прокси между браузером и BurpSuite, а после — перехватить POST-запрос на сценарий /api/soap/mantisconnect.php с указанными данными для авторизации пользователя observer.

Согласно эксплойту, уязвимым параметром SQL Injection будет являться значение тега access. Отправляется легитимный, ничего не нарушающий HTTP-запрос:

В ответ сервер возвращает 200-й статус и запрашиваемую информацию:

Однако, если заменить значение 1 на одинарную кавычку (') в теге access, то в данном случае сервер, согласно эксплойту, должен вернуть 500-й статус с ошибкой о некорректности сформированного приложением и исполняемого базой данных SQL-запроса. Отправление запроса с одинарной кавычкой:

Действительно, сервер отвечает 500-м статусом, а в теле ответа содержится подтверждение наличия уязвимости SQL Injection:

Теперь имеет смысл воспользоваться ранее упомянутым инструментом — sqlmap, с помощью которого можно автоматизировано получить информацию из базы данных, эксплуатируя найденную уязвимость SQL Injection.

Сперва необходимо скачать sqlmap и в его корень папки поместить последний выполняемый запрос с одинарной кавычкой (') в текстовом файле с именем, к примеру request. Вместо одинарной кавычки следует поставить звездочку (*), для того чтобы sqlmap знал, какой параметр в запросе необходимо эксплуатировать.

По умолчанию MantisBT именует базу данных как bugtracker. Зная это, мы можем запросить список таблиц, которые находятся в ней:

Результатом будет служить несанкционированное получение списка всех таблиц в базе bugtracker, к которым также можно обращаться и получать их содержимое.

На HackerOne уязвимости SQL Injection оцениваются так:

Солидно, не правда ли?

Пришло время поговорить про атаки на пользователя.

В моем примере будет рассмотрена атака на пользователя «Межсайтовое выполнение сценариев» (XSS) и «Подделка межсайтового запроса» (CSRF).

В начале рассмотрим атаку на пользователя «Межсайтовое выполнение сценариев» (XSS) на примере системы с открытым исходным кодом GitBucket. Для версии 4.37.1 существует публичный эксплойт, с помощью которого авторизованный злоумышленник имеет возможность внедрить вредоносный JavaScript-код на определенные страницы, при просмотре которых он будет исполняться. Выполнение JavaScript-кода в браузере жертвы может привести к краже cookies, редиректу на другую страницу, внедрению кейлогера (вредоносного ПО для отслеживания нажимаемых клавиш), отрисовки формы авторизации с последующей кражей логина и пароля. В рассматриваемой системе при атаке на администратора имеется возможность полностью скомпрометировать сервер.

Покажем метод внедрения вредоносного JavaScript-кода. Для начала авторизованный злоумышленник должен создать свой репозиторий:

После создания репозитория в нем необходимо создать «вопрос» (issues), в заголовке которого хакером размещается вредоносная нагрузка:

"><img src=1 onerror=alert()>

Далее при посещении главной страницы или страницы злоумышленника (вкладка Public activity) будет исполнен внедренный JavaScript-код в браузере пользователя:

На HackerOne можно посмотреть, насколько опасными могут быть XSS-атаки и как высока может быть награда за их обнаружение:

Рассмотрим другую атаку на пользователя — «Подделка межсайтового запроса» (CSRF) — на примере системы с открытым исходным кодом GitLab.

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

В GitLab для версий ниже 14.0.2 существует уязвимость CSRF:

В данном случае уязвимость позволяет создавать сниппеты (/dashboard/snippets) от лица атакуемого пользователя.

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

На основе публично доступного эксплойта по приведенным выше ссылкам хакер создает на контролируемом сайте страницу с HTML-формой следующего содержания:

После того как авторизованный в системе GitLab пользователь перейдет на сайт хакера с размещенной там формой, от имени этого пользователя выполнится запрос в систему GitLab и будет создан сниппет. После отправки формы сервер вернет ответ, который говорит о том, что сниппет был успешно создан и атака «Подделка межсайтового запроса» на пользователя была проведена.