Хабрахабр

Особенности национальной охоты на баги или Bug Bounty по славянски

Почему крупнейший мобильный оператор платит за critical bug 3-мя месяцами бесплатного интернета, гос. авиа компания считает паспортные данные и дату рождения не конфиденциальной информацией, а служба доставки №1 в стране по скриншотам отрицает утечку данных?

А тем временем, на другом континенте, Пентагон собирает 1410 фрилансеров ИБ-шников и выплачивает 75 000 долларов за найденные баги. U.S. Dept Of Defense так же запускает программу вознаграждения и выплачивает более 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. А если хакеры не пришлют нам найденную уязвимость, а используют ее в плохих целях?

— У bug hunter'a всегда есть выбор: репортить или не репортить уязвимость. Он ведь знает, сколько денег он может официально получить. А вдруг с помощью уязвимости он сможет «заработать» в разы больше, например миллионы долларов? Ведь он может скрыть факт нахождения уязвимости, а позднее, с анонимного устройства поступить как black hat hacker?

Это попытка скрыть нескрываемое или отсрочить неизбежное (вероятное). А вдруг не найдут, а вдруг само после апдейта «рассосется»? Чтобы продать или «реализовать» уязвимость нужно время для планирования операции, связи, знания обналичивания и анонимности, а так же подготовка. А в условиях конкуренции с другими bug hunter'ами — видна лишь перспектива уступить законное вознаграждение другому, более этичному хакеру.

3. У нас много апдейтов предстоит, много функционала планируется добавить.

— Зачем тестировать, то, что мы, вероятней всего, будем апдейтить, а так же добавлять дополнительный функционал. Bug hunting будет бесполезной работой.

Это вечный ремонт или вечная стройка, на стадии которой находятся все стартапы. Если это не MVP и продукт уже продается, тратятся деньги на маркетинг — он уже представляет ценность для хакеров. Но хакеры ведь тоже понимают логику принятия решения в стартапах, которые зачастую, проще всего и взломать. Почему на маркетинг деньги тратятся, а на безопасность — нет?

А какие правила общения между белыми хакерами и компанией?

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

Самый показательный, из недавнего — это серия публичных откровений, под названием #FuckResponsibleDisclosure. Хактивисты были настолько опечалены безразличной и пофигистической реакцией организаций, что прибегли к единственному оставшемуся выходу — предупредить всех публично об опасности, разгласив полную информацию о найденных уязвимостях.

Может ли нарушение обязанностей со стороны компании после Responsible Vulnerability Disclosure повлечь за собой право нарушить их хакеру в ответ?

Ответом на этот вопрос считаются правила Coordinated Vulnerability Disclosure. Но кто имеет право координировать раскрытие уязвимости, если вендор отказывается участвовать в этом процессе?

Давайте просто вспомним прописные истины bug hunting'a:

Белый хакер имеет право:

  • Начать процесс выявления уязвимости при обнаружение ее признаков.
  • Передать информацию об уязвимости ответственному лицу в компании

Не имеет право:

  • Наносить непоправимый ущерб в процессе выявления уязвимости.
  • Разглашать уязвимость третьим лицам.

Кроме того:

  • Нет обязанности быть волонтером для коммерческих компаний и бесплатно помогать им улучшать безопасность.
  • Требовать деньги или ставить любые условия перед тем как раскрыть уязвимость — это шантаж.
  • Спрашивать о денежном вознаграждении перед раскрытием уязвимости — это не white hat hacking

Белых хакеров не остановить. Они будут присылать в тех. поддержку баги, которые они находят. Терпеливо ждать ответа и пояснять. Присылать Proof of Concept и скриншоты с видео. Блюсти негласные resposible disclosure и публично раскрывать уязвимости, предупреждая всех об опасности связываться с организацией.

Теги
Показать больше

Похожие статьи

Кнопка «Наверх»
Закрыть