Крупные вендоры и ИТ-компании все чаще прибегают к краудсорсингу для поиска уязвимостей. В прошлый раз мы посмотрели, зачем и как это можно сделать, а в этот раз хотелось бы обратить внимание на недостатки такой системы.
Ресурсы
Забавно, что некоторые говорят: вот сделаем баг-баунти, и не нужны нам пентестеры (внутренние или внешние — не важно в данном ключе) — сэкономим круто! Что ж, такое можно сказать, но примерно через месяц выяснится несколько печальных вещей:
- охотники за багами далеки от системного подхода;
- большинство баг-хантеров тестируют довольно ограниченное количество атак;
- большая часть отчетов содержит либо неполную информацию, либо ложную;
- большинство баг-хантеров не старается искать ресурсы — основной упор будет делаться на самые популярные и известные ресурсы (что легко гуглится).
Только эти пункты уже достаточно говорят о таком проекте. В итоге мы имеем кучу отчетов по самым попсовым ресурсам о XSS и пару SQLi. Любые более-менее интересные, сложные или архитектурные вещи так и останутся ненайденными. Разумеется, бывают случаи, когда кто-то хочет блеснуть эрудицией и мастерством, но это исключения из правил. Тем не менее даже такие «исключения» ограничены — временем и желанием, а в итоге максимум PHP-баги и XXE в более спрятанных ресурсах разбавляют тонны отчетов (с дубликатами, естественно) о XSS и clickjacking. И главная проблема — люди, которые будут эти отчеты разбирать. Ведь надо не просто посмотреть отчет о XSS, надо убедиться, что это не дубликат, что в других параметрах или скриптах того же плана подобной проблемы нет. Потом убедиться, что атака вообще возможна, что это не self-XSS, заполнить тикет, сгенерить ответ, связаться с разработчиками, назначить время исправления и так далее, и тому подобное. Короче, это требует людских ресурсов, причем эти люди должны разбираться в предметной области. При этом, возможно, остаются проблемы, которые баг-хантеры пропускают. В итоге мы получаем что-то, что не покрывает весь код и все возможные проблемы, поэтому говорить, будто краудсорсинг позволяет избавиться от «оффенсив секурити», неверно. Да, это круто, да, это позволяет найти много проблем, но этого еще недостаточно. По крайней мере на первом этапе развертывания такой программы. Ведь есть еще зависимость от времени: активность наиболее высока в первые месяцы (один, два) с начала программы. Потом выясняется, что большинство халявных багов уже найдены, и тогда народ забивает до тех пор, пока не наткнется на новый ресурс, «который еще не смотрел». Но все это хаотично и несистемно. Итак, на самом деле такая программа может иметь место именно тогда, когда есть команда внутренних/внешних специалистов, которые выпускают продукт/сервис, проведя все проверки «по-взрослому», и оставляют для постоянной «поддержки» и проверки багов на откуп сообществу баг-хантеров. Это и очень мотивирует, и позволяет спать более крепко (ну да, как же… но мечтать-то не вредно?). Еще один минус: если в вашей сети есть IDS, то количество алертов возрастет, и опять же эти алерты надо разгребать, а значит снова — людские ресурсы. Таким образом, число инцидентов возрастет, следовательно, будет больше форензики и работы для response-team (если таковые вообще имеются, для русских компаний это все не так актуально, есть же только риск проверок по ПДн). Но если у вас мало ресурсов, которые пригодны для баг-баунти-программы, то можно вписываться ограниченным контингентом девелоперов и админов, без команды секурити, все очень зависит от размеров, масштабов и возможностей. Так что тут есть что планировать и обдумывать.
Материал
Итак, мы начали программу по баг-баунти. Мы бодры, веселы, мы ждем… И вот самое первое, что бросается в глаза, — качество материала, а именно отчетов. Каждый ресерчер видит проблему по-своему, и так же по-своему он видит то, как ее следует преподнести, поэтому заранее продумайте правила приема репортов, формат и прочее. И даже в этом случае будьте готовы получать в аттачментах зоопарк архивов всех мастей, PDF-, DOC- и даже RTF-документы. Но это еще полбеды. Самое печальное, что может вас ждать, — это формат подачи. Например, текст, где говорится, что на таком-то сайте у вас нет заголовка X-Frame-Options, а значит, возможен кликджакинг. Это замечательно и мило, но если на сайте нет никаких форм ввода и контроля, то кого это волнует? Или, например, отчет, где все, что есть, — это сообщение о наличии XSS и скриншот alert(‘XSS’). Все такие отчеты приводят к одному — трате времени, а ведь баг-баунти задумывался наоборот — чтобы время экономить. Ресерчеру не так сложно написать дельный отчет, зато это очень сильно ускорит процесс его валидации, проверки вектора и, как результат, обратный ответ. Кроме того, квалификация тех, кто этот отчет валидирует, как было сказано выше, тоже должна быть на достаточном уровне, иначе будут забавные кейсы. Вот вам реальная история, не связанная с баг-баунти, но пример того, что может быть, если секурити-инциденты будут разбирать на скорую руку. В одной небольшой компании было несколько сервисов, и один умный парень догадался запустить сканер. После чего сканер выдал, что найдена уязвимость:
http://serv.site.com/?goto=file:///etc/passwdМолодой хакир в своем BugTraq’e открыл браузер и ввел URL. И о чудо, действительно он увидел заветный файл /etc/passwd в экране браузера. Как человек ответственный, он написал в техподдержку компании и гордо сообщил о проблеме. Специалист компании открыл браузер в своей юбунте, ввел URL и тоже увидел заветный файл. Завалидировал тикет, присвоил статус «Супер-Критикал-Мы-Все-Умрем». Девелоперы через пару дней закрыли тикет и, как следствие, багу. Менеджер компании, увидев, что был такой случай, решил вознаградить хакера. Но никто не спросил разработчиков, в чем же была проблема. Ну и ладно… но на самом деле то был обыкновенный open-redirect, и что хакер, что специалист техподдержки, открыв этот URL в браузере под Linux, гордо лицезрели свой собственный локальный /etc/passwd. Вы же понимаете, что это провал? А теперь учтите, что если ваша баг-баунти-программа предлагает реальные барыши и плюшки, то найдется процент баг-хантеров, который будут тупо впаривать вам булшит, в надежде поиметь с вас профит на халяву. Поэтому те, кто будут разбирать кейсы, должны четко шарить в вопросе.
Этичные хакеры
Ну и последнее, скорее, о наболевшем. Есть группа людей (баг-хантеров), которые относятся к этому всему как к работе, за которую им должны. И, открывая баг-баунти программу, невольно понимаешь, что мир полон жадных людей. Например, у нас в оркестре всегда, еще до баг-баунти, была неофициальная программа поощрения, о которой люди не знали. То есть был кто-то, кто находил баги и слал их нам просто потому, что он клевый парень, и мы благодарили его за это, как могли, соответственно стараниям во имя мира, дружбы и любви. Вот такие отношения ценятся, но то, что порождают баг-баунти программы, по моему мнению, немного убивает понятие этичности в угоду рынка. При этом страдает и качество. Например, многие «исследователи», найдя тупо-XSS, получают благодарность на сайте, скажем, Microsoft. Они делают шумный пост у себя в блоге о том, как помогли МС спастись от угроз, добавляют ссылку в резюме и выдают себя за убер-специалиста. И ведь продадут себя кому-то, кто не будет вникать в детали. Это все, конечно, не наши проблемы, но на общий уровень шума это немного влияет, делая мир «грязнее».
Вместо вывода
Любая программа или проект, который вы хотите развернуть, должны иметь четкие цели, при этом надо понимать все возможные преграды и проблемы. В конечном счете если цель оправдывает те средства, что будут вложены, значит, это стоит того. То же самое и с баг-баунти — не стоит думать, что это выгодный суперпроект, который бесплатно сделает вас безопасными, исключит пентесты как необходимость и вообще сведет всю секурити лишь к проверке отчетов и закрытию багов. Все гораздо сложнее и очень сильно зависит от размеров скоупа, кадровых возможностей и правил самой программы.
Алексей Синцов, defconrussia@gmail.com
