Месяц поиска уязвимостей: как мы к нему готовились и как его пережили
21 апреля совместно с Hacker One мы запустили программу поиска уязвимостей. 20 мая завершился конкурс, ставший первым шагом этой программы. Сегодня мы хотим рассказать, как мы укрепляли нашу оборону, готовясь к конкурсу, как исследователи искали в ней бреши и что они помогли нам найти.Конечно, бросаться открытой грудью на амбразуру bug bounty мы не собирались. Программу поиска уязвимостей мы запустили как самую серьезную и эффективную проверку на прочность для тех security-фич, которые мы реализовали за последние пару лет. Одним из самых мощных рубежей нашей обороны стало внедрение SDC. Но начнем с небольшой предыстории.
Проекты, объединенные доменом Mail.Ru, представляют собой огромную гетерогенную структуру. Сейчас в домене Mail.Ru размещено более 50 разных проектов, имеющих собственные поддомены. В их разработке участвуют команды со своими сложившимися подходами, инструментарием и стандартами качества. Кроме того, бывают разовые проекты, которые создаются под определенное событие. И это не говоря о проектах партнеров.
Как при таких объемах кода сделать так, чтобы пользователю было удобно (и не приходилось заново вводить пароль на каждом сервисе), и при этом безопасность не страдала (чтобы ошибка в сайте-открытке с поющими котиками не приводила к угону почтового ящика)? Мы решили: Сепарируй @ Сегментируй.
Сепарируй @ Сегментируй
Первая часть нашего плана по защите пользователей — сепарация привилегий — работала в Mail.Ru в течение многих лет; в рамках работы над усилением безопасности мы реструктурировали ее, свели к единому стандарту и укрепили. Вторую часть плана — сегментацию доступа — мы реализовали сравнительно недавно.
Сепарация привилегий подразумевает, что только хорошо контролируемая часть приложения с ограниченным функционалом и минимальным API имеет доступ к критичным данным.
Сегментация доступа означает, что компрометация одного приложения не приводит к компрометации других приложений.
В организации сеансов пользователя такой подход реализуется с помощью разделения сессий, или secure domain cookies (SDC), более подробно о котором мы расскажем в отдельном посте. Введение SDC позволило нам логически разграничить доступ на разные проекты, а также стандартизировать и минимизировать код по контролю доступа пользователей в разных проектах.
Мы активно работаем над переводом всех проектов Mail.Ru Group на SDC, но процесс это небыстрый. Тем не менее, мы смогли обезопасить наиболее критичные проекты. Прежде всего на SDC перешли Почта, Облако, Календарь и «Mail.Ru для бизнеса».
Итак, мы провели аудит проектов, устранили найденные недочеты, реализовали SDC. Пришло время устроить нашей системе безопасности проверку в стрессовых условиях, и мы решили, что лучшим способом станет запуск программы поиска уязвимостей.
Награду мы назначили за обнаружение уязвимостей в веб-версиях и мобильных приложениях Почты, Облака и Календаря, а также в «Mail.Ru для бизнеса» и Авторизационном центре Mail.Ru. В качестве партнера и площадки выбрали ресурс HackerOne.com. HackerOne — некоммерческая организация, занимающаяся вопросами кибер-безопасности. Почему именно HackerOne? Во-первых, это одно из самых авторитетных в мире хакерских коммьюнити. Среди сооснователей — ведущие мировые эксперты в этой области. Одна из крупных инициатив, проводящихся на площадке, — поиск уязвимостей в популярном ПО с открытым кодом. На их исследования идет 30% денег, вносимых коммерческими сервисами (включая нас. Кстати, мы стали на HackerOne первой российской компанией). Именно через платформу Hackerone была выплачена награда за обнаружение печально известной уязвимости Heartbleed, которая недавно привела к крупнейшей в истории человечества утечке данных. Во-вторых, у HackerOne очень удобные условия и интерфейс для участников.
Итак, мы запустили bug bounty и стали ждать отчетов.
Армия сканеров спешит на помощь
Долго ждать не пришлось. Едва ли не в первые секунды после того, как программа стартовала, нам посыпались отчеты. Такое чувство, что исследователи со всего мира (особенно из Азии, особенно начинающие) под девизом «Вот он, мой звездный час!» бросились штурмовать нашу оборону. За первые 4 дня работы программы мы получили 750 баг-репортов. Казалось бы, пора хвататься за голову, но после первой сотни мы поняли, что:
В странах Азии очень, очень много людей, умеющих запускать Acunetix и другие сканеры безопасности.Большая часть первых баг-репортов представляла собой идентичные, старательно скопированные отчеты Acunetix, ко многим из которых не прилагалось ни URL, ни адреса сайта. К счастью, волна таких репортов схлынула достаточно быстро.
Мануалы для слабаков. Подавляющее количество оставшихся репортов касалось проектов, которые находились за рамками объявленной программы вознаграждения. Ценные экспонатыОднако релевантные отчеты тоже приходили. Бдительными исследователями были обнаружены:
недостаточная проверка SSL-сертификата; клиентский HeartBleed (разновидность HeartBleed против клиента, которая не так опасна, как серверная, но все же достаточно критична); утечка информации (информация может быть доступна другому приложению на устройстве или передается по незащищенному соединению); удаленная DoS-уязвимость в одном из почтовых приложений (на письме с определенными данными); подмена контента; некоторое количество XSS- и CSRF-уязвимостей; уязвимость, позволявшая выполнять команды на сервере (RCE). О последней — подробнее: ошибка была найдена на проекте, не включенном в программу. Однако, поскольку она оказалась единственной уязвимостью с выполнением кода — и самой серьезной из найденных за месяц действия программы, — мы решили включить обнаружившего ее участника в число призеров.О самых интересных кейсах мы обязательно расскажем в одном из следующих постов.
Немного статистики
За месяц действия программы исследователи обнаружили 194 бага (не являющихся дубликатами и воспроизводимых). В это число вошли как ошибки на проектах, которые участвуют в программе, так и баги на других проектах.
В цифрах:
На проектах, входящих в программу На проектах, не входящих в программу Удаленное выполнение кода 0 1 Инъекции SQL 0 7 XSS 14 68 Доступ к данным между доменами или приложениями 14 4 CSRF 11 26 Недостаточная защита транспорта 4 2 Прочие малокритические 18 27 Победители
1 место ($5000) — niwasaki2 место ($3000) — reactors083 место ($1500) — d1g1
Первые два места мы присудили исследователям, нашедшим в Почте XSS-уязвимости.XSS — одна из самых распространенных ошибок безопасности в веб-приложениях. По классификации OWASP технический риск этой уязвимости оценивается как «умеренный». Тем не менее, для некоторых сервисов она представляет довольно серьезную опасность: XSS потенциально позволяет атакующему получить временный доступ к содержимому ящика пользователя, посетившего вредоносную страницу или открывшего вредоносную ссылку в письме (хотя при этом невозможно завладеть ящиком, поменять в нем пароль или секретный вопрос, получить постоянный доступ).
Третье место мы отдали за уязвимость недостаточной проверки SSL-сертификата. Такая уязвимость позволяет получить доступ к передаваемым данным, если пользователь выходит через небезопасную сеть — например, в кафе или другом публичном месте.
Что дальше?
Однотипные отчеты сканеров не испортили общего положительного впечатления, мы получили и ценные, профессиональные репорты и остались довольны результатами. Поэтому мы трансформируем конкурс в действующую на постоянной основе программу (о ее условиях можно почитать на HackerOne: https://hackerone.com/mailru).
В рамках программы установлены следующие вознаграждения для разных типов уязвимостей:
Для Авторизационого центра Mail.Ru: RCE: $10000SQLi или эквивалент, обход аутентификации или эквивалентная утечка информации: $5000XSS: $500 (кроме self-XSS)СSRF: $150–500Open Redirection: $150–300
Для других проектов, участвующих в программе (из scope): RCE: $3000SQLi или эквивалент, обход аутентификации или эквивалентная утечка информации: $2000XSS: $300–500 (кроме self-XSS)СSRF: $150–500
Так что, если вы хотите попробовать найти брешь в нашей защите и получить за это вознаграждение — welcome.
