Всем привет. Совсем недавно, а именно в начале апреля, я решил плотнее заняться хантингом, чтобы немного разнообразить свою работу и посмотреть на безопасность с другой стороны.

Ранее в компании я уже проводил black box-аудиты, и именно это мне всегда нравилось больше всего: ты не просто читаешь код или смотришь схему, а руками проверяешь, как именно эксплуатируется уязвимость и какой у неё реальный импакт. И в bb это ощущается очень хорошо.

━━━━━━━━━━ Чем интересен хантинг ━━━━━━━━━━

В BB можно не только искать базовые уязвимости.

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

Условно: • где-то раскрывается чувствительный токен • где-то находится скрытый эндпоинт, который использует этот токен • сам эндпоинт позволяет сбрасывать пароль • а рядом ещё есть ошибка в обработке JSON, позволяющая подменить почту для восстановления

По отдельности такие баги могли бы получить low или medium. Но в связке это уже может превратиться в high, а иногда и в critical.

━━━━━━━━━━ Как у меня начался путь в BB ━━━━━━━━━━

Вообще, зарегистрировался на bug bounty я ещё год назад. Тогда я оформил 2 отчёта, и оба получили статус informative😁

Сейчас, смотря назад, я понимаю, что один из них, возможно, всё же могли принять, потому что он позволял делать почтовые spam-рассылки, а это входило в scope программы. Но что было, то было.

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

━━━━━━━━━━ Как я выбирал вендора ━━━━━━━━━━

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

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

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

━━━━━━━━━━ Что получилось у меня за апрель ━━━━━━━━━━

За апрель я потестировал веб и мобильное приложение выбранного вендора и в итоге оформил 5 отчётов: • 2 informative • 2 accepted с low-статусом, за которые мне даже символически заплатили • 1 отчёт до сих пор в работе

Из informative один был чисто моей поспешностью: я зарепортил функционал, который на самом деле был доступен в интерфейсе, просто я о нём не знал)

А второй хоть и был принят по сути, но получил informative из-за того, что находился во scope второго уровня.

Для меня это всё равно хороший результат.

Я вообще не рассчитывал, что на старте смогу зарепортить несколько отчётов на крупного вендора, которые ещё и будут приняты и устранены.

━━━━━━━━━━ Что, как по мне, реально помогает ━━━━━━━━━━

Возможно, мне помогло то, что я уже работаю AppSec, занимался не только white box, но и black box, а также в своё время решал лабы: от PortSwigger и Juice Shop до HTB.

Я думаю что для начала не стоит искать в основном функционале только инъекции. Ведь если вендор давно стоит на bug bounty, то с высокой вероятностью всё самое очевидное там уже либо нашли, либо давно устранили.

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

Потому что вулны бизнес-логики — это одновременно и самые “простые”, и самые сложные для репорта. ➤ Простые — потому что часто не требуют редкой технички. ➤ Сложные — потому что для них нужно понимать продукт.

#appsec #bugbounty #Pentest #CyberSecurity