|
Статья предоставлена компанией Timeweb
Рассказываем об опыте Timeweb Любой компании необходим взгляд со стороны на состояние информационной безопасности сервисов и продуктов. Эту задачу можно решить разными способами, один из которых — участие в Bug Bounty программах.
Bug Bounty программа как свежая сила в деле багхантинга
Bug Bounty («вознаграждение за ошибку») — это программа, которая предусматривает денежное вознаграждение или другие бенефиты за нахождение багов, эксплойтов и уязвимостей в работе ПО. Программы Bug Bounty реализованы многими компаниями, в том числе Facebook, Google, Reddit, Apple, Microsoft и др.
Компания может запустить подобную программу самостоятельно, своими силами организовав все процессы и взаимодействия. Второй вариант — обратиться к специальным Bug Bounty платформам: заключаем соглашение, и армия багхантеров приступает к работе.
Timeweb запустила Bug Bounty программу около года назад. На тот момент в компании не было специалистов с опытом в этой области, всё приходилось делать методом проб и ошибок. В сети почти никто не делится рекомендациями по построению данного процесса, поэтому часто изобретаются велосипеды, а знания обычно передаются в разговорах с коллегами у кофе-машины.
В этой статье мы расскажем, как организовать запуск Bug Bounty программы, если вы ни разу этим не занимались, на что стоит обратить внимание и как еще можно проверить состояние системы информационной безопасности.
Check it out!Почему мы запустили Bug Bounty программу?
Перед нами стояла задача: поднять систему информационной безопасности на новый, более качественный уровень и не потратить при этом слишком много денег. Важно отметить, что Timeweb — зрелая компания со сложной инфраструктурой и большим набором критически важных сервисов, поэтому для нас тогда было совсем неочевидным, в какой очередности нужно тестировать сервисы и закрывать уязвимости, к чему вообще приступать первым делом.
Можно выделить несколько способов, как проверить систему информационной безопасности. Перед запуском Bug Bounty программы мы постарались рассмотреть и проанализировать различные варианты. Среди них, наверное, внешний аудит является наиболее распространенным решением задачи. Благодаря аудиту можно найти сложные, нестандартные проблемы, но, даже заплатив большую сумму, ты не можешь быть уверен, что получишь то, что тебе действительно нужно.
Еще один способ — обучить команду и развить компетенции сотрудников. Здесь необходимо понимать, что ресурсы команды все-таки ограничены, и найти все возможные баги своими силами, конечно, невозможно.
В деле проверки системы ИБ помогают также тикеты и обращения клиентов в техподдержку, если получается эффективно обрабатывать замечения и сообщения пользователей.
Параллельно мы общались с коллегами и собирали экспертные мнения, как выстроен процесс поиска багов в других компаниях. Как раз благодаря рекомендациям мы решили обратить внимание на Bug Bounty программы.
Запуск Bug Bounty программыЧто важно учесть на старте?
Существует огромное количество различных типов Bug Bounty программ и платформ.
На первом этапе мы выбирали между публичной и приватной программами, решив остановиться на последней. В публичной программе доступ не ограничен: все желающие могут искать баги. В приватной программе — по приглашению. В обоих случаях баги раскрываются только по соглашению сторон. Мы посчитали, что публичную программу нам открывать пока рано: прежде всего, мы должны быть уверены, что наши сервисы и продукты не содержат критических уязвимостей.
Что касается самой Bug Bounty платформы, мы проанализировали существующие варианты и выбрали наиболее подходящий для нас, оптимальный по количеству багхантеров и стоимости услуг.
Приводим список наиболее известных Bug Bounty платформ на рынке:
Отдельно стоит отметить платформу Open Bug Bounty — некоммерческая Bug Bounty платформа, которая объединяет ИБ специалистов-энтузиастов и популяризирует этичный хакинг. Исследователи могут сообщить о найденном баге в работе любого ПО, за что компании предоставляет вознаграждение (денежные выплаты, мерч, скидки или собственная продукция). Timeweb, например, предоставляет багхантерам бесплатный хостинг. Обратим внимание, что согласно политике Open Bug Bounty можно сообщать только о багах, которые не подразумевают активного вмешательства, например, RCE и SQL репортить нельзя.
В первую очередь, мы выстроили работу внутри компании: определили, как должны взаимодействовать между собой отделы, кто ответственен за исправление багов, кто следит за обновлением скоупа и ответов на репорты.
Перед запуском программы мы бы посоветовали убедиться, что вы сделали все, что смогли, нашли все возможные баги своими силами. Также важно вдоль и поперек знать продукт, который вы планируете отдать в работу багхантерам: какие проблемы есть сейчас, какие были; появляются ли систематические ошибки. Эта информация позволит вам сформировать корректный скоуп (scope) — емко, но исчерпывающе дать вводные данные и описать запрос для багхантеров.
Платформа выбрана, подготовку провели — начинаем набивать шишки работать!
Формируем скоупРассказываем, что мы поняли за год существования программы
Скоуп, заполняемый на Bug Bounty платформе, своего рода оферта — договор между компанией и сообществом багхантеров. В скоуп необходимо включить следующую информацию:
- указать цель: наличие каких вредоносных воздействий или деструктивных последствий мы бы хотели проверить
- информация об уже известных, неактуальных или неинтересных компании багах (за их нахождение не предусмотрена награда)
- правила и границы поиска уязвимостей, которые следует соблюдать
- размер наград.
Чем больше времени вы потратите на составление скоупа, тем лучше. Постарайтесь заполнить все пункты внимательно и подробно, чтобы в будущем можно было решать все инциденты на основе указанной информации.
Пример секций скоупа с содержанием пунктов на примере нашей действующей программы:
Как выбрать, что именно проверять в первую очередь? Мы бы посоветовали включить в программу такой сервис или аспект, который, скорее всего, больше всех остальных нуждается в проверке. Невозможно сразу понять, что именно нужно искать, можно только выбрать направление, важно нащупать самые проблемные точки. С каждым новым репортом и каждой новой программой мы наращивали опыт и более отчетливо понимали, куда стоит идти дальше.
До сих пор не все наши сервисы и продукты выставлены на Bug Bounty платформу. Это сделано сознательно, так как часть сервисов, например, создана на основе opеn source решений: их развитием и поддержкой занимаются сторонние команды, поэтому мы считаем, что нет смысла их выставлять в рамках нашей Bug Bounty платформы, так как наша команда следит только за актуальностью данных сервисов.
Стоит учесть, сможете ли вы изменить продукт, включенный в Bug Bounty программу: есть ли команда, которая может заняться его развитием; позволяют ли нюансы архитектуры.
Со своей стороны, во время проведения Bug Bounty программ мы постоянно исследовали все сервисы и сеть своими силами. Это позволило нам сэкономить средства: мы исправляли найденные баги и актуализировали скоуп.
Важной составляющей программы является определение уровня критичности найденной уязвимости и установление размера вознаграждения. Постарайтесь зафиксировать прозрачную зависимость между критичностью ошибки и размером награды. Чем прозрачнее, тем меньше вопросов к вам! Хорошая практика — привязать размер награды к шкале CVSS (открытый стандарт для оценки критичности уязвимости). Кроме того, на Вug Bounty платформах обычно выставлены методички и инструкции, как определять размер вознаграждения. Менеджеры площадок смогут вам с этим помочь. Чтобы ориентироваться в уровне оплаты работы багхантеров, можно зайти на портал HeadHunter и проанализировать указанные зарплаты. Если хакеры перестали проявлять активность, возможно, стоит поднять размер вознаграждения.
В Timeweb мы самостоятельно оцениваем критичность ситуации в зависимости от влияния на бизнес. Наша градация критичности багов по влиянию на бизнес включает 4 уровня:
- low (получение не критичной информации о других пользователях, например, название логина или возможность менять аватарки; а также нарушение целостности и доступности данной информации)
- medium (получение доступа к аккаунту другого пользователя и возможность частично посмотреть информацию, например, какие сайты есть на хостинге у этого клиента; а также нарушение целостности и доступности данной информации)
- high (возможность выйти за “пределы” своего аккаунта или сервера; получение критичной финансовой информации: номер счета, логин, сумма на счете, название компании; а также нарушение целостности и доступности данной информации)
- critical (получение доступа к базам данных; а также нарушение целостности или доступности данной информации).
Помимо информации, указанной выше, мы смотрим на тип уязвимости (RCE, XSS, SQL-инъекция) и важность сервера, который взломали или к которому удалось получить доступ.
Таким образом, для установления уровня критичности найденного бага мы анализируем тип уязвимости, важность сервера и степень влияния на компанию. На основании этих критериев мы определяем уровень для каждой найденной уязвимости, от этого и зависит размер вознаграждения багхантеру. Однако добавим, что всё учесть невозможно и часто при определении уровня критичности найденного бага не обойтись без субъективности.
Более детальное описание процесса оценки критичности уязвимости приведено в таблицах:
Таблица оценки сервера/сервиса
Bug Bounty Timeline: Как это было?
Программа №1
Отдаем на растерзание: Панель хостинга Timeweb.ru
Скоуп: Скоуп был составлен на основе примеров других компаний. Spoiler: так делать не стоит! Но нам нужно было с чего-то начинать.
Результаты: В течение недели мы получили 20 репортов, в основном с указанием критичных уязвимостей, и… потратили все деньги, которые положили на счет (несколько тысяч долларов). За эти 7 дней мы увидели повторяющиеся паттерны проблем: множественные проблемы с фильтрацией ввода и отображения данных, различные нарушения бизнес-логики приложения, а также некоторые другие риски по OWASP Top Ten. Мы решили приостановить программу, и следующий месяц занимались только исправлением найденных багов и их анализом.
Как только мы разобрали эти 20 репортов, пришло понимание, что делать дальше: куда копать при разработке, как правильно работать с безопасностью.
Программа №2
Отдаем на растерзание: Панель хостинга Timeweb.ru (снова)
Скоуп: Скоуп мы исправили на основе полученных ранее репортов: убрали исправленные уязвимости и акцентировали внимание на то, что интересно нам.
Результаты: В этот раз мы получили достаточно много критичных репортов, однако более точечных и конкретных. Все таски по Bug Bounty были определены как срочные. Благодаря второй программе мы подкорректировали процессы разработки и исправления багов.
Программа №3
Отдаем на растерзание: панель VDS Timeweb.ru, проверка официального сайта
Результаты: Получили около 40 репортов с багами разной степени критичности.
Поскольку наши продукты схожи по функционалу, иногда они наследуют не только функции, но и баги друг друга. Оказалось, что новая панель содержала баги, которые уже были найдены в предыдущих программах Bug Bounty. Такие баги были прописаны в скоупе как дубликат, поэтому нам не пришлось за них повторно платить.
В работе сайта было обнаружено много проблем с формами и XSS-уязвимостями.
Программа №4
Скоуп: Главной целью четвертой по счету программы стал поиск SQL-инъекций.
Результаты: Перед запуском программы мы самостоятельно изучали, как это работает, и выполнили исследования своего продукта самостоятельно: нашли только 1-2 некритичные уязвимости. Через 2 недели после запуска этой программы ночью нам прислали долгожданный репорт: багхантер продемонстрировал вектор атаки с деструктивным воздействием на базу данных с данными биллинга посредством blind-SQLi. Оперативно в течение 5 минут мы смогли закрыть эту уязвимость: она была в предыдущей глобальной версии ядра, которая до сих пор используется в виде подключаемых модулей для нескольких action в актуальных последних глобальных версиях панелей управления (виртуальный хостинг, VDS, веб-мастера). Мы были в восторге, что смогли обнаружить такую серьезную проблему и вовремя исправить ее. Помимо прочего мы тщательно проверили по аналогии все остальные аналогичные участки кода.
Программа №5
Отдаем на растерзание: Виртуальный хостинг Timeweb
Виртуальных хостинг — это, грубо говоря, физический сервер, поделенный между сотнями клиентов. Клиенты размещают свои веб-приложения и рабочие каталоги на этом сервере, имеют доступ по SSH и FTP к серверу. У каждого из наших клиентов есть собственные клиенты. На таком сервере крутятся наши обслуживающие сервисные скрипты, сервисы и иные кастомизации, которые взаимодействуют с другими обслуживающими сервисами и базами данных.
Скоуп: Основная цель для багхантеров тут была проста: поиск векторов повышения привилегий до root. Также мы ожидали поиск векторов воздействия на других пользователей и их ресурсы, поиск векторов воздействия на наши обслуживающие скрипты и поиск векторов атаки на другие сервера как виртуального хостинга, так и на сервисные сервера, к которым была бы гипотетическая возможность доступа.
Результаты: Мы выделили багхантерам специальный сервер без клиентов, аналогичный по функционалу production серверам. На данный момент багхантеры нашли всего 10 багов. В 2 репортах были продемонстрированы векторы атаки с повышением привилегий до root, но на другие сервера попасть не удавалось. Эти проблемы были моментально исправлены.
Перед запуском пятой программы мы погрузились в обновление серверов и ПО, разбирались со слабыми местами, разворачивали служебные сервисы в локальную сеть, недоступную для внешней сети. Благодаря этой программе мы провели рефакторинг внутренних систем на сервере. Это позволило нам замечать ошибки даже раньше, чем нам о них напишут.
И куда вас это привело?О результатах Bug Bounty программы
За почти год работы Bug Bounty программы мы получили 72 репорта. Из них 36 отчетов не удовлетворяют правилам нашего скоупа. Однако багхантеры нашли 7 опасных уязвимостей критического уровня, 9 — высокого и по 10 багов среднего и низкого уровня критичности.
Чтобы получить такой результат, мы потратили более 15 000$ на вознаграждение багхантерам (без учета комиссии за услуги платформы). Наименьшая награда составила 50$ (за уязвимость, позволяющую получать информацию о способе оплаты любого счета посредством IDOR). Наивысшая выплаченная награда на данный момент — 1 500$. Средний размер вознаграждения: примерно 423$.
Что касается качественных результатов:
сохраняем тонус ИБ-мышц
Поскольку Bug Bounty программа подразумевает постоянный и непрерывный поиск багов, наша ИБ-команда находится в состоянии боевой готовности 24/7.
Можно сказать, что багхантеры симулируют действия хакеров. Они каждый день создают санкционированную “вредоносную” активность, заставляя нас смотреть в оба и не терять бдительность.
держимся в тренде
Багхантеры используют новые сервисы, незнакомые утилиты и современные техники взломов. Благодаря этому наши специалисты могут актуализировать компетенции и знания.
совершенствуем сервис и продукты
Информационная безопасность в целом и Bug Bounty процессы в частности всегда направлены на улучшение и развитие сервиса и продуктов для клиента.
привлекаем сообщество экспертов
В осуществлении информационной безопасности участвуют не только наши внутренние админы, но и полноценное сообщество экспертов с различным опытом и знаниями.
Часто мы спрашивали у багхантеров, как вопроизвести найденный баг и даже как его закрыть. Специалисты были готовы общаться напрямую в Telegram, записывать видео, за что мы им очень благодарны.
соблюдаем дисциплину
Работая с Bug Bounty платформами, мы ответственны за закрытие багов не только перед собой и клиентами, но и перед багхантерами, они ждут обратную связь. Взаимодействие проходит согласно установленному регламенту, мы должны регулярно актуализировать информацию по текущим репортам.
В течение 3 дней мы должны были ответить багхантеру на его репорт: является ли найденная ошибка багом, каков ее уровень критичности. Конечно, мы могли давать ответ и в течение недели, но такое поведение не будет хакер-френдли и может оттолкнуть багхантеров.
лучше понимаем пользователей
Багхантеры — это те же самые пользователи и клиенты, которые передают нам определенный пользовательский опыт в аспектах информационной безопасности.
Есть ли жизнь после Bug Bounty?Мы продолжаем работать в рамках приватной Bug Bounty программы с проверенной платформой. Мы бы хотели эффективно выстроить все внутренние процессы по закрытию и исправлению багов. Как только мы поймем, что багхантеры, с которыми мы сейчас взаимодействуем, стали менее активными, мы попробуем перейти на другие, в том числе более крупные, Bug Bounty площадки, чтобы получать еще больше репортов и найти все возможные проблемы.
Другим направлением развития для нас стало внедрение принципов безопасной разработки. Обычно разработчики занимаются функциональным программированием, а безопасность уходит на второй план. Важно сделать проверку кода на безопасность ключевым моментом любого код-ревью.
Команда Timeweb старается внедрять новые, современные инструменты для аудита информационной безопасности сервисов. О некоторых из ресурсов мы узнали благодаря сотрудничеству с багхантерами.
Постепенно мы подключаем к решению задач информационной безопасности сотрудников технической поддержки: обучаем коллег и усиливаем команду.
Мы готовы разговаривать о Bug Bounty программе бесконечно долго. Возможно, у вас остались вопросы к нашим экспертам, — пишите в комментариях, о чем еще интересно и полезно почитать. Постараемся ответить на все вопросы ниже или расскажем более подробно в следующих статьях. Больше статей здесь:
Блог компании на Habr: habr.com/ru/company/timeweb
Сайт компании: timeweb.com/ru
Community: timeweb.com/ru/community Обсудить в форуме |
