Безопасность веб-ресурсов банков России

В нашей компании мы постоянно проводим различные исследования (список), выбирая интересную для нас тему и как итог — представляя общественности pdf с результатами.

Данная статья статья как раз из разряда таких исследований. Проводя работы по анализу защищенности мы приводим обычно очень схожие (общие для всех) советы, которым мало следует, некоторые best practices, которые или просто повышают общий уровень защищенности системы (например — применение CSP), или действительно позволяют предотвратить атаку.

Введение

Как известно, уровень безопасности системы определяется надежностью её самого слабого узла. На практике, после проведения анализа защищенности, основываясь на перечне найденных уязвимостей, выбирается одна брешь или целая цепочка и определяется наиболее проблемное звено. Сразу можно сказать, что зачастую правильно настроенная система может нивелировать риски существующей уязвимости. В ходе исследования мы выяснили, какие потенциальные векторы атак могут быть доступны злоумышленникам. Например, легко ли похитить сессионные данные пользователя при наличии уязвимости межсайтового скриптинга. Также нам было интересно посмотреть, насколько просто реализовать фишинговую атаку на пользователей банка. Пройдясь по этим пунктам и условно проставив “галочки”, злоумышленник может выстроить векторы дальнейших атак на банк и его пользователей.

Цель исследования

Начиная это исследование мы ставили в свои задачи выяснить, как топ 100 банков России обеспечивают свою безопасность, применяя лучшие практики, как это делают самые популярные сайты в интернете. Главной целью данного исследования является оценка уровня безопасности публично доступных банковских ресурсов: официального сайта, ДБО для физических и юридических лиц в соответствии с лучшими практиками по настройке веб-ресурсов. В рамках исследования мы никак не вмешивались в работу банков, все данные были собраны подобно обычному посещению пользователя (несколько HTTP, SSL, DNS запросов). Вся проанализированная нами информация находится в открытом доступе, и манипуляции с этими данными не требуют серьезных навыков и сложных схем. Иными словами, мы решили показать, что при желании и усердии к подобным результатам может прийти любой заинтересованный пользователь.

Тестирование

Для тестирования мы взяли ТОП-100 банков России, определенных по ключевым показателям. С полным списком можно ознакомиться, пройдя по ссылке: http://www.banki.ru/banks/ratings/ (актуальные данные на август 2015 г.).

Сначала определили все официальные сайты и интернет-ресурсы ДБО для физических и юридических лиц. Далее, для каждого банка были проведены проверки, осуществленные несколькими стандартными запросами (по протоколам HTTP/HTTPS/DNS), схожими с обычными запросами от клиентов банка. Каждая проверка проводилась для официального сайта, а также для ДБО для юридических и физических лиц. Исходные данные:

• Официальные сайты — 100 шт.
• ДБО для физлиц — 96 шт.
• ДБО для юрлиц — 81 шт.

Объяснить то, что ДБО меньше, можно просто — не все банки имеют ДБО для физлиц и/или юрлиц.
Чтобы сравнить полученные результаты, было решено осуществить аналогичные манипуляции с популярными сайтами, представленными ниже:

• wikipedia.org
• facebook.com
• twitter.com
• youtube.com
• linkedin.com
• yahoo.com
• yandex.ru
• amazon.com
• vk.com

В статье будут приведены описание и результаты только некоторых проверок, с полным текстом исследования можно ознакомиться по следующей ссылке:
http://dsec.ru/ipm-research-center/research/safety_web_resources_of_banks_of_russia/

HTTP-заголовки

Заголовки в ответе веб-сервера позволяют определить поведение браузера в тех или иных ситуациях. В том числе, их наличие помогает избежать некоторых атак или усложнить их проведение. При этом, добавление заголовка не требует каких-либо сложных действий или настроек. Однако, некоторые настройки (например, CSP) отличает слишком большое количество настроек, некорректное использование которых может как создать иллюзию безопасности, так и вовсе повредить некоторый функционал сайта.

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

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

X-Frame-Options

Заголовок X-Frame-Options разрешает или запрещает отображение страницы, если она открыта во фрейме.
У заголовка может быть три значения:

1. Рендеринг документа, при открытии во фрейме возможен только с того же домена.
2. Рендеринг документа внутри фрейма запрещён.
3. Разрешает рендеринг, если внешний документ с определенного origin. Например, Twitter разрешает показывать свой сайт только на своём домене.

Данный заголовок позволяет защититься средствами браузера от атаки «Clickjacking». Суть её очень проста — фактически пользователь на сайте нажимает на один элемент страницы, а в действительности нажатие происходит на другой.

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

В контексте ДБО это может привести к тому, что пользователь сделает какой-либо «быстрый» платеж, который обычно не требует подтверждений — например оплаты телефона.

Рассмотрим полученные результаты:

• ДБО для юридических лиц — используют 33%
• ДБО для физических лиц — применяют 27%
• Официальный сайт — в наличии у 14%

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

Server header

Данный заголовок сообщает, на каком ПО работает веб-сервер и может иметь следующее значение (для примера):
Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l
Раскрытие данной информации не несет прямой угрозы, но может сократить время у злоумышленника при проведении атак. Вместо того, чтобы проверять ту или иную уязвимость, можно сразу начать искать какие-нибудь данные по определенной версии ПО.

• ДБО для юрлиц — 93%
• ДБО для физлиц — 89%
• Официальный сайт — 95%

SSL

Одним из самых важных пунктов является проверка настроек SSL, поскольку этот криптографический протокол сегодня — самый популярный метод обеспечения защищенного обмена данными через Интернет. Среди основных потенциальных угроз здесь стоит отметить использование атак по перехвату трафика (без подмены сертификата), раскрытие оперативной памяти (атака Heartbleed) и многое другое.

Для осуществления SSL-соединения необходимо, чтобы сервер имел инсталлированный цифровой сертификат. С его помощью возможно подтвердить подлинность домена и проверить, кто является владельцем сайта. Это важно для того, чтобы пользователи посещали нужные им ресурсы, а не фейковые страницы злоумышленников.

Немаловажная функция — шифрование интернет-соединения, необходимое для предотвращения возможного хищения конфиденциальных данных при их передаче в Сети. Эта опция может значительно усложнить задачу злоумышленникам. Допустим, пользователь подключился к открытой сети WiFi и с помощью мобильного банка или веб-браузера решил оплатить покупки или пополнить баланс счета. Между клиентом и ДБО установится SSL-соединение и произойдет передача данных в зашифрованном виде. Злоумышленник, даже если перехватит эти данные, должен будет расшифровать их, что займет у него многие годы.

Предположим, что в системе ДБО, к которой подсоединяется пользователь, не используется SSL, и весь трафик “ходит” в открытом виде. Что тогда может произойти? Злоумышленник, находящийся в той же сети, будет просто “прослушивать” трафик, и получит возможность перехватывать или подменять данные (используя активные методы — MiTM), чтобы похитить денежные средства пользователей или получить доступ к их аккаунтам. А если на сервере присутствует уязвимость Heartbleed, то злоумышленник сможет получить доступ к данным пользователей, которые находятся в оперативной памяти сервера.

Были выбраны следующие проверки:

Рейтинг

SSL имеет большое количество настроек и особенностей, которые в той или иной мере влияют на безопасность как самого соединения, так и его участников в целом. Используя эту информацию, можно провести общую оценку данной настройки. Для этого мы использовали функционал, предоставляемый Qualys . Он позволяет на основе многочисленных параметров создать общий рейтинг от A до F (или более привычный аналог — от 5 до 2). Соответственно 5+ — это лучший результат, который может быть достигнут с точки зрения защищенности. Очень немногие компании (даже крупнейшие интернет-корпорации) имеют его. Наихудший же результат, можно получить, если сервер подвержен какой-либо критичной уязвимости, поддерживает устаревшие протоколы и обладает иными проблемами.

Какие результаты были получены:

В качестве сравнения, так же были получены результаты для сайтов из top alexa

Таким образом, средняя оценка — 4+. Оценки 4 у топа можно объяснить большим количеством пользователей (сравнительно меньшим, чем у банков), часть из которых не имеет возможности обновить свои устройства (например — Windows XP). Примерно так же обстоят дела и с системами ДБО для физических лиц. Уровень защищенности официальных сайтов и ДБО для юридических лиц с точки зрения настроек SSL ниже чем у популярных сайтов.

Heartbleed

Heartbleed — одна из самых известных уязвимостей последнего десятилетия. Информация о ней была опубликована в апреле 2014 года, ошибка существовала с конца 2011 года. Если описать ее в нескольких предложениях, получим следующее. Это ошибка (переполнение буфера) в криптографическом программном обеспечении OpenSSL, позволяющая несанкционированно читать память на сервере или на клиенте, в том числе, для извлечения закрытого ключа сервера. Сервер не проверяет корректность некоторых запросов, поступающих от клиентов. Установив соединение, клиент периодически обращается к серверу с просьбой подтвердить, что соединение еще не разорвано. В ответ сервер должен вернуть некоторый небольшой объем данных, причем количество их определяет сам клиент. Так вот, если клиент запросит больше данных, чем отправил, его запрос все равно будет выполнен и сервер пришлет ему кусок из оперативной памяти. Размер ограничен 64 Кбайт, но ведь можно послать много запросов. Тем самым, количество переходит в качество — посылая сотни, тысячи запросов, можно читать большие блоки данных. Таким образом, сложных методов для эксплуатации данной ошибки не требуется. Если сервер ДБО уязвим к Heartbleed, злоумышленник может получить доступ к критичным данным в считанные минуты. Посмотрим, сколько участников предоставляют такую возможность.

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

• ДБО для юридических лиц — используют 0%
• ДБО для физических лиц — применяют 0%
• Официальный сайт — в наличии у 2%

Используя эту уязвимость, можно также получить приватный сертификат, который реально использовать в MitM атаках. И если для официального сайта и для ДБО используется один и тот же сертификат (или просто Wildcard), то это даст провести атаку даже на защищенное HTTPS соединение.

Проверка доменов

Чтобы злоумышленнику получить доступ к конфиденциальной информации или в КИС, необязательно пытаться обойти техническую защиту периметра, искать “бреши в файерволах” и т.п. Одним из самых действенных способов является рассылка сотрудникам/клиентам писем с предложением открыть резюме или протестировать новый сервис банка, например. Конечно, успех подобного предприятия зависит от истории, содержания текстов и дальнейших действий со стороны жертв, но в упрощенном виде реализация этого сценария такова: злоумышленник подбирает список сотрудников, отправляет им письма с официальными ссылками, “правильными” доменными именами. Далее, жертвы проходят по ссылке якобы на стандартные страницы сайта банка (на самом деле — подмененные). Для успешной атаки нужно зарегистрировать доменное имя, которые бы максимально было похоже на имя банка, например.

После того как пользователь попадает на поддельную страницу, мошенники пытаются побудить его ввести логин и пароль, которые он использует для доступа к определённому сайту. Если это происходит, злоумышленники получают доступ к аккаунтам и банковским счетам жертвы.

Фишинг — одна из разновидностей социальной инженерии, основанная на незнании пользователями основ сетевой безопасности: в частности, многие не в курсе, что официальные сервисы не рассылают писем с просьбами сообщить свои учётные данные, пароль и прочее.

В качестве примера возьмем вымышленное название банка (rusomebank, РуСамБанк), которые будет иметь сайт — rusomebank.ru. Вот так это будет выглядеть в браузере.

Злоумышленники могут подделать доменные имена, создав похожие следующим образом:

• В домене РФ, например, вместо somebank.ru — самбанк.рф.
• Использовать доменные зоны org, com и net.
• Задействовать омоглифы — графически одинаковые или похожие друг на друга знаки, имеющие разное значение. Например, у латинская буква l может быть заменена цифрой 1.
• С использованием удвоенных символов.
• Взять поддомен с похожим именем. Если ДБО располагается на поддомене, возможно зарегистрировать домен, в котором точка (между поддоменом и доменом) будет заменена на тире.

В качестве проверки поддоменов, можно порекомендовать dnstwist, который помимо того, что проверяет доступность доменов, еще сравнивает похожесть сайтов, чтобы определить является ли сайт фишинговым или нет.

Омоглифы

Омоглифы — это графически одинаковые или похожие друг на друга знаки, имеющие разное значение. Заглавную букву О и число 0 легко можно перепутать. Омоглифы могут появляться при использовании разных алфавитов. В ходе проверки была использована следующая таблица:

Используя эти данные, для доменного имени rusomebank.ru можем получить следующие результаты:

• rus0mebank.ru
• rusornbank.ru
• rusomedank.ru

Адресная строка, которая содержит омоглиф, будет выглядеть следующим образом:

Во время проверки заменялся только один символ, то есть вариации как rus0rnedank.ru — не тестировались. Результаты того, сколько банковских доменов имеют ресурс, который содержит омоглиф и который можно зарегистрировать:

• Официальный сайт: 71%
• ДБО для физлиц: 67%
• ДБО для юрлиц: 68%

И только 14% банков не позволяют зарегистрировать домен с омоглифом. Нельзя сказать, что это хороший показатель, поскольку в большинстве своем доменные их доменные имена не очень длинные.

Передача зоны DNS

AXFR — вид транзакции DNS, который позволяет осуществлять репликацию баз DNS между серверами. По факту это такой же запрос, как и любой другой, например для того чтобы узнать IP адрес сайта. Может быть выполнен анонимно.
Но часто можно встретить ошибку в настройке DNS серверов, когда на данный запрос приходит ответ без каких-либо ограничений. Это позволяет раскрыть всю зону (все записи) домена, в том числе приватные данные. Такими могут быть домены для внутреннего пользования, например как трекер задач, внутренние порталы или адрес АБС.Зачем это вообще может быть нужно? Зачастую основные сайты компаний очень хорошо защищены и найти на них серьезную уязвимость не представляется тривиальной задачей. Однако, как говорится «Цепь настолько сильна, насколько сильно ее самое слабое звено». На некоторых поддоменах иногда можно найти тестовые версии сайтов, бекапы и многое другое. Некоторые довольно крупные компании были взломаны подобным образом, из-за того, что на каком-то поддомене оставались скрипты тестирования.

В данной проверке важно проверять все DNS серверы, которые обслуживают домен, а не только тот, который задан первым. Встречаются случаи, когда домен обслуживает собственный DNS сервер и сервер компании-партнера, который настроен с ошибкой.

Результат: для 17 банков можно раскрыть всю зону домена и получить доступ ко всем записям.

Выводы

К сожалению, результаты исследования показали, что применение очевидных приемов (которые не так затратны с точки зрения и финансовых ресурсов, и технических) для повышения уровня защищенности не очень популярно среди участников исследования.

Например, только 5 участников не позволяют зарегистрировать домен с использованием омоглифов, перестановок, повторений и смены доменной зоны, что говорит о широких возможностях для проведения фишинговых компаний злоумышленникам. Справедливости ради стоит отметить, что доменные имена данных участников являются короткими, что, по сути, не дает вариативности в проверках. Не удастся зарегистрировать домен в зоне .com/.net/.org/.рф всего для 25 участников. Если у участника есть ДБО на поддомене то можно зарегистрировать домен как поддомен для всех участников.

Было неожиданным, что для 17 участников можно извне отправить AXFR запрос на DNS сервер и раскрыть все записи для домена банка, через которые чаще всего можно определить инфраструктуру, внутренние ресурсы, адреса значимых серверов (например — АБС).

Также было обнаружено, что у двух банков на официальном сайте веб сервер уязвим к атаке Heartbleed. В случае, если для официального сайта и для системы ДБО используется wildcard сертификат (или просто одинаковый, выписанный для этих доменов), это позволит злоумышленнику похитить приватный ключ SSL и в при проведении атаки “человек посередине” позволит прослушивать и изменять трафик, данные для проведения транзакции в ДБО, и как следствие привести к хищению денег со счетов клиентов.

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

С полным текстом исследования можно ознакомиться по следующей ссылке:
http://dsec.ru/ipm-research-center/research/safety_web_resources_of_banks_of_russia/

Автор: Digital Security

Источник