Сегодня Яндекс вместе с организаторами конференции ZeroNights запускает конкурс по поиску уязвимостей в Яндекс.Браузере. Его участники смогут не только помочь миллионам пользователей, но и побороться за вполне материальные призы.

Публиковать пост на Хабрахабре только ради анонса конкурса было бы слишком скучно, поэтому я совмещу полезное с полезным и расскажу вам, почему наша команда внедряет в браузер дополнительные технологии защиты (например, проксирование трафика открытого wi-fi), а не ограничивается лишь закрытием уязвимостей. Было бы интересно обсудить с вами наше видение.



Конкурс
Уверен, читатели Хабра согласятся, что безопасность это не конечный результат, а процесс постоянного поиска и исправления проблем. Какую бы защиту вы ни разработали, рано или поздно ее кто-то пробьет. И чем больше у вашего продукта пользователей, тем чаще защиту будут испытывать на прочность.

В этой ситуации было бы неправильно игнорировать опыт и знания сторонних специалистов. Конкурс, о котором далее пойдет речь, это первая попытка нашей команды Браузера организовать такую совместную работу, поэтому будем благодарны вам за отзывы и помощь. И если все получится, и браузер в результате станет безопаснее, то мы продолжим эту практику, а в перспективе включим Яндекс.Браузер и в постоянную программу «Охота за ошибками».

С 26 октября по 20 ноября любой исследователь может попробовать найти уязвимость в Яндекс.Браузере и сообщить нам о ней через специальную форму. Среди всех участников конкурса будут выбраны трое победителей, которые пришлют наиболее критичные и неожиданные уязвимости. В качестве наград они получат 500, 300 и 150 тыс. рублей в зависимости от призового места. Объявление победителей будет происходить на «хакерской конференции» ZeroNights 26 ноября в Москве.

Уязвимости нужно искать в стабильной версии Яндекс.Браузера не ниже 15.10 (бета-версии не участвуют) для операционных систем Windows и OS X.

Более подробно правила описаны здесь.

Что нужно искать:

— Возможность обхода защиты в общественных сетях Wi-Fi, а именно создания незащищённого подключения в открытой сети Wi-Fi либо перехвата/модификации HTTP-трафика.
— Возможность обхода защиты паролей, а именно получения пароля пользователя, совпадающего с паролем от Яндекса, в обход предупреждения о вводе пароля от Яндекса на другом сайте. (Принимаются только методы обхода защиты при вводе паролей через стандартные веб-формы HTML вида <input type=password>.)
— Возможность обхода защиты паролей путём подбора пароля от Яндекса.
— Возможность удалённого выполнения кода (remote code execution) через Use-After-Free, Integer Overflow, Stack/Heap Based Overflow, Memory Corruption и т.д.
— Возможность обхода Same Origin Policy (SOP), а именно выполнения Universal XSS (UXSS), обхода SOP через Cache-Timing, а также Browser-API уязвимость.
— Возможность обхода Content Security Policy (CSP) за исключением обхода CSP через расширения браузера или подмену HTTP-заголовков.
— Ошибки в реализации SSL\TLS, проверке сертификатов, проведении SSL-Strip с сохранением статуса защищённого соединения у ресурса.
— Возможность запускать старые версии плагинов без подтверждения пользователем (click-to-play bypass).
— Удалённый отказ в обслуживании (Remote DoS) через JS или HTML.

В списке областей, где мы рекомендуем искать проблемы, вы можете заметить две наши новые технологии: шифрование открытого wi-fi и защита паролей от фишинга. В следующем разделе поста я постараюсь объяснить, почему мы внедряем такие механизмы и считаем эту практику важной.

Как защищать людей?

Совсем недавно Яндекс.Браузеру исполнилось три года. За это время продукт оброс возможностями (если будет интересно, перечислю их в комментариях), стал популярнее (второй по популярности десктопный браузер в России как по нашей Метрике, так и по данным Liveinternet.ru). Наша работа над безопасностью также претерпела изменения. В первое время от нас требовались лишь регулярно перевозить весь свой багаж технологий и доработок на более свежий Chromium (кстати, вопреки расхожему мнению, уже тогда мы умели бэкпортить к себе критичные исправления из новых версий Chromium). Этого вполне хватало, ведь мошенники и разработчики malware ориентировались на другие, более распространенные в те времена, браузеры. Но со временем все изменилось.

Вскоре мы узнали, каково быть целью для мошенников. Все началось с быстрого роста количества обращений в поддержку с жалобами на встроенную в браузер рекламу (до 30% от всех обращений). Как вы уже могли догадаться, причиной большинства проблем были вредоносные расширения, чьи создатели «признали» Яндекс.Браузер. К сожалению, это было понятно далеко не всем. Многие пользователи обвиняли нас в монетизации подобным способом и удаляли браузер. Поверьте, это обидно. Но мы решили не обижаться, а работать над защитой. И это принесло свои плоды. Подробнее об этой истории мы рассказывали здесь. Но самое главное в ней то, что она во многом определила одно из направлений развития Яндекс.Браузера.

Безопасность пользователей браузера (да и многих других продуктов) зависит не только от наличия в нем уязвимостей, но и от внешних условий. Даже если у вас идеальный непробиваемый продукт (да, это фантастика), многие пользователи все равно станут жертвами мошенников, просто потому что их могут обмануть, или их данные могут идти через незащищенный канал связи, или по многим другим причинам, за которые разработчик не отвечает. Что делать в этой ситуации?

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

Защита Wi-Fi и паролей в Яндекс.Браузере — это и есть те самые дополнительные средства защиты. О защите открытого Wi-Fi я рассказывал на Хабре в прошлый раз. Браузер автоматически шифрует и пропускает через прокси весь HTTP-трафик, когда пользователь подключается к незащищенной точке.

image

Защита паролей направлена на борьбу с фишингом. Уже известные нам фишинг-сайты достаточно давно блокируются в браузере через SafeBrowsing. Но это не решает проблему в полной мере — новые сайты создаются очень быстро и порой успевают навредить до попадания в черный список. Защита паролей от фишинга — это наш первый «подход к снаряду» в решении проблемы. Суть достаточно простая. Если человек вводит пароль от популярного сайта (например, ВКонтакте) на сторонней странице, то Яндекс.Браузер предупредит его об этом риске (а заодно и заблокирует отправку данных до явного подтверждения). Сами пароли не обязательно хранить в браузере — технология запомнит и будет сравнивать лишь их хэши.



Было бы интересно узнать мнение сообщества. А тем, кто захочет принять участие в конкурсе, желаем удачи в поиске!

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


  1. SergeyGrigorev
    26.10.2015 15:18
    +5

    Мне кажется основная кнопка должна быть «Не входить», чтобы пользователь на автомате не нажал «войти». Достаточно многие привыкли нажимать «далее — далее — далее — получить результат». Поэтому опасные действия должны осознано производиться, где действие по умолчанию — блокировать. Например в Chromium при попытке зайти на сайт с неверным сертификатом, основная кнопка — Back to safety


    1. BarakAdama
      26.10.2015 15:23
      +3

      Спасибо. Согласны с Вами. На скриншоте один из первых вариантов этого диалога. Допиливание этой штуки идет активно.


      1. Lol4t0
        26.10.2015 18:09

        Эта штука весело работает с паролем-по-умолчанию-для-всяких-форумов


        1. BarakAdama
          26.10.2015 18:18
          +2

          Тут важно учесть, что защита по умолчанию работает только для паролей от популярных и критичных сервисов. И если человек использует один и тот же пароль для интернет-банка и для «всяких форумов», то это уже проблема. И мы привлекаем к этой проблеме внимание. Но при этом разрешаем добавить сайт в исключение (кнопка «Я доверяю этому сайту»).


          1. Lol4t0
            26.10.2015 19:27
            +1

            У нас с вами разное отношение к mail.ru, как выяснилось :)


  1. Isis
    26.10.2015 16:08

    Вредоносные расширения живут в вашем браузере по 2 месяца точно. Вы его удаляете, а добавить новое в хром стор это подождать один день модерации.


    1. BarakAdama
      26.10.2015 16:33

      Про 2 месяца хотелось бы посмотреть детальнее пример. Распространяющиеся угрозы мы обычно рубим достаточно быстро. Хотя проблемы с расширениями все равно остаются. Это уже не та «эпидемия», что была в цитируемой истории, но работы все равно хватает.

      Вы правы, модерация в Chrome Web Store сильно упрощает жизнь мошенникам, и мы, к сожалению, никак не это повлиять не можем. Поэтому создаем защиту на своей стороне.


      1. Isis
        26.10.2015 16:59

        Запретить инлайн инсталл и редиректить на стор — the best solution :)


        1. BarakAdama
          26.10.2015 17:41

          К сожалению, инлайны это не единственный «способ доставки».


  1. slashd
    26.10.2015 16:49

    А где можно посмотреть сорцы?


    1. BarakAdama
      26.10.2015 16:54
      +3

      У Браузера закрытый исходный код. Отчасти из-за смежных прав на используемые компоненты. Но при этом мы вполне официально участвуем в проекте Chromium и отправляем туда свои коммиты (чуть подробнее об этом писал тут).


  1. Lockal
    27.10.2015 13:07
    +1

    Проксировать трафик ВК в открытых сетях немного странное решение. Конкретно в этом случае гораздо проще перенаправить на https://vk.com. Встроенный аналог HTTPS Everywhere хотя бы на десяток самых популярных сайтов в разы бы повысил безопасность пользователей.


  1. Igor1024
    31.10.2015 11:07

    То есть платят только если твоя вулна окажется в топ-3 по критичности?
    Как понимаю, вы таким образом щупаете почву — прежде так же открывали баг-баунти для вебарей. Народ заслал вам много вулн, вы оплатили малую их часть. Через год открыли уже полноценную баг-баунти.
    Если я правильно понимаю положение дел — не вижу смысла участвовать в текущей.


    1. BarakAdama
      31.10.2015 12:08

      К моменту запуска постоянного багбаунти текущие уязвимости могут потерять ценность.