Компания
548,51
рейтинг
22 мая 2014 в 16:00

Разработка → Месяц поиска уязвимостей: как мы к нему готовились и как его пережили



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 баг-репортов. Казалось бы, пора хвататься за голову, но после первой сотни мы поняли, что:
  1. В странах Азии очень, очень много людей, умеющих запускать Acunetix и другие сканеры безопасности.
    Большая часть первых баг-репортов представляла собой идентичные, старательно скопированные отчеты Acunetix, ко многим из которых не прилагалось ни URL, ни адреса сайта. К счастью, волна таких репортов схлынула достаточно быстро.


  2. Мануалы для слабаков. Подавляющее количество оставшихся репортов касалось проектов, которые находились за рамками объявленной программы вознаграждения.

Ценные экспонаты

Однако релевантные отчеты тоже приходили. Бдительными исследователями были обнаружены:
  • недостаточная проверка 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) — niwasaki
2 место ($3000) — reactors08
3 место ($1500) — d1g1

Первые два места мы присудили исследователям, нашедшим в Почте XSS-уязвимости.
XSS — одна из самых распространенных ошибок безопасности в веб-приложениях. По классификации OWASP технический риск этой уязвимости оценивается как «умеренный». Тем не менее, для некоторых сервисов она представляет довольно серьезную опасность: XSS потенциально позволяет атакующему получить временный доступ к содержимому ящика пользователя, посетившего вредоносную страницу или открывшего вредоносную ссылку в письме (хотя при этом невозможно завладеть ящиком, поменять в нем пароль или секретный вопрос, получить постоянный доступ).

Третье место мы отдали за уязвимость недостаточной проверки SSL-сертификата. Такая уязвимость позволяет получить доступ к передаваемым данным, если пользователь выходит через небезопасную сеть — например, в кафе или другом публичном месте.

И мы решили учредить дополнительный приз в $2000 за самую серьезную уязвимость вне скопа (ту самую RCE) для xlimbolandx.

Что дальше?

Однотипные отчеты сканеров не испортили общего положительного впечатления,
мы получили и ценные, профессиональные репорты и остались довольны результатами. Поэтому мы трансформируем конкурс в действующую на постоянной основе программу (о ее условиях можно почитать на HackerOne: https://hackerone.com/mailru).

В рамках программы установлены следующие вознаграждения для разных типов уязвимостей:

Для Авторизационого центра Mail.Ru:
RCE: $10000
SQLi или эквивалент, обход аутентификации или эквивалентная утечка информации: $5000
XSS: $500 (кроме self-XSS)
СSRF: $150-500
Open Redirection: $150-300

Для других проектов, участвующих в программе (из scope):
RCE: $3000
SQLi или эквивалент, обход аутентификации или эквивалентная утечка информации: $2000
XSS: $300-500 (кроме self-XSS)
СSRF: $150-500

Так что, если вы хотите попробовать найти брешь в нашей защите и получить за это вознаграждение — welcome.
Автор: @z3apa3a

Комментарии (26)

  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      ИМХО, сравнивать нужно со стоимостью уязвимости на «черном рынке». И тут вопрос, скорее сколько стоит RCE, позволяющий обойти любую авторизацию mail.ru?
      • +3
        Около 180k$ (*нолик потерял)
        • 0
          Привет,
          а, если не секрет, что за сумма (спрос/предложение) и с какой биржи?
          • 0
            Около 3 лет (в 10м. это, получается, 4 года) назад видел спрос по 40k от 3 человек. Учитывая 0day, который продать можно всем сразу, и индексацию, получим 180k$.
            Вот только, понятное дело, удастся ли найти покупателя — это вопрос сложный :)
        • 0
          Да ну?
        • +1
          Я тоже не очень верю в такие цифры, как и в мифический «чёрный рынок» если честно.
          Пруф, хоть на одну уязвимость проданную за такие или схожие деньги?
  • +2
    Так и не понял из статьи, товарища, который нашел RCE на проекте не участвующем в конкурсе и не отражен в списке призеров, какой суммой поощрили?
    • 0
      Прошу прощения, дополнительный приз $2000, впишу в статью. Все эти суммы — помимо вознаграждения в самой программа Bug Bounty.
  • 0
    Удивительно что XSS в почте оказалась приоритетнее чем XSS в центре авторизации
    • 0
      Звучит парадоксально — но в следствии разделения доступа, прямой ипакт от XSS в почте оказался выше, т.к. есть возможность доступа к письмам. Для XSS в центре авторизации прямого импакта нет — куки центра авторизации HTTP Only и угнать сеанс пользователя через XSS нельзя, с домена центра авторизации нет доступа к проектным доменам, т.е. к письмам получить доступ тоже нельзя.
      • 0
        Давайте продолжим разговор в ЛС, и я расскажу вам немного о эксплуатации XSS в центре авторизации
    • 0
      Если есть желание, можно попробовать поиграться, например, с Oauth и попробовать угнать сеанс пользователя через XSS в центре авторизации. Мы знаем похожий вектор, но он требует дополнительных, не очень вероятных действий от пользователя. Если получится найти вектор, позволяющий сделать это автоматически — мы или поднимем премии за XSS в центре авторизации, если он неустранимый, или выплатим премию как за уязвимость, если он устранимый.
  • 0
    Идея — чтобы отсеять азиа-рисечеров сделать небольшую CAPTCHA для отправки репорта… Что такое XSS, CSRF и тд :)
    • 0
      … сказал азиа-рисечер (=
    • 0
      Бороться роботами с роботами — это нормально, но бороться роботами с людьми все-таки не хорошо. Есть много хороших специалистов, которые занимаются какой-то узкой областью. Человек может не знать что такое XSS и отрапортовать переполнение буфера при разборе письма, например :)
  • 0
    Мануалы для слабаков. Подавляющее количество оставшихся репортов касалось проектов, которые находились за рамками объявленной программы вознаграждения.

    Ок, перестану слать баги вне скопа)
    • +1
      Нет. Ты — шли. :)
      Когда бага интересная это вообще как глоток воздуха, с ней и разбираться приятно.

      Да и вообще мы за любые баги признательны в пределах разумного.
      • 0
        ok :)

        Потом чекните, я добавил парочку в скопе (которые нашёл как раз после phd T_T).
      • 0
        Слушайте, а то что в вашей почте не создаются папки глубже второго уровня иерархии, это баг или фича?
        А то я тут попробовал перекинуть почту на ваше biz.mail.ru — и обломался на том, что ящик со сложной и ветвистой структурой не прилетает…
        • 0
          Синхронизуются все папки, которые отдаются по IMAP. Те, что имеют более высокий уровень вложенности синхронизуются во второй.
          С какого сервиса синхронизация производится? Если какой-нибудь публичный, можем проверить.
          • 0
            И типа, так оно и должно быть, то есть это фича? А теперь представьте себе, во что превращается ящик с 3-мя уровнями вложенности с делением на каждом на 20 папок, в среднем.

            Уходили с communigate, развернутого на своем серваке. В итоге отказались от mail.ru (ровно по этой причине) и ушли в yandex.
            • 0
              Михаил, Вы, возможно, ошиблись записью, потому что буквально в соседней, посвященной biz.mail.ru тусуется руководитель проекта Олег Паринов, которому можно рассказать про ваши потребности. Мне представить необходимость иметь 8000 папок в среднем в одном ящике сложно, а он не только запросто это представит, но еще продумает, как это должно работать, чтобы было удобно, опишет и реализует.
              А здесь, если хотите, можем об ошибках поговорить, причем за деньги.
              • 0
                Спасибо. Я тоже нашел ту запись, напишу туда тоже.
  • 0
    Удалено

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка