Злоумышленники, специализирующиеся на воровстве паролей, номеров банковских карт и прочей личной информации, появились еще в прошлом веке и с тех пор их число только растет. Согласно отчету Лаборатории Касперского, от 9% до 13% их пользователей в России сталкиваются с фишингом. Ежегодно в мире фишинг и другие формы кражи личных данных наносят ущерб в $5 млрд, согласно оценкам Microsoft. Это в целом соответствует нашим наблюдениям и объясняет, почему в любом более-менее популярном браузере есть защита от фишинга, основанная на «черных списках». В Яндекс.Браузере она тоже есть. Казалось бы, зачем изобретать что-то еще?
Safe Browsing
Самое очевидное решение для защиты пользователей – это использование готовой базы со списком фишинг-сайтов. Проверяем по «черному списку» посещаемые страницы и предупреждаем, если нашлось совпадение. На этой идее и основана защита с использованием технологии Safe Browsing, которая работает в Яндекс.Браузере с момента его появления.
Немного о том, как это работает. В Браузере регулярно обновляется список плохих сайтов весом в несколько мегабайт. На самом деле опасных сайтов очень много, а степень сжатия ограничена, поэтому вместо явных адресов локально храним лишь префиксы (т.е. начальная часть) их хэшей. Посещаемые сайты проверяем по локальной базе. Если нашли совпадение, то префикс отправляем на сервер, в ответ получаем полные хэши, перепроверяем, если и здесь совпадение, то показываем предупреждение. Цепочка выглядит длинной, но работает за доли секунды, не плодит запросы и, что наиболее важно, защищает пользователя.
Списки Safe Browsing пополняются с помощью поисковых и антивирусных технологий Яндекса, детали которых раскрывать по понятным причинам не стоит. Однако сторонние разработчики тоже могут воспользоваться результатами в своих продуктах (в том числе в браузерах) с помощью нашего Safe Browsing API.
Защита с помощью списков плохих сайтов (будь то Safe Browsing Яндекса, Гугла или другие аналоги) долгое время была единственным применяемым способом в браузерной индустрии. Проблема в том, что современные фишеры уже не такие медленные, как раньше. Создание сайтов-подделок, их публикация, рассылка спама через социальные сети – все это уже давно автоматизировано. Пока новая фишинг-страница дойдет до полной базы, а затем до легкой локальной она вполне может успеть кому-то навредить. Нам нужно было научиться бороться с проблемой в условиях отсутствия точных знаний.
Защита паролей
Злоумышленники с помощью фишинга активно воруют пароли от банков, платежных систем, социальных сетей и даже админок управления сервером. Как их защитить, если браузер еще не знает, хороший или плохой сайт открыт в нем? Предупреждать при каждом вводе пароля и просить убедиться, что это именно тот самый сайт? Это не просто навязчиво, но и бесполезно в перспективе. Если пользователь 100 раз подтвердит, что перед ним настоящий сайт Сбербанка, а не поддельный, то на 101 раз он просто не станет проверять сайт, который по закону подлости обязательно окажется мошенническим.
К слову, есть распространенное заблуждение, что двухфакторная авторизация на банковских сайтах спасет от кражи денег, даже если человек попался на фишинг. Спасет, конечно, но далеко не всегда. В нашей практике мы сталкивались с примерами опасных сайтов, которые после ввода логина и пароля умели инициировать отправку СМС настоящим банком. Код из СМС пользователь вводил на уже открытой фишинг-странице, и злоумышленники использовали его, получая полный доступ к личному кабинету. Но мы отвлеклись.
Изначально идея была достаточно проста. Нужно присматривать за паролями, уже сохраненными в браузере. Если пользователь вводит пароль на сайте, который явно не совпадает с сайтом из менеджера паролей в браузере, то нужно его остановить и предупредить. Проблема в том, что встроенным менеджером паролей пользуются далеко не все. Даже простые пользователи, которые никогда не слышали о LastPass, KeePass или 1Password, не спешат сохранять свои пароли, нередко предпочитая вводить их по памяти или из блокнота (бумажного, а не из Windows). Причем именно эта категория пользователей наиболее уязвима перед фишингом, а значит, такое простое решение не подходило.
Использовать уже сохраненные пароли не было смысла, но вместо отказа от всей идеи мы научили Браузер самостоятельно запоминать хэши вводимых паролей. Почему хэши? Потому что их вполне достаточно для сравнения паролей, к тому же хранить хэши все же безопаснее. Конечно же, мы дали опцию отключить функцию для тех, кто и хэшам не доверяет. Итак, если пользователь хотя бы раз вошел, например, на настоящий Альфа-Банк, то Браузер предупреждал его при попытке ввода пароля на фишинговых копиях. Казалось бы, можно было идти пить шампанское, но не все так просто.
Память пользователей не подчиняется закону Мура, поэтому многие предпочитают придумать один пароль на все сайты. Это ужасно с точки зрения безопасности, но такова реальность. Если бы мы включили защиту паролей на всех пользователей для всех сайтов, то изобрели бы не только хорошую защиту от фишинга, но и отличный способ распугать аудиторию. Поэтому по умолчанию защита была включена только для наиболее популярных среди мошенников сайтов. Для любого другого ее можно включить вручную.
Эта функция была внедрена примерно год назад, и все это время она не только защищает от фишинга, но и привлекает внимание людей к теме безопасности паролей. Вот только пароли – это не единственный вид конфиденциальных данных, которые любят воровать.
Защита карт
Чтобы украсть деньги, не обязательно воровать пароли от онлайн-банков и продумывать логику с обходом двухфакторной авторизации. Можно просто выкрасть данные банковской карты. Про необязательный 3-D Secure вспоминать тоже не стоит – пользователь и CVV-код не забудет ввести на фишинг-странице. После кражи данных карты остается только придумать, как забрать оттуда деньги. Способы бывают разные. Например, кто-то продает туристам билеты с 50% скидкой, по факту покупая их с украденной карты по полной стоимости. С переменным успехом подобные операции удается вовремя оспорить через свой банк, но лучше до этого не доводить и защищать данные своей банковской карты.
В отличие от защиты паролей, где можно было однозначно контролировать пары «пароль-сайт», банковские карты могут использоваться где угодно. Мы можем контролировать крупные площадки, но длинный хвост онлайн-магазинов все равно не покроем. Да и что вообще значит «контролировать»? Не давать вводить номер карты? Если предупреждать, то о чем? Осознав, что вряд ли на уровне Браузера можно сделать однозначный вывод о плохих намерениях сайта, мы взглянули на ситуацию под другим углом – с точки зрения шифрования.
Наличие SSL-сертификата – обязательное условие для любого сайта, который работает с конфиденциальными данными пользователей, в особенности с банковскими данными. Если ресурс просит ввести номер карты, но не поддерживает защиту и работает по HTTP, то тут возможны сразу две разные проблемы. Во-первых, ваши данные кто-то может перехватить по пути из открытого трафика. Например, через незащищенную Wi-Fi точку в кафе. Во-вторых, владелец такого ресурса как минимум не заботится о безопасности своих посетителей, а, возможно, просто ворует данные. В любом случае, вводить номер карты на таком сайте не стоит. Если проблему с перехватом мы еще как-то решаем с помощью функции защиты Wi-Fi, то от мошенника шифрование канала никак не спасет. Точнее спасет данные от мошенников-перехватчиков и доставит их в целостности мошенникам-фишерам. И вот здесь нужно было что-то делать.
Итак, мы локализовали проблему. Если пользователь заходит на HTTP-сайт, который просит ввести номер банковской карты, то это повод предупредить. Но чтобы показать сообщение, нужно для начала распознать ввод карты. Специальный банковский тип тега input еще никто не придумал, а относительно свежий атрибут для браузерного автозаполнения autocomplete=cc-number мало кто использует. Команда Chromium, конечно, не бросает идею научить браузер самостоятельно подставлять номера карт и даже внедряет эвристику, которая угадывает по названиям полей и некоторым другим данным, но работает это не везде. В общем, анализ полей ввода – не вариант. Но зато мы можем ловить ввод цифр. Например, если пользователь ввел 16 цифр, то можно предположить, что это банковская карта. Проблема в том, что это не всегда так. К счастью, существует алгоритм Луна.
Думаю, многие знают, что последняя цифра в номере карты нужна для проверки корректности всего номера. А саму проверку можно легко провести с помощью алгоритма Луна. Он достаточно простой. В каждой паре цифр номера карты первое число умножаем на 2. Если после умножения число становится больше 9, то нужно сложить составные цифры. А затем все сложить. Если итоговая сумма кратна 10, то перед нами номер банковской карты. С вероятностью ошибки в 10%.
Алгоритм Луна снижает вероятность ложного срабатывания в разы. Но существует дешевый способ снизить ошибку еще немного – контролировать первые цифры в номере. Именно в начале номера закодирована платежная система, поддерживающая карту. Если в начале стоит цифра 4, то это VISA. Что-то из диапазона 51-55 – это MasterCard. 34-37 – это American Express. Аналогично для некоторых других систем. Вероятность ошибки, конечно же, всегда остается, но уже на допустимом уровне.
Мы научили Браузер распознавать ввод определенного количества цифр (от 15 до 19), проверять их по алгоритму Луна и на соответствие кодам известных платежных систем. И все это работает полностью локально – номер карты Браузер никуда не отправляет и не хранит. Если все условия выполняются, то пользователь видит такое предупреждение:
Подобное же сообщение мы показываем и для ряда других опасных ситуаций. Например, если сам сайт защищен HTTPS, но ввод номера происходит в HTTP-фрейме. Или если сертификат сайта не валиден.
Существуют ситуации, для которых в силу широкой распространенности и относительной безопасности не стоит показывать предупреждение, но дать возможностям пользователям разобраться все же надо. Например, если форма ввода номера карты находится во фрейме на другом домене (и сайт, и фрейм при этом HTTPS). Это встречается сплошь и рядом, потому что онлайн-магазинов много, но далеко не все из них способны проработать собственный модуль оплаты, предпочитая встраивать фреймы популярных платежных систем. Или другой пример. Сайт не использует шифрование, но карту принимает через HTTPS-фрейм на своем же домене. Для таких ситуаций Браузер не показывает предупреждение, но добавляет в адресную строку значок карты. Если кликнуть по нему, то можно узнать, кому именно вы доверяете свои данные.
Вся наша вышеописанная защита вертится вокруг наличия SSL-сертификата. Это обоснованно, потому что пользователи в массе своей еще не привыкли обращать внимание на замочек в адресной строке, и у фишеров нет мотивации использовать сертификаты. Но постепенно все меняется. Установить бесплатный сертификат от того же LetsEncrypt уже не проблема. А значит рано или поздно мы вновь вернемся к ситуации, когда защищать как-то надо, но данных на клиенте недостаточно. И чтобы не проиграть фишинг-сайтам в будущем, готовиться мы начали уже сейчас.
Машинное обучение
Любой сайт в интернете обладает совокупностью характеристик, по которым его можно оценить. Например, размер аудитории, время жизни, наличие SSL-сертификата, его надежность или даже уникальность адреса (фишеры любят использовать максимально схожие адреса). И наше с вами доверие к тому или иному сайту во многом определяется именно ими. Опытный пользователь, глядя на неизвестный сайт, может для себя решить, вызывает ли эта площадка доверие. С компьютером все сложнее. Задача определения «подозрительности» сложно поддается формализации и не укладывается в простые алгоритмы. Понятно, что грубая ошибка в HTTPS — это сильный критерий, но я говорю о куда более неочевидных случаях. И здесь без машинного обучения уже не обойтись.
Яндекс применяет машинное обучение не первый год. Наши технологии используются не только внутри компании (Поиск, Музыка, Маркет, Дзен), но и доступны для внешних заказчиков через Yandex Data Factory. Именно машинное обучение позволяет компьютеру демонстрировать поведение, которое в него не было явно заложено. И для нашей задачи –предупреждать пользователей при оплате на подозрительных сайтах – подходит идеально.
Чтобы обучить машину искать подозрительные сайты, мы должны показать ей примеры заведомо плохих сайтов. С этим у нас нет проблем – спасибо технологии Safe Browsing. С другой стороны, мы указываем ей уже упомянутые выше характеристики (факторы), на которые стоит обращать внимание. А уже дальше наш метод машинного обучения Матрикснет учится выводить закономерности и строить формулы, которым можно было бы скормить адрес сайта, а на выходе получить вердикт. Максимально упрощенно это выглядит так:
Среди всех факторов один хотелось бы выделить особенно. Обычные пользователи, которые чаще других становятся жертвами фишинга, ориентируются в первую очередь на внешний вид сайта и далеко не всегда смотрят на его адрес, замочек и прочие детали. Злоумышленники этим и пользуются. Отличительная черта большинства фишинг-сайтов – это копирование оформления популярных ресурсов. Поэтому с помощью технологии компьютерного зрения мы научили машину сравнивать внешний вид страниц с образцами популярных сайтов. Если она находит совпадение, то это сильный сигнал о возможной угрозе.
Результаты работы машинного обучения и компьютерного зрения доступны пользователям Яндекс.Браузера, начиная с версии 16.9.1. Если пользователь вводит на сайте номер карты, то на сервер уходит запрос с указанием страницы. Если есть риск, то пользователь видит предупреждение.
Может показаться странным, что мы показываем именно предупреждение и только в ответ на ввод карты, а не используем сразу при загрузке полноэкранную блокировку. Причина в том, что машина обучается выявлять сайты, на которых есть риск потери денег, и блокировать доступ ко всей информации было бы неправильно. К тому же вероятность ложноположительных вердиктов никогда не равна нулю.
Если вы дочитали до конца, то уже знаете, что с фишингом можно (и нужно) бороться с помощью совершенно разных технологий. К сожалению, далеко не все зависит только от них. Знания и опыт самих пользователей во многом определяют их уязвимость перед злоумышленниками. Но мы верим, что если привлекать внимание к проблеме, рассказывать об угрозах на уровне предупреждений, объяснять средствами Браузера, почему важно использовать разные пароли и не стоит вводить номера карт на сайтах без шифрования, то в конечном счете люди начнут с большей осторожностью относиться к своей работе в сети.
Автор: Яндекс
