Какие области бизнеса для вас наиболее привлекательны? В каких компаниях интереснее/выгоднее искать ошибки?
BlackFan: Всегда интереснее искать уязвимости в компаниях, услугами и приложениями которых пользуешься каждый день. Ты лучше понимаешь типовые сценарии использования этих сервисов и благодаря этому ищешь уязвимости эффективнее, чем в незнакомых приложениях. Кроме того, всегда приятно улучшать безопасность сервисов, в которых хранятся твои данные.
Если же смотреть на багхантинг как на анализ защищенности, на который ты потратишь пару недель и больше никогда не вернешься к приложению, то область бизнеса не имеет особого значения.
brain: Мне интересна электронная коммерция, потому что у таких сервисов, как правило, большой функционал: от покупки/продажи товаров, различных программ лояльности до возможностей b2b. Также отмечу платформы автоматизации, которых на данный момент на багбаунти не так много. В каждой из них есть функционал для интеграции с другими сервисами, который не всегда учитывает особенности сторонних API. Более того, подобные решения разрабатываются не так часто, поэтому велика вероятность обнаружить в них уязвимость, о которой разработчики даже не догадываются.
С точки зрения финансовой выгоды самые привлекательные компании — те, которые включают все свои сервисы в область действия багбаунти. В противном случае велика вероятность того, что интересующий исследователей функционал окажется на отдельном домене и, несмотря на наличие уязвимости высокого уровня критичности, отчет будет закрыт как «информативный».
r0hack: Интереснее всего работать с сервисами, которыми я пользуюсь в повседневной жизни. Кроме того, мне нравится искать ошибки в больших компаниях, где есть крупные, архитектурно сложные приложения. Например, это могут быть банки, ритейл или маркетплейсы с их порталами для продавцов.
Чаще всего эти направления и являются самыми выгодными. Из-за сложной архитектуры приложений разработчики часто оставляют в них логические уязвимости, а исследователи ленятся во всем этом разбираться, так что багов там предостаточно.
Чем вы руководствуетесь, когда выбираете программу на багбаунти?
BlackFan: Строгих критериев у меня нет — все зависит от цели участия. Если это новая программа, сначала я отсылаю несколько «тестовых» уязвимостей, которые обнаружил за небольшой промежуток времени: смотрю, насколько мои ожидания от сложности поиска багов, взаимодействия с программой и размера выплаты соответствуют реальным. И уже после этого решаю, буду ли участвовать дальше.
Я часто использую багбаунти, чтобы отвлечься и переключиться со сложного или нудного рабочего проекта. В таких случаях я в основном работаю с крупными и известными программами и ищу интересные мне уязвимости. Иногда все это выливается в отдельные статьи или исследования.
Еще есть вариант участия с целью получить максимальный профит в виде очков репутации или выплат за определенное время — например, в рамках какого-нибудь ивента. Тогда мой выбор будет зависеть от размеров выплаты и простоты поиска — время нужно тратить продуктивно :) Но постоянно работать в таком режиме невозможно — это может привести к выгоранию.
brain: При выборе программы я всегда провожу разведку: смотрю функционал сайта, связанных ресурсов и их покрытие багбаунти, оцениваю возможности сервисов. Если работа с API кажется мне приятной (например, когда оно соответствует архитектурному подходу REST), эта программа будет в приоритете.
Другим важным критерием является предыдущий опыт работы с компанией: обычно я нахожу и отправляю несколько багов, а затем провожу оценку нашего взаимодействия. Если все было корректно, я продолжу исследование, в противном случае сменю программу. Оговорюсь: есть ряд программ, работа с которыми была настолько приятной, что я уже долгое время смотрю функционал их сервисов. Я уверен в том, что не столкнусь с недопониманием либо конфликт будет решен компромиссом без вмешательства третьей стороны.
r0hack: Про это я написал отдельный пост. Если кратко, есть несколько факторов:
- Сумма выплат.
- Интересный скоуп (это субъективно, для меня — то, чем пользуюсь в повседневной жизни).
- Сложный или уникальный скоуп.
- «Дырявое» приложение.
- Быстрота обработки репортов (с момента сдачи до выплаты фикса).
- Соответствие ожиданий — ваших и вендора.
Само собой, все эти пункты учитываются по-разному в зависимости от ситуации.
С какими трудностями вы чаще всего сталкиваетесь при поиске багов?
BlackFan: Самая главная проблема — недостаток свободного времени.
brain: Трудности зачастую связаны с СЗИ: не все вендоры адаптируют их для участия в багбаунти. Тогда исследование сервисов сводится к обходу средств защиты и ручному анализу, что сказывается на продуктивности оценки безопасности. Как сказал однажды мой коллега: «У них до багбаунти еще добраться нужно, там WAF-Bypass сначала нужен».
r0hack: С трудностями я сталкиваюсь редко, особенно техническими. Если мне что-то не нравится, я просто перестаю багхантить в программе и не парюсь :) Я давным-давно перестал писать, спорить и т. д. Занимаюсь этим редко и только в том случае, когда спорный момент случился в уже проверенной программе, а на кону крупная выплата. В конечном счете все сводится к комфорту и деньгам.
Вот еще один пост в тему.
Какие виды уязвимостей можно назвать самыми популярными прямо сейчас? Что компании пропускают чаще всего?
BlackFan: Чаще всего в приложениях встречаются уязвимости Broken Access Control (в частности, IDOR) и XSS. Но искать IDOR’ы довольно скучно, поэтому я уделяю больше времени client-side уязвимостям, которые включают дополнительные челленджи (типа обхода CSP или формирования цепочек уязвимостей для увеличения импакта). К сожалению, в российских багбаунти client-side не особо любят и выплаты за них довольно посредственные.
brain: Самые популярные уязвимости относятся к классу «Ошибки логики». Он подразумевает использование штатного функционала веб-ресурса (бизнес-логики) во вред платформе или для собственной выгоды, а также сами логические ошибки: раскрытие UUID по порядковому ID, выдача учетных данных без валидации и т. д. К примеру, внедрение защиты от XSS или LFI можно осуществить на этапе разработки, а саму уязвимость несложно обнаружить при аудите. Ошибки бизнес-логики же лежат глубже, по сути — на уровне архитектуры сервиса, поэтому их сложнее отслеживать.
r0hack: Самыми популярными остаются уязвимости XSS, но за них мало платят. Плюс уязвимости на client-side, которые мне не очень нравится исследовать. Лично я больше всего люблю логические баги (IDOR, Improper Access, Parameter Tampering, Mass Assignment, Privilege Escalation) — они как раз и встречаются в больших и сложных приложениях, о которых я упоминал. Моя стратегия — искать то, что я хорошо умею находить и что точно можно найти почти в любом приложении и получить за это бенефиты.
Расскажите о самом интересном баге/уязвимости в вашей практике?
brain: Сложно выделить что-то одно — каждая уязвимость интересна по-своему. Например, однажды я нашел CRLF-инъекцию на поддомене — она позволяла установить любые значения Cookie. Мне пришлось потратить значительное время на поиск вектора атаки на аккаунты пользователей, но результата это не принесло. Передохнув, я взглянул на баг с другой стороны и сумел отыскать хост, на котором Cookie встраивались в страницу небезопасным образом (буквально в код HTML), при этом ее содержимое кэшировалось на CDN. Тогда-то из одного бага и появились сразу две цепочки атаки: CRLF -> Cookie Injection -> Cookie based XSS; и одновременно с этим Cache Poisoning -> Stored XSS. Мне показалось интересным, что одна уязвимость иногда дает несколько векторов при повышении импакта. В данном случае можно было инфицировать страницы самостоятельно либо через пользователей с вредоносными Cookie (для создания «распределенной сети носителей вредоносного кода»).
Сколько стоила самая дорогая уязвимость, которую вы обнаружили?
BlackFan: Максимальная выплата за одну уязвимость — 2 400 000 руб. Наиболее успешное участие в программе — 70 000 долл. за пять уязвимостей в течение недели. Но это максимально кликбейтный вопрос :) Не стоит рассчитывать, что если один раз повезло, так будет всегда. И не надо ставить заработок на первое место — это самый быстрый путь к выгоранию. В первую очередь важно найти баланс: поиск багов должен приносить удовольствие, а высокие выплаты — это всего лишь удачное стечение обстоятельств и приятный бонус.
Brain: Самая дорогая уязвимость принесла мне более 350 000 руб. И до сих пор приносит, правда уже в других программах: каждая вторая компания допускает эту ошибку :)
r0hack: 15 000 долл.
Что бы вы изменили в общепринятых правилах и условиях программ багбаунти? Что мешает вам работать?
BlackFan: Хотелось бы видеть равные условия для всех участников. Это странно, когда для доступа к определенным сервисам нужно быть москвичом, владельцем таксопарка или сотрудником конкретной компании — иначе не уйдешь дальше формы авторизации :) Если в скоупе есть сервисы, подразумевающие наличие определенного доступа, нужно предоставлять исследователям тестовые аккаунты или демостенды.
Также было бы полезно описывать в правилах сценарии тестирования, которые наиболее интересны компании. Например, получение доступа к аккаунту продавца в программе маркетплейса.
brain: На мой взгляд, текущие правила/условия достаточно хороши и не мешают мне работать. Хотя в них нет некоторых интересных векторов, которыми хакеры могут воспользоваться в реальности. Например, я считаю, что социальную инженерию нужно включать в скоуп (хотя бы ограниченно), потому что подобные атаки проверяют защищенность компании не только с технической, но и с организационной точки зрения (самое слабое звено нельзя не проверять!). Да и атаки на беспроводные сети не будут лишними: чего стоят все эти антибот-системы и WAF, если компания не удосужилась безопасно настроить Wi-Fi?
r0hack: Мешает ужасная система оценки критичности багов у 80% программ. Многие факторы не учитываются, а уязвимости чаще всего ранжируются по непонятным внутренним системам, которые организаторы не выносят на внешнюю аудиторию. Это нужно менять в первую очередь — необходима прозрачная система оценки уязвимостей.
Насколько справедливо, на ваш взгляд, компании оценивают критичность и стоимость багов/уязвимостей?
BlackFan: Сейчас у многих российских компаний стоят слишком низкие выплаты за уязвимости среднего уровня. Даже если за критичные баги установлена выплата 1 млн руб., у багхантеров не хватает мотивации ковырять приложение настолько глубоко, потому что в процессе они получают за обнаруженные уязвимости среднего уровня по 5 тыс. руб.
У меня проблем с оценкой критичности найденных уязвимостей практически не возникает, но только потому, что в основном я ищу классические веб-уязвимости и не углубляюсь в бизнес-логику приложений.
brain: На самом деле четкого механизма по оценке уязвимостей и их стоимости сейчас нет, хотя он очень нужен. Нередки случаи, когда исследователь получает меньше, чем ожидал, что сказывается на его мотивации и желании продолжать охоту за ошибками. В идеале нужны метрики — если не общие по рынку, то для каждой программы или вендора. На данный момент критическая уязвимость может быть оценена как в 150 тыс. руб., так и в миллион — оценка непрозрачна и часто сводится к внутренним метрикам компании.
Моя личная оценка текущей ситуации — 4/5, но только потому, что многие компании стремятся мотивировать багхантеров продолжать исследования и лояльно оценивают нашу работу.
r0hack: Как я уже отметил, большинство компаний оценивают уязвимости как хотят, по секретным внутренним системам. При этом многие говорят, что исследователям мало платят, но я не совсем с этим согласен. Учитывая, что российский рынок багбаунти активно развивается всего пару лет, в целом платят неплохо. Причем у крупных компаний выплаты стабильно растут. Лично меня точно устраивают вознаграждения в 20–30% программ.
Вам часто приходится отстаивать свою точку зрения перед владельцами программ багбаунти?
BlackFan: Практически никогда этим не занимался. Не вижу смысла тратить время на споры, конфликты и т. п. Если мне что-то не нравится, проще игнорировать эту программу.
brain: Конфликты возникают крайне редко, но есть две причины, по которым мне приходилось отстаивать свою точку зрения:
- Отсутствие у вендора восприятия уязвимости в контексте сервиса. Представьте, что вы находите в биржевом сервисе типовую CVE, которая позволяет осуществить атаку типа «отказ в обслуживании». Как вы понимаете, DoS подобного ресурса и условного обучающего веб-сайта имеют совершенно разные последствия. В случае обучающей платформы издержки понесет только сам поставщик товара/услуги, а в первом — ущерб коснется еще и пользователей биржи. Более того, его тяжело будет зафиксировать сразу: последствия могут проявиться только спустя некоторое время. К счастью, после длительного диалога вендоры практически всегда пересматривали свою оценку и принимали мои уязвимости.
- Отсутствие у некоторых вендоров понимания сути уязвимостей. Например, недавно я обнаружил ошибку конфигурации в одном из сервисов, которая позволяла выполнять атаку с подделкой запроса на стороне сервера. При этом уязвимость была слепой, то есть у меня не было возможности получить ответ от внутреннего хоста. Однако по другим признакам было понятно, что ошибка существует. Компания решила не разбираться и закрыла уязвимость как информативную, а на все мои возражения отвечала достаточно просто: «Покажите ответ от внутреннего хоста». Нередко в подобных случаях можно также услышать что-то из серии «не баг, а фича».
Даже приложу вам скриншот сообщения от компании :) Btw: по сообщению можно понять, что больше багов в эту программу я не ношу.
r0hack: За последний год была всего одна ситуация, когда триажер не понял, в чем импакт, и мне пришлось дополнительно все объяснить. В остальном, как я уже говорил, мне легче просто забить. Но я понимаю, что для многих новичков это важный момент. Когда тебя стригут в самом начале, это сильно демотивирует: приходишь с багом, а тебе говорят: «Это вообще не баг, иди отсюда!»
Хотели бы вы работать в штате коммерческой компании или предпочли бы остаться на вольных хлебах?
BlackFan: Моя основная работа связана с анализом защищенности веб-приложений и максимально похожа на багбаунти. Она обеспечивает мне стабильный заработок, а программы багбаунти я использую для реализации своих идей или просто для удовольствия.
brain: Я работаю в коммерческой компании и хочу сказать, что опыт проведения пентестов и участие в багбаунти — это совсем разные вещи. В компании проекты ограничены сроками, а багбаунти — это уникальный опыт долгих исследований: как развивается сервис, какие практики в нем используются, как крупные организации ошибаются при конфигурировании систем. Только совокупность работы в коммерции и участие в багбаунти дают мощный профессиональный рост, поэтому я предпочитаю сохранять текущий темп как работы, так и поиска багов.
r0hack: Я уже работаю пентестером, а багбаунти для меня — это возможность прокачать личный бренд, хобби и дополнительный источник доходов.
Что могут сделать организаторы программ багбаунти, чтобы привлечь больше талантливых исследователей?
BlackFan: В первую очередь нужно хорошо выстроить стандартные процессы: первоначальную обработку уязвимостей, механизмы выплат и исправление найденных багов. Важно, чтобы исследователи с первого бага получали положительный опыт взаимодействия с программой.
В этом году особенно заметна борьба за внимание багхантеров с помощью всевозможных ивентов и конкурсов (что-то принципиально новое здесь придумать сложно). Мне нравится соревновательный формат а-ля Standoff Hacks, когда есть мотивация искать уязвимости и можно очно обсудить их с другими участниками.
brain: С точки зрения вендора: помимо повышения размера выплат, можно привлечь исследователей за счет расширения области действия программы (насколько это возможно). Также важно публиковать не только отдельные домены, но и перечень всех IP-адресов — это позволит специалистам, которым нравится изучение внешнего периметра, занять свою нишу на багбаунти. Аналогично с мобильными приложениями и связанными с ними сервисами. Также можно привлечь больше исследователей путем проведения различных акций.
С точки зрения платформы: необходима активная работа с сообществом, организация публичных и приватных ивентов и, конечно же, увеличение количества программ. Также нужно активнее раскрывать информацию о найденных багах. Многие исследователи попросту боятся начинать охотиться за ошибками, поскольку полагают, что для этого нужен многолетний опыт или что все баги уже обнаружены. Публикация данных о свежих уязвимостях, в том числе простых, поможет исследователям понять, что в программе есть что поискать и новичку, и профессионалу.
r0hack: Достойно платить и честно оценивать критичность багов — это основа! Плюс добавлять в программы больше интересных и сложных сервисов.
Как будет меняться сфера багбаунти в ближайшие годы?
brain: Со временем будет появляться все больше новичков, которые составят уверенную конкуренцию остальным участникам. Площадкам же нужно и дальше увеличивать количество доступных программ и грамотно и активно работать с сообществом. Тогда рынок багбаунти ждет экспоненциальный рост.
r0hack: В лучшую сторону! Мы увидим увеличение выплат и быстрый рост количества программ. Например, Один крупный банк начинал с 250 тыс. руб., а сейчас дошел до миллиона. ИБ-сектор растет и подковывает новых бойцов, многие приходят из разработки, QA-тестирования и т. д. В общем, нас всех ждет счастливое будущее :)
