Баг хантинг что это
Что такое баг-хантинг (и чем он не является)?
Баг-хантинг – это неформальные упражнения по тестированию. Не надо путать их с ситуацией, когда вы развлекаетесь с приложением без цели и смысла, а также не смешивайте их с исследовательским тестированием. Вот почему:
Чтобы добиться результатов (и не потратить время зря), баг-хантинг должен следовать особой методологии. Его нужно планировать, готовиться к нему, и контролировать/отслеживать его процесс в ходе выполнения.
Книг, посвященных этой теме, насколько я знаю, не существует. Лично я пользуюсь процессом, о котором узнал несколько лет назад на одной из конференций STAR.
Как планировать баг-хантинг
Я планирую охоту на баги согласно парному тестированию и сценариям мыльной оперы, совмещенным воедино в форме чемпионата между командами.
Парное тестирование – это ситуация, когда два инженера работают как команда на одном компьютере (или в одном окружении). Идея родилась на основе парного программирования, и имеет те же преимущества – передача знаний, мозговой штурм, позитивное давление от партнерской работы. Я получал неплохие результаты, объединяя в пары инженеров из разных команд, особенно если разработчик сотрудничал с тестировщиком – обе стороны могли делиться своими точками зрения.
Сценарии мыльной оперы – это относительно краткие end-to-end сценарии, которые прогоняют систему через сложную операцию, содержащую быструю (и иногда преувеличенную) цепочку событий. Работая в экстремальных условиях, мы можем найти баги, которые были упущены во время тестирования через контролируемые скрипты и сценарии.
Чемпионат задействует человеческий фактор. Люди должны быть мотивированы, и что может быть лучше для инженера, чем приз! Я слежу за статистикой (количество оригинальных багов, обнаруженных в процессе, самый серьезный найденный баг, наихудший краш системы, и т. д.), и награждаю пару, которая преуспела в каждой категории (обычно это футболки, а один раз мы даже выдали iPod). В любом случае, важен не сам приз, а дух соперничества.
Что нужно учесть, прежде чем планировать баг-хантинг
Для баг-хантинга очень важно не только разработать методологию и сценарии, но и создать правильную атмосферу и особое состояние ума. Убедитесь, что вы весело проводите время, и охота точно оправдает ваши ожидания – или даже превзойдет их.
Особенности национальной охоты на баги или Bug Bounty по-славянски
Почему крупнейший мобильный оператор платит за критические уязвимости 3-мя месяцами бесплатного интернета, государственная авиакомпания считает паспортные данные и дату рождения не конфиденциальной информацией, а служба доставки №1 в стране по скриншотам отрицает утечку данных?
А тем временем, на другом континенте, Пентагон собирает 1410 фрилансеров ИБ-шников и выплачивает 75 000 долларов за найденные уязвимости. Министерство Обороны США так же запускает программу вознаграждения и выплачивает более 100 000 долларов за 118 найденных уязвимостей (багов) на всех официальных сайтах департамента.
В данной статье мы рассмотрим особенности внедрения и обслуживания одного из самых эффективных мер в сфере безопасности (security) — программа поиска и выявления уязвимостей (bug bounty).
Для полноты понимания отношения отечественных компаний к безопасности, раскрою первый абзац, дополнив его фактами и деталями (пруфами):
Недавний пост об уязвимости у компании-авиаперевозчика МАУ и ее неадекватная реакция, дословная цитата: «получаемые данные не являются конфиденциальной информацией (таких как дата рождения и паспортные данные)»
Получше, но такая же странная ситуация была у крупнейшего оператора мобильной связи Киевстар, летом 2016 года. Chief Digital Officer (CDO) Виталий Султан заявил о том, что в компании к безопасности относятся более чем серьезно и выразил свои надежды опубликовать условия bug bounty в течении пару недель… Прошло 2 года, а в Google находится только моя старая статья и внимание(!) полный отчет про full disclosure уязвимости, на которую Киевстар не захотел даже реагировать на сайте openbugbounty
Почему компании и белые хакеры не могут договориться?
Много, казалось бы больших и солидных компаний неадекватно реагируют на репорты белых хакеров, всячески пытаясь сохранить лицо, даже идут на откровенную ложь. Это боязнь потери репутации и не имение четкого плана реагирования. В результате, все оборачивается тем, чего и боялись. Да, все интриги и расследования происходят в тусовке технарей, но рано или поздно инцидент выходит наружу и попадает на страницы бизнес изданий, распространяясь дальше.
Я уверен, что всего этого не было бы, адекватная реакция компании и банальная благодарность разрешила бы любые трения. Давайте немного вникнем и подумаем почему так происходит? Я просто приведу из своего опыта 3 типичных опасения касательно bug bounty программы:
1. А зачем нам подталкивать хакеров на взлом?
— Многие считают, что программа вознаграждения за найденные уязвимости — это излишняя мотивация, которая привлекает не нужное внимание. «Тише едешь — дальше будешь» — говорят они.
Это подход «на авось» — авось пронесет? Bug Bounty — это не только стимуляция хакеров находить уязвимости, а и инструмент управления политикой информационной безопасности. Например, в моей практике, решение открыть программу bug bounty было отличным контр-ударом на попытку шантажа и вымогательства черных хакеров.
2. А если хакеры не пришлют нам найденную уязвимость, а используют ее в плохих целях?
— У хакера всегда есть выбор: сообщать или не сообщать про уязвимость. Он ведь знает, сколько денег он может официально получить. А вдруг с помощью уязвимости он сможет «заработать» в разы больше, например миллионы долларов? Ведь он может скрыть факт нахождения уязвимости, а позднее, с анонимного устройства поступить как черный хакер (black hat hacker)?
Это попытка скрыть нескрываемое или отсрочить неизбежное (вероятное). А вдруг не найдут, а вдруг само после обновления (апдейта) «рассосется»? Чтобы продать или «реализовать» уязвимость нужно время для планирования операции, связи, знания обналичивания и анонимности, а также подготовка. А в условиях конкуренции с другими хакерами (bug hunter’ами) — видна лишь перспектива уступить законное вознаграждение другому, более этичному хакеру.
3. У нас много (апдейтов) предстоит много обновлений ПО, планируется добавление нового функционала.
— Зачем тестировать, то, что мы, вероятней всего, будем обновлять (апдейтить), а так же добавлять дополнительный функционал. Поиск уязвимостей (bug hunting) будет бесполезной работой.
Это вечный ремонт или вечная стройка, на стадии которой находятся все стартапы. Если это не MVP (бета-версия продукта) и продукт уже продается, тратятся деньги на маркетинг — то продукт уже представляет ценность для хакеров. Но хакеры ведь тоже понимают логику принятия решения в стартапах, которые, зачастую, проще всего и взломать. Почему на маркетинг деньги тратятся, а на безопасность — нет?
А какие правила общения между белыми хакерами и компанией?
В конечном итоге, хакеры сами «откроют» программу вознаграждения в любой компании, где захотят. А если сотрудники организации будут нарушать правила раскрытия уязвимостей, то исхода два, и оба негативные: тюрьма для искателя или позор для компании. Примеров множество.
Самый показательный — (из недавнего) — это серия публичных откровений под названием #FuckResponsibleDisclosure. Хактивисты были настолько опечалены безразличной и «пофигистической» реакцией организаций, что прибегли к единственному оставшемуся выходу: предупредить всех публично об опасности, разгласив полную информацию о найденных уязвимостях.
Может ли нарушение обязательств со стороны компании после Responsible Vulnerability Disclosure повлечь за собой право нарушить их хакеру в ответ?
Ответом на этот вопрос считаются правила Coordinated Vulnerability Disclosure. Но кто имеет право координировать раскрытие уязвимости, если вендор отказывается участвовать в этом процессе?
Давайте просто вспомним прописные истины bug hunting’a:
Белый хакер имеет право:
Как поднять бабла на баг-баунти или история о поощрении поиска ошибок
Баг-баунти в нашей IT компании мы используем как способ поощрения сотрудников. В этой статье расскажу, как способы оптимизации процессов помогут вам разбогатеть. Что такое баг-баунти, зачем нужна эта программа, сколько денег она сэкономит вашей компании и как с ее помощью заработать на ламборджини в 25 лет, работая в IT компании тестировщиком.
Что же такое баг-баунти?
Сегодня многие IТ-компании пользуются баг-баунти. Это программа, с помощью которой люди могут получить признание и вознаграждение за нахождение уязвимостей. У программы есть три типа:
Программу баг-баунти мы взяли из мировой практики и адаптировали под свою компанию. В нее входят баги (далее уязвимости), которые связаны с безопасностью приложений.
Любые уязвимости приводят к большим потерям: финансовым, репутационным и другим. Баг-баунти для нашей компании довольно актуальная тема. Так каждая уязвимость обходится дешевле, ведь ее находим мы, а не пользователи. Стараемся устранить проблему до ее появления и до релиза проекта.
Искать уязвимости внутри компании эффективно еще и потому, что разработчики хорошо знают свой продукт. Ребята из команды проекта ищут в нем слабые места и то, как ими можно воспользоваться, за что мы их и поощряем.
Подробнее про уязвимости
Все уязвимости мы делим на следующие группы: критические, блокирующие, минорные и незначительные.
Критические уязвимости включают в себя: вывод средств больше положенного, утечку логинов/паролей, доступ к внутренним ресурсам, удаленное исполнение кода, нарушение бизнес-логики проекта;
Блокирующие: получение доступа к чужому аккаунту, нарушение механизма авторизации/регистрации;
Минорные: уязвимости нарушающие работу внутренних механизмов, нарушение стабильности и/или доступности кошельков, раскрытие деталей устройства внутренней сети;
Незначительные: потенциальное нарушение безопасности, не влияющие на проект в данный момент времени, угроза репутации.
Как награждаем за найденные уязвимости?
Баг-баунти – заимствованный подход к безопасности продукта. Однако есть в нем и авторская нотка – это система распределения денежных премий, которая придумана внутри нашей компании.
У нас никто никогда не остается без премии: есть дополнительный фонд оплаты, из которого поощряются сотрудники в рамках баг-баунти. Когда ребята из проектов находят уязвимость – им достается сумма, соответствующая критичности найденных уязвимостей. Если за квартал уязвимостей не обнаружено, премию между собой делят специалисты по безопасности. Награда может быть равна половине среднего оклада разработчика, третьей, четвертой или пятой его части. Размер вознаграждения напрямую зависит от критичности найденной уязвимости. Нашел в каждом проекте хотя бы по одной блокирующей уязвимости, заработал еще одну зарплату.
Как определяется сложность уязвимости?
Чем опаснее уязвимость для пользователей, тем критичнее. Ну а если положить наш сервис можно одним действием – значит проблема максимально критичная.
Например, если мы вставляем какой-либо символ, и у нас не проходит регистрация, то это один момент. Если же вследствие этих действий нам достается доступ к чужому аккаунту – это более серьезная проблема. И такая уязвимость несет повышенную опасность для пользователей.
Также оцениваем по следующим критериям: нужно ли находиться внутри нашей офисной сети, чтобы воспользоваться багом и нужно ли взаимодействовать с другими пользователями для совершения атаки. Например, необходимо ли скинуть ссылку или можно совершить преступное действие из своего аккаунта так, чтобы другой участник системы об этом не узнал? При этом, если у хакера не так много прав, но он смог принести какие-либо потери, тем серьезнее уровень угрозы.
Как сотрудники ищут уязвимости?
Чтобы найти уязвимость, надо думать как уязвимость. Вот и наши сотрудники выступают в роли злоумышленника. При поиске уязвимостей они пользуются сайтом и мобильным приложением через собственные личные аккаунты. Существует несколько вариантов развития событий: например можно посмотреть код и сделать вывод о возможной уязвимости или не смотреть код, а действовать исключительно как пользователи. Их задача – отыскать пути, как можно обмануть систему.
Как предоставить отчет о найденной уязвимости?
У нас нет обязательной формы отчетности, никаких сложных документов. Нашедший уязвимость подробно описывает ситуацию в свободной форме специалисту по безопасности.
Чтобы убедиться в наличии проблемы, специалист обязательно попробует повторить действие со своего компьютера. Если попытка удалась – уязвимость засчитывается, а нашедшего сотрудника ждет вознаграждение.
Хотите историй из жизни нашей компании? Ловите
Однажды наш сотрудник декомпилировал мобильное приложение, чтобы посмотреть, какие запросы делают пользователи. Для этого он скачал специальное приложение и с его помощью отыскал уязвимость.
Еще один случай напоминает сказку, в которой мальчик кричал о волках, но ему никто не верил. Коллега много раз говорил нам об уязвимости проекта, но никто не думал, что она серьезная. Как только он воспользовался уязвимостью, мы ее быстро исправили. Пример, конечно, плохой, но пользы в нем много.
У нас есть две версии системы: Веб и Мобильная. Если пользователь заблокирован в системе, то на вебе это было видно сразу, а вот в мобильной версии пользователь мог осуществлять свою деятельность дальше.
После таких случаев мы ввели в компании баг-баунти и предугадали множество уязвимостей. Процесс продолжается, и эти, на первый взгляд, неприятные случаи, стали настоящим стимулом внести изменения, которые сегодня позволяют нам тщательнее следить за безопасностью проектов. Один из программистов, во время рефакторинга нашел API, которая была способна остановить деятельность любого пользователя системы. Нужно было лишь авторизоваться и передать в API нужный ID пользователя. Это legacy функционал, которым никто не пользовался в новых версиях системы. При желании можно было остановить деятельность всех пользователей системы простым перебором ID.
Подход положительно влияет на качество продукта в целом. Однако риск для безопасности любой, даже самой надежной системы, остается всегда.
Какие плюсы имеем от использования баг-баунти и что в планах?
За год работы этой программы в компании, имеем только плюсы. Смотрите сами:
На саму программу мы потратили около 2 млн рублей, а сохранили в десятки, а то и сотни раз больше. Нашли и устранили уязвимостей: 18, из которых 13 были блокирующими. В среднем раз в месяц мы находили уязвимость, которая несла огромную угрозу. Поощрили 20 сотрудников, которые нашли и устранили уязвимости.
Схема использования программы проста, а главное помогает нашим сотрудникам стать немножечко богаче и счастливее, а компания может не бояться за безопасность проекта, не говоря уже об экономии огромных средств.
Кстати в следующем году планируем открыть программу для всех, и вы тоже сможете принять участие в поиске уязвимостей за неплохое денежное вознаграждение.
Программы поиска уязвимостей всегда привлекают немало внимания со стороны хакеров и специалистов по безопасности. Ведь это легальный способ неплохо зарабатывать одними только поисками багов (при условии, что есть хороший опыт и голова на плечах). На днях нам представилась возможность взять интервью у багхантера Ивана reactors08 Григорова. Он лидер нашей программы Bug Bounty и занимает 11-е место в общем рейтинге платформы HackerOne.
Как начать искать баги? Может ли это быть единственным источником дохода? В каких Bug Bounty участвовать? Сколько зарабатывают багхантеры? И почему поиском уязвимостей особенно выгодно заниматься в кризис? Ответы на эти и другие вопросы читайте в нашем интервью.
Как ты начал искать баги?
О таком явлении, как Bug Bounty, я узнал года два-три назад, но не сталкивался с ним лично до запуска программы Mail.Ru Group. Когда она стартовала, я решил, что стоит попробовать. На тот момент я очень скептически относился к этому занятию и не надеялся, что мне кто-то выплатит хотя бы доллар.
Мне удалось найти пару багов и получить за это первые вознаграждения, а вскоре я занял в программе второе место. Вот тогда я и задумался, что стоит отнестись к этому делу со всей серьёзностью.
И всего за полтора года ты стал самым результативным исследователем в нашей программе, а на HackerOne входишь в первую двадцатку. Как это так?
Просто учишься, и все дела.
И как же ты учишься?
В основном читаю статьи или презентации, описывающие какие-то конкретные уязвимости. Изучаю книги и ресурсы по данной тематике. Смотрю видеодоклады, митапы, конференции. Изучаю чужие отчёты. Ищу информацию в поисковиках. У меня высшее образование, но оно не имеет отношения к IT.
Какими видами уязвимостей ты занимаешься?
В основном вебом, остальное разве что для забавы. Но всё это вопрос мотивации. Можно и браузер поломать, если поставить себе такую цель.
Есть ли у тебя какая-то постоянная работа?
Постоянной работы нет, поиск уязвимостей — мой основной источник дохода.
Ты работаешь один или в команде? Какая схема больше распространена: командная или одиночная?
Я работаю один. Чаще всего багхантеры работают в одиночку, хотя команды тоже иногда встречаются.
Как выглядит твой типичный день? Сколько времени ты тратишь на поиск багов?
Всё зависит от того, есть ли приглашения на новые проекты. Если одно за другим приходят интересные приглашения или же попадается крупный проект с большим scope, то я могу с утра до ночи зависать в поисках уязвимостей и не замечать, как летит время. Но так бывает редко, и обычно я уделяю этому около 3–5 часов в день.
Можно ли прожить исключительно на доход от Bug Bounty?
Определённо можно, но всё зависит от знаний в этой области, количества времени, потраченного на поиски, приглашений в новые и интересные проекты, а также от стремления и желания найти действительно крутой баг. Ведь можно на одной уязвимости сделать 10 тысяч долларов, а можно зарепортить, к примеру, кликджекинг 100 раз по 100 долларов. Кстати, актуальность багхантинга в кризис существенно растёт, ведь большинство компаний платят за баги в долларах :).
Сколько в среднем зарабатывают багхантеры?
Нужно понимать, что существует очень большой разброс в доходе. Он зависит от множества факторов, прежде всего от опыта исследователя и от того, сколько времени он готов уделять взлому. Многие участвуют в Bug Bounty программах от случая к случаю и не столько ради денег, сколько из интереса или желания усилить своё резюме. Понятно, что их доход, скорее всего, будет небольшим (особенно если брать не разовый выигрыш, а заработок за какой-то период, например за полгода-год).
Кстати, а как попадают в топ?
Для этого нужно присылать много серьёзных багов. Рейтинг строится не по уровню заработка, а по совокупной критичности найденных уязвимостей. Хотя отчасти это влияет и на заработок: чем баг страшнее, тем больше за него обычно готовы платить. Скажем, на HackerOne опасные уязвимости дают в рейтинг примерно 50 баллов, средние — 25, а самые низкие — 15. В профиле у каждого исследователя можно посмотреть и среднеарифметическую оценку, это значение Impact.
Насколько автоматизированы инструменты, которые ты используешь?
Я использую всем известные Burp Suite и sqlmap. А также руки и голову :).
В каких программах Bug Bounty ты участвуешь?
Я стараюсь участвовать во всех программах, как за вознаграждение, так и бесплатно. Конечно, платные для меня в приоритете, но тем не менее я уделяю внимание и бесплатным программам. Например, я отправлял отчёты об уязвимостях и по тем проектам Mail.Ru Group, по которым не предусматривается награда.
Как ты выбираешь программы, в которых участвуешь?
Всё зависит от текущей ситуации. Если меня пригласили в новую приватную программу, то выбор очевиден: как правило, в безопасности таких проектов гораздо больше «дыр», они обнаруживаются быстрее и проще.
А если приглашений давно не было, то я предпочту крупные проекты, в которых выше вероятность наличия багов, упущенных другими исследователями. Или же я могу вернуться к хорошо знакомому проекту, чтобы постараться заново открыть для себя какие-то вещи.
Поясни для наших читателей, что такое приватные программы?
Приватная Bug Bounty — это программа, которая не анонсируется публично и в которую компания приглашает лишь ограниченный круг багхантеров. Это позволяет регулировать количество тестеров, выбирая наиболее опытных и адекватных. Если на проекте ещё никогда не проводился поиск уязвимостей, целесообразно начинать именно с приватной версии, приглашая поучаствовать конкретных проверенных людей. А потом, когда основные баги будут выловлены, можно пригласить к поиску уязвимостей всех желающих.
Как попадают в приватные программы?
Насколько я знаю, на HackerOne приглашают случайным образом. Конечно, сначала нужно набрать какой-то рейтинг на публичных программах, и тогда начинают приглашать. Если ты совсем новичок, шансов получить приглашение в приватную программу у тебя нет.
Чем HackerOne привлекателен как площадка? Есть ли у него какие-то альтернативы?
На данный момент я участвую в программах от HackerOne и от Bugcrowd. Если сравнивать эти две площадки, для меня привлекательнее HackerOne.
Во-первых, сама система репортов намного удобнее: можно красиво оформить отчёт, затем сделать его доступным для других исследователей. К каждому комментарию в репорте можно прикрепить различные файлы. А на Bugcrowd форма отправки репортов запутанная, никаких красивостей для оформления нет, прикреплять файлы можно только в отчёте, но не в комментариях.
Во-вторых, с HackerOne сотрудничает больше крупных компаний. Но с другой стороны, я чаще получаю приглашения на приватные программы от Bugcrowd, нежели от HackerOne. Также у Bugcrowd есть система поощрений для активных исследователей, что весьма приятно.
Службы поддержки на обеих площадках хороши, вам с радостью ответят на любые вопросы. Выплаты производятся обеими площадками без проблем. Оба этих ресурса хороши для исследователей и достойны внимания.
Ты пользуешься возможностью public disclosure на HackerOne?
Да, но довольно редко. Хотя, не скрою, с удовольствием читаю чужие раскрытые репорты.
Бывают ли у тебя спорные моменты?
Изредка. Например, когда несколько однотипных багов засчитывают как один и выплачивают только за один, закрыв остальные репорты и аргументируя это тем, что один фикс исправил несколько уязвимостей. Хотя ты не можешь это проверить, и приходится верить на слово. Бывают случаи, когда через длительное время после твоего отчёта команда безопасности пытается воспроизвести баг, а он уже исправлен разработчиками. В таких случаях что-либо доказать проблематично, если к отчёту не было прикреплено видео.
Несколько месяцев назад у меня был случай, когда багнутый функционал просто исчез. Естественно, команда безопасности не смогла воспроизвести баг и закрыла репорт. А буквально пару дней назад я заметил, что этот функционал вернулся, так что я снова жду подтверждения от команды безопасности.
Бывали случаи, когда компании не платили за баги, которые ты зарепортил?
Было несколько случаев, когда я отправлял критичные уязвимости, но они относились к проектам, не охватываемым программой. Их фиксили и говорили «спасибо». Но тут нет смысла кого-то винить, ведь заранее было ясно, что баги out of scope.
Как ты относишься к программам, в которых не выплачивают вознаграждений?
Зависит от того, какая компания запустила программу. Если это какой-то стартап или некоммерческая организация, то я постараюсь уделить им время и найти что-то ценное.
Если это компания с огромным доходом, мне кажется, как минимум странно, что они не предлагают вознаграждение.
Хотя, как и любой другой пользователь, я бы хотел, чтобы мои данные оставались в безопасности и не были подвержены риску перехвата злоумышленниками. Поэтому я стараюсь защитить и пользователей тех сервисов, которые по каким-то соображениям не могут выплатить награду. Конечно, я не буду в значительной степени углубляться в продукт, чтобы найти как можно больше уязвимостей. Но какие-то лёгкие лично для меня баги, не требующие много времени, я найду и отправлю.
Многие топовые исследователи не такие альтруисты и вряд ли будут иметь дело с бесплатными программами. Отчасти они правы. Но я считаю, что в конечном итоге нужно думать о пользователях и вносить хотя бы небольшой вклад в защиту их интересов.
Расскажи, пожалуйста, про самые интересные баги в твоей практике.
У меня довольно много интересных багов, но, пожалуй, расскажу про последний раскрытый на HackerOne, который сделал уязвимым около 30 тысяч веб-сайтов (преимущественно корпоративных): hackerone.com/reports/111440.
Я решил поискать баги в Zendesk. Программа стартовала довольно давно, и я тщательно просматривал содержимое главной страницы www.zendesk.com, анализируя детали. Меня заинтересовало видео с неизвестного мне на тот момент источника fast.wistia.com.
Также на странице имелся сторонний скрипт с fast.wistia.com, который управлял видео, манипулировал DOM, подгружал данные о видео. Внимательно изучив действие этого скрипта, я заметил, что могу дополнительно подгрузить и исполнить JS-файл с fast.wistia.com. При этом можно полностью изменить путь, название и расширение исполняемого файла. А если мне удастся загрузить и исполнить свой злонамеренный файл, то получится выполнить произвольный сценарий на стороне Zendesk. И я начал искать такую возможность.
Потратив много времени, я понял, что не смогу загрузить файл именно на fast.wistia.com. Тогда я сосредоточился на запросах к fast.wistia.com и заметил JSONP-запрос, который позволял мне манипулировать ответом от сервера. Объединив этот баг с первым, можно было презентовать JSONP-ответ как вредоносный JS-сценарий. И когда у меня это получилось, я начал понимать, что проблема затрагивает не только Zendesk, но и огромное количество магазинов, размещённых на Shopify, огромное количество WordPress- и Tumblr-блогов, множество корпоративных веб-сайтов, около десяти других компаний, имевших собственные программы Bug Bounty, а также самих Wistia. Почти все, кто размещал у себя на сайте видео от Wistia, добавляли и этот уязвимый скрипт.
Первым делом я сообщил об этом в поддержку Wistia. Прождав день, я написал ещё одно письмо, и где-то через час меня заверили, что информация отправлена разработчикам. Прошло ещё два дня, а баг ещё не был исправлен. Конечно, два дня — небольшой срок, но не для подобных багов, ведь под ударом и репутация других компаний.
Мне стало ясно, что багом никто не будет заниматься (потом оказалось, что я был прав), и я стал сообщать об этом другим компаниям в надежде, что они свяжутся с Wistia. Я отправил отчёт в Zendesk, но мне ответили, что ничем помочь не могут и будут просто ждать, пока Wistia решит этот вопрос… Шок, да и только… Тогда я отправил отчёты в Shopify, Trello и Automattic (WordPress). Команды этих компаний не стали ждать Wistia и начали самостоятельно решать проблему, в том числе контактировать с Wistia по своим каналам. И, о чудо, ровно через час после того, как с Wistia связались, баг был исправлен.
Обязательно ли самые интересные уязвимости — самые дорогие?
Нет. Пожалуй, у каждого исследователя есть такие баги, за которые он получил меньше, чем ожидал, или вовсе ничего, но их оценили по достоинству другие исследователи. Вот один из таких примеров, принадлежащий BlackFan: hackerone.com/reports/14883.
Есть мнение, что программы поиска уязвимостей не помогают найти по-настоящему крутые баги. Ты с ним согласен?
Думаю, такое мнение сформировалось из-за большого количества желающих получить халявные деньги, отправив неадекватные отчёты. Этим особенно славятся индусы (хотя среди них есть очень компетентные ребята). И на фоне большого количества таких мусорных отчётов команды начинают задумываться над эффективностью Bug Bounty. Нередко программы закрывают, так и не дождавшись действительно ценных данных или попросту утонув в огромном количестве отчётов.
Что для тебя на первом месте — интересность бага или деньги? Будешь ли ты возиться с заведомо скучным багом, который точно принесёт тебе какой-то доход?
Я не заостряю внимание только на интересных багах. Но в то же время я бы не стал репортить что угодно в погоне за любой прибылью. Я почти никогда не репорчу кликджекинг и всё, что ниже этого по степени критичности. Во-первых, потому что наверняка нарвусь на дубликат и только зря потрачу время, а во-вторых, не все компании принимают подобные репорты.
Какие советы ты мог бы дать начинающим багхантерам?
Прежде всего нужно понимать, что вероятность быстро найти уязвимость обратно пропорциональна времени, в течение которого функционирует программа. Самая лучшая стратегия — не зависать слишком долго в одной программе, участвовать в разных.
Тем не менее, когда я участвую в Bug Bounty, которые уже довольно долго принимают репорты и вероятность обнаружения уязвимости крайне мала, я стараюсь как можно лучше познакомиться с продуктом, найти функционал, которому, вероятнее всего, другие уделили меньше времени. Или же ищу что-то сложное для понимания, что также, вероятнее всего, будет упущено другими исследователями. Стараюсь не упустить из виду какие-либо мелочи. Всё это требует времени, терпения и упорства.
Начать учиться багхантингу можно так: пересмотреть отдельно каждую типовую ошибку безопасности, начав с простых уязвимостей, вроде CSRF, XSS, SQLi. Накопать материал отдельно по каждой из них. Достаточно вбить в поиск на YouTube, и вывалится куча полезного.
Много хороших статей публикуется на Хабре, и там же можно найти упоминания интересных книг. Например:
А вообще как думаешь, какие тренды сейчас есть в области Bug Bounty? Что нас ждёт в 2016 году?
Ещё несколько лет назад Bug Bounty были редкостью, а сейчас открывать такие программы — тренд, и можно ожидать, что всё больше компаний будут приходить на такие площадки, как HackerOne. Всё более востребованными будут становиться приватные программы. У Bugcrowd появился новый формат приватных программ — Flex-программы с ограниченным бюджетом и призовыми. Мне кажется, они понравились компаниям и будут постепенно набирать популярность.