Презентация "Проклятие дубликатов: как выжить в багбаунти и не потерять мотивацию" с VK Security Confab.

Больше всего вопросов возникло по моим начинаниям автоматизации. Буду продолжать наращивать и экспериментировать сколько она будет находить принятых багов в багбаунти.

Всем доброго вечера.

Выложили в открытый доступ мой доклад по тестированию "дана страница авторизации, что делать будем, как выкручиваться?". Пройдем путь программиста Васи (все совпадения случайны), которому надо внести изменения в аутентификацию. Доклад ориентирован на новичков.

#видеозаписи

Известно, что аутентификация, авторизация и идентификация — понятия разные, хоть и взаимосвязанные. А вот какие проблемы присущи этим понятиям?

#БезопаснаяСреда открывает запись доклада об этом.

YouTube | VK Видео

Скачать презентацию с сайта SafeCode

Всем привет.
У VK bugbounty появился личный кабинет багхантера
Теперь можно в одном месте посмотреть процент увеличения выплаты следующего отчета, а не искать следующий комментарий

Текущий % Bounty Pass: 8.

Было интересно
* Как быстро обновится процент после принятого отчета - задержек не замечено.
* Нет ли возможности подшаманить процент через ЛК - не обнаружено

Что еще не хватает?
VK за разные активности назначают промокоды: награждение, принятый, но не оплаченный отчет, на конференциях. Было бы здорово, если бы они так же отображались в личном кабинете.

Начала использовать навыки с работы в багбаунти и писать автоматизацию.

В качестве системы управления уязвимостями используется defectdodjo.
Структура следующая: group -> вендор, project -> бб программа, engagement -> сканер.
Через pipeline_schedules задается багбаунти программа и все ее настройки: логин/пароль тестовой учетки, скоуп, нужно ли сканировать поддомены и тд.

Запуск по cron -> Сбор данных ->DAST -> defectdodjo -> нотификация о новых срабатываниях в телеграм.

Процесс протестирован на текущем Bugs Zone 4. Еще очень много надо сделать, чтобы жать кнопку "богатства", но пользу уже приносит.

Факторы влияющие для меня на то, стоит ли багхантить в программе
* Скорость ответа
* Адекватность
* Честность
* Размер вознаграждения

Первый пункт помогает быстрее понять остальные и ответить на вопрос "а стоит ли тратить время?" Я обычно закидываю 1-2 отчета и жду. Если взаимодействие с программой было успешным и адекватным, то продолжать стоит. Но некоторые 2 месяца отчет в дубликат переводят после напоминаний раз в месяц. Триаж бывает очень долгий, причем у программ у которых 2-5 отчетов за квартал. Для багхантера же черный ящик процессов - отчет за месяц остался со статусом "Новый".

Забить | Напоминать каждые 2 недели | Скидывать мемы о том как ты ждешь?

Мне лично не нужно быстро получить вознаграждение (готова и пол года ждать, такое уже было), но знать, что над отчетом ведется работа, его не забыли - важно. Без знания, что не будет проблем и споров - продолжать искать, кажется, не стоит.

Менять статус с "Новый" или хотя бы писать "Отчет взяли в работу" - важно и полезно.
#bugbounty

Всем привет.
Была на выходных в Иннополисе и вела разборы заданий Т-банк CTF прошлых лет.

Формат:
Было 3 разных задания и в 15, 17 и 19 часов мы вместе с участниками рассуждали и решали задания прошлых лет. Доступа к основным заданиям у меня не было и не подсказывала(не надо ставить красную карточку). В каждом заложено несколько проблем безопасности, которые встречаются на проде и можно найти в багбаунти. Было продемонстрировано сразу 2 подхода: тестирование белым и черным ящиком. Рассуждали как не допустить каждую уязвимость и как ее исправить. Аудитория была разбирающаяся - думала будем Burp устанавливать и все с 0 рассказывать, а ребята сами отвечали. Большие молодцы.

По итогу скажу, что впечатления странные. С одной стороны идея - хорошая, с другой очень мало уж людей было на разборах (от 2-8). Я благодарна всем кто пришел, рассуждать вместе было здорово. Но мне кажется такой движ надо делать только в онлайне в следующий раз.

Про Иннополис: создалось впечатление, что он еще более пустой чем был в 2014 году. Вот в сериалах/фильмах про зомбиапакалипсис бывают сцены, где герой просыпается и никого на улицах. Если встретятся в баре/кафе/магазине/на улице пару человек - уже успех. Где студенты поющие Цоя и Киша, катающиеся на великах, выгуливающие собак, дети на детской площадке? В такой тишине и отсутствии людей не была давно и возможно никогда.

Очень вдохновляют истории, когда исследователь собирает цепочку багов в один красивый вектор атаки. Разбирается, пробует варианты долгое время, не бросает и один из вариантов все-таки получается. Моя любимая статья, победитель Pentest award 2023 как раз такая Как за неделю превратить Open redirect в RCE.

В этот раз уговорила подать какой-нибудь из своих векторов fat_dog с которым мы иногда вместе ищем уязвимости. Он собирал разные мисконфиги в один баг 1 месяц и получил высокорисковый вектор.

Если у вас так же есть о чем рассказать, в этом году стало больше номинаций Pentest award - подавайте заявку до 30 июня.

Хмм, что-то устала, надо отдохнуть от багбаунти. Так же я опять иду вечерами фармить баги. Затягивает иногда похлеще варкрафта (или кто во что залипает - сериалы/книги).

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

Глубоко поражена своей не удачей.

Пока не знаю:
* Отказываться от запуск через gitlab pipeline schedules?
* Костылить через api (у gitlab многие ограничения так обходятся - хочешь нажимать кнопку, то плати).
* Покупать Premium за 29 долларов в месяц, чтобы это ограничение стало 50 или 100 на self hosted?
* Искать race condition в gitlab?
* Переписать все на просто запуск по cron на сервачке?

Столько вопросов и так мало ответов.

Эхх не быть мне BugbountyDevSec-м.
#bugbounty

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

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

https://award.awillix.ru/

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

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

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

В последнее время часто замечаю, что при n-попытке вызвать метод получается обойти проверки.

Например, метод позволяет парсить csv. По тексту ошибки определяешь что эта за библиотека и что она может работать со всеми excel форматами.

Пробуешь загрузить xlsx для тестирования XXE - получаешь ошибку "неподерживаемый формат файла". Пробуешь последовательно вызвать метод n-раз и проверка обходится.

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

Аналогично встречала при подтверждении email. На k-попытку проверку кода подтверждения получается обойти. Но при этом воспроизвести стабильно, чтобы собрать все данные и завести в багбаунти не получается. А пока я пытаюсь получить стабильную версию скрипта, баг обычно исправляют.

Заводите ли в бб плавающие баги?

Всем привет.

Прочитала статью https://habr.com/ru/articles/927672/ и особенно зацепилась

И различные разработчики периодически мне пытались доказать, что найденной мной проблемы якобы нет и им-то лучше знать как работает их код.

Тоже сталкивалась с таким в багбаунти у разных вендоров.

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

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

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

Могу только предположить почему так происходит:
* Любой баг сначала попадает команде разработки, а потом туда приходит ИБ
* Рассинхрон процессов ИБ и dev
* KPI на количество критичных дефектов - именно этим я обьясняю отрицание, попытку скрыть наличие дефекта и быстрый молчаливый фикс. Помню как в мою работу QA нам хотели ввести KPI на наличие дефектов на проде. Я правда уволилась раньше реализации этой инициативы и не знаю чем дело закончилось.
* Бас фактор. Может быть там уволились сотрудники и весь процесс сломался?

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

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

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

#bugbounty #appsec