Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Безопасность мобильного банкинга: возможность реализации атаки "MitM"

(Голосов: 3, Рейтинг: 5)
Количество просмотров 1869 просмотров
Digital Security объявляет результаты нового исследования «Безопасность мобильного банкинга: возможность реализации атаки MitM (Man-in-the Middle, Человек посередине)», автором которого является Дмитрий Евдокимов, директор исследовательского центра Digital Security.

1.png



Введение

В прошлом году мы постарались систематизировать сферу мобильного банкинга и подход к оценке его безопас­ности, а также провели статический анализ около 40 приложений для iOS и Android.

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

Возможности дистанционного банковского обслуживания физических лиц среди топ-200 российских розничных банков (2014 год)

2.png

3.png

Рассматривались приложения для мобильного банкинга (МБ) с платежным функционалом от следующих банков:

Infin Bank

QBank (Связной Банк)

Автоградбанк

Актив Банк

Алмазэргиэнбанк

Альфа-Банк

Банк «2Т»

Банк «Авангард»

Банк «Балтика»

Банк «БКФ»

Банк «БФА»

Банк «Веста»

Банк «Возрождение»

Банк«Долинск»

Банк «Европлан»

Банк«Зенит»

Банк «Кузнецкий»

Банк «МБА-Москва»

Банк «Москва»

Банк «Народный кредит»

Банк «Нейва»

Банк «Первомайский»

Банк «Санкт-Петербург»

Банк на Красных Воротах Банк24.ру

Бинбанк

Военно-Промышленный Банк

Восточный Экспресс Банк

ВТБ

ВТБ24

Вятка-банк

Газпромбанк

Живаго-Банк

Запсибкомбанк

Инвестбанк

Интерактивный Банк

Крайинвестбанк

Кредит Урал Банк

КС Банк

Лайф-Мобайл

МДМ-Банк

МИнБ

Московский Кредитный Банк

МПСБ

МТС-Банк

Новокузнецкий Муниципальный Банк

НОМОС-Банк

Первобанк

Примсоцбанк

Приорбанк

Пробизнесбанк

Промсвязьбанк

РайффайзенБанк

Рокетбанк

Росбанк

РосЕвроБанк

РосИнтерБанк

РСХБ

Русский Стандарт Банк

РусСлавБанк

Сбербанк

Связь-Банк

СДМ-Банк

СИАБ

Ситибанк

Смоленский Банк

Собинбанк

Солид Банк

Татфондбанк

Тинькофф Мобильный Кошелек

УБРиР

Уралсиб

ФБИиР

Ханты-Мансийский Банк

Челябинвестбанк

Экопромбанк

Экспобанк

ЮниКредит Банк

Данное исследование, в первую очередь, направлено на повышение осведомленности пользователей, информирование сотрудников СБ банков, улучшение квалификации разработчиков в сфере ИБ.

Атака “MitM”: сценарии и последствия

По сравнению с прошлогодним исследованием, текущее претерпело значительные концептуальные изменения.

Вместо поиска большого количества типов уязвимостей будет рассмотрена лишь одна — недостаточная защита транспортного уровня или ее отсутствие. В "OWASP Mobile Security Project — Top Ten Mobile Risks" эта проблема занимает 3-е место. Эту опаснейшую атаку особенно легко провести именно на мобильном устройстве. Поэтому данная проблема чрезвычайно важна и требует быстрого решения.

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

В ходе исследования будет рассмотрена и оценена защищенность российских МБ от атаки типа «человек посередине», MitM. Проверка возможности реализации данной атаки выбрана не случайно: при контролировании канала передачи данных между приложением мобильного банкинга и сервером злоумышленник может украсть деньги со счета клиента, то есть нанести прямой финансовый ущерб.

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

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

В рамках данного исследования рассматри­вается ситуация, когда устройство пользова­теля не имеет ни jailbreak, ни root-доступа. При наличии jailbreak или root-доступа уро­вень безопасности снижается на порядок, появляется еще больше векторов атаки, в том числе, нацеленных на кражу денег. Также наше «идеальное» устройство не заражено никаки­ми вредоносными программами, ворующими средства (типа ZitMo (ZeuS-in-the-Mobile), SpitMo (SpyEye-in-the-Mobile)). Это верно везде, где не сказано обратное.

4.png

Основные сценарии реализации атаки “MitM”

· Подключение пользователя к поддельной Wi-Fi-точке доступа

Это самый распространенный и реальный сценарий MitM-атаки. Может быть легко воспроизведен в кафе, торговом или бизнес-центре.

· Подключение к поддельной базовой станции оператора

Эта схема становится все более доступной для широких масс благодаря широкому выбору аппаратного и программного обеспечения и его низкой стоимости.

Ситуацию необходимо взять под контроль как можно оперативнее.

· Использование зараженного сетевого оборудования

Под заражением сетевого оборудования понимается не только исполнение на нем вредоносного кода, но и его целенаправленное злонаме­ренное переконфигурирование, например, через уязвимость.

Уже известно немало примеров реализации подобных атак.


Специфика работы мобильных устройств с Wi-Fi-сетями

· Автоматическое подсоединение к известным Wi-Fi-сетям (на основе PNL, Preferred Network List).

· Не везде можно отключить или сконфигурировать каким-либо простым способом

· Если известных сетей несколько, то выбор подключения у каждой ОС свой

· Идентификация сети происходит на основании SSID (имени сети) и настроек безопасности

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

Такая схема и отсутствие простого управления доверенными сетями упрощает реализацию "MitM" для злоумышленника.

Возможные последствия "MitM"

· Кража денежных средств со счетов клиента

· Раскрытие информации о счетах клиента и его прошлых операциях

· Просмотр данных о текущей операции клиента

· Отказ в обслуживании клиента

Как защитить канал связи

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

Каналы можно разделить на 3 основные группы:

Находясь в одной сети с жертвой, злоумышленник видит все клиент-серверное взаимодействие в открытом виде

Как показывает наша практика, это не лучшее решение: оно приводит к ряду ошибок, которые ведут к компромета­ции передаваемых данных

Самый распространенный вариант — SSL/TLS

SSL (Secure Sockets Layer) — общепринятый стандарт безопасного обмена сообщениями через Интернет. Безопасность SSL-соединения при защите от злоумышленника, активно атакующего из Сети, зависит от корректности проверки сертификатов общедоступных ключей, отправляемых при установлении соединения.

Основная цель SSL — защитить собеседников от «человека посередине».

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

SSL-соединение начинается с т. н. «рукопожатия» между клиентом и сервером.

SSL-рукопожатие

7.png

В SSL [1] все взаимодействие основывается на паре «открытый и закрытый ключ» сертификата сервера, и важным условием является то, что сертификат действителен. Это означает, что сертификат должен быть:

· подписан одним из доверенных CA;

· не истекшим;

· не отозванным;

· имя/имена, перечисленные в списке соответс­твия сертификата(ов), и название домена, к кото­рому подключается клиент, совпадают.

Цепочка сертификатов

version

version

version

serial no.

serial no.

serial no.

singing algo.

singing algo.

singing algo.

issuer name: Enterprise CA

issuer name: Root CA

issuer name: Root CA

validate period

validate period

validate period

subject name: www.enterprise.com

subject name: Enterprise CA

subject name: Root CA

extentions

extentions

extentions

basic constraint CA bit: 0

basic constraint CA bit: 1, parthlen: 0

basic constraint CA bit: 1

key usage: keyEncipherment

name constraint *.enterprise.com

key usage: keyCertSign

other extentions

key usage: keyCertSign

other extentions

other extentions

Конечный сертификат

Сертификат промежуточного CA

Сертификат корневого CA

Для обеспечения работоспособности данной схемы на устройстве находится много корневых сертификатов (CA), которые хранятся в специальном хранилище доверенных корневых сертификатов, и все, что ими подписано, является доверенным для устройства.

Проверка сертификатов идет по цепочке: от присланного на устройство до корневого (CA), кото­рому доверяет устройство. Далее [2] идут проверки имени хоста, отозванности и т. д.

Сертификаты разделяются на системные (предуста­новлены в систему) и пользовательские (установ­лены пользователем).

8.png


SSL и Android

Просмотр сертификатов на Android

В ОС Android до версии 4.0 все сертификаты хранились в едином файле — Bouncy Castle Keystore File.

Изменить его без root-привилегий было невозможно, и ОС не предоставляла никаких способов его модификации.

Любое изменение сертификата (добавление, отзыв) требовало обновления ОС.

/system/etc/security/cacerts.bks

Начиная с версии Android 4.0, подход к работе с сертификатами изменился. Теперь все сертификаты хранятся отдельными файлами, и при необходимости можно удалять их из доверенных.

/system/etc/security/cacerts

/data/misc/keychain/cacerts-added

Распространенность версий Android

9.png

По данным сайта Android Developers, 1 мая 2014


Версия

Кодовое имя

API

Количество %

2.2

Froyo

8

1.0

2.3.3 - 2.3.7

Gingerbread

10

16.2

3.2

Honeycomb

13

0.1

4.0.3 - 4.0.4

Ice Cream Sandwich

15

13.4

4.1.x

16

33.5

4.2.x

Jelly Bean

17

18.8

4.x

18

8.5

4.3

KitKat

19

8.5

Установка сертификатов на Android

10.png

Для установки пользовательского сертификата в ОС Android необходимо загрузить корневой сертификат на SD-карту и зайти в меню Настройки -> Безопасность -> Установить с карты памяти или, в новых версиях, воспользоваться MDM (DevicePolicy- Manager).

С помощью социальной инженерии это сделать можно, но не очень просто.

Для просмотра сертификатов в ОС Android необхо­димо зайти в меню Настройки -> Безопасность -> Надежные сертификаты (Settings -> Security -> Trusted credentials).

Количество системных сертификатов в различных версиях Android

11.png

Количество сертификатов также может меняться от производителя к производителю и для каждой модели устройства.

SSL и iOS

Просмотр сертификатов на iOS

В ОС iOS посмотреть встроенные сертификаты нельзя, и получить информацию о них можно только с сайта компании Apple. Для просмотра пользовательских сертификатов необходимо зайти в меню Настройки -> Основные -> Профиль(и).

/System/Library/Frameworks/Security.framework/certsTable.data

/private/var/Keychains/TrustStore.sqlite3

В ОС iOS существует несколько путей установки пользовательских сертификатов:

· Через браузер Safari — необходимо зайти по ссылке, на которой лежит сертификат с расши­рением .pem или профиль конфигурации с расширением .profile;

· Через присоединение сертификата к E-mail;

· Через MDM API.

Видно, что провести установку пользовательского сертификата через социальную инженерию на iOS намного проще, чем на Android.

Количество системных сертификатов в различных версиях iOS

12.png

Возможные векторы установки сертификатов через социальную инженерию:

· Пользователь делает все сам из-за неосведомлен­ности

· Приобретается подержанный телефон со встроен­ным вредоносным сертификатом

· Сертификат устанавливается на телефон с iOS за несколько секунд, если оказывается случайно в руках злоумышленника (например, он попросил позвонить)

· Сертификат устанавливается принудительно для дос­тупа к бесплатной точке Wi-Fi

Установка сертификата

13.png

Просмотр сертификата

14.png

К чему ведут ошибки защиты канала

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

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

Отсутствие HTTPS (SSL)

Как бы удивительно это ни звучало, еще год назад мы встречали приложения для мобильного банкинга, в которых все общение, включая финансовые операции, происходило по HTTP-протоколу: аутентификация, данные о переводах, — все было в открытом виде. Это значит, что злоумышленнику для получения финансовой выгоды необходимо было просто находиться с жертвой в одной сети и обладать минимальной квалификацией. Тогда для успешной атаки было достаточно исправлять номера счетов назначения и, при желании, суммы.

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

· С новостями банка

· С расположением банкоматов

· С курсом валют С социальными сетями

· Со статистикой программы для разработчиков

· С рекламой

В лучшем случае, злоумышленник может просто дезинформировать жертву, а в худшем — внедрить собственный код, который выполнится на устройстве жертвы, что в дальнейшем поможет похитить аутентификационные данные или деньги. Причина в том, что ОС Android позволяет подгружать код из Интернета, а затем выполнять его. Такой код злоумышленник может при определенных обстоятельствах внедрить в открытый канал.

Собственное шифрование

Данный вариант нам также встречался как на прак­тике, так и в процессе исследования. Использование его нам непонятно, но, по нашим предположениям, оно может быть связано с устоявшимися внутренними процессами банка. При этом трафик в SSL допол­нительно разработчиком не заворачивается.

Как показывает наша практика, использование собственного шифрования до добра не доводит. Порой это даже не шифрование, а просто свой бинарный протокол, который на первый взгляд кажется непонятным, зашифрованным.

Некорректное использование SSL

Самый распространенный класс ошибок — это некорректное использование SSL. Чаще всего оно связано со следующими причинами:

Невнимательность разработчика

В процессе разработки используется различный тестовый код для ускорения процесса тестиро­вания. И перед выпуском программы про этот код забывают.

Ошибки разработчика

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

Отсутствие тестовой инфраструктуры у заказчика

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

Основные ошибки при работе с SSL

· Отключение проверок (отладочное API)

· Некорректное переопределение стандартных обработчиков на собственные

· Неправильная конфигурация API-вызовов

· Слабые параметры шифрования

· Использование уязвимой версии библиотеки

· Неправильная обработка результатов вызовов

· Отсутствие проверки на имя хоста или исполь­зование неправильных регулярных выражений для проверки


Компрометация корневого сертификата

При использовании SSL существует зависимость от корневых сертификатов. Нельзя исключать возможность их компрометации — вспомним, к примеру, последние инциденты с Bit9, DigiNator и Comodo. Не стоит забывать и о сертификатах других стран, компаний, для которых трафик, можно сказать, является открытым.

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

Если CA-сертификат скомпрометирован:

1. Пользователь может удалить сертификат из доверенных.

В ОС Android пользователь может это сделать как со встроенными сертифика­тами, так и с пользовательскими.

В iOS пользователь может удалить только пользовательские сертификаты.

2. Разработчик ОС может выпустить обновление.

3. Издатель сертификата может отозвать свой сертификат. Механизм проверки сертификата может динамически проверить это (например, OCSP, "Online Certificate Status Protocol").

Android не поддерживает ни CRL, ни OCSP

iOS использует OCSP

Надеяться на то, что пользователь сам будет управлять корневыми сертификатами, сложно. Так что единственный путь — это ждать обновления ОС. Пользователь в промежуток времени между компрометацией и обновлением системы уязвим.

CA-сертификаты бывают разных типов — точнее, могут служить для разных целей (шифрования почты, подписи кода и т. д.), но они, как правило, хранятся в одном безопасном хранилище и могут использоваться для проверки доверия к HTTPS- соединению. К сожалению, корректная проверка назначения сертификата не везде реализована. Таким образом, злоумышленник может получить легитимный сертификат от выпускающего центра для одних целей, а использовать для установки HTTPS- соединения в процессе MitM-атаки.

Кроме того, когда пользователь работает в браузере, он может заметить работу с подозрительным сертификатом по красному значку замочка в строке адреса. В такой же ситуации при работе через приложение пользователь никак не будет информирован, если разработчик этого не предусмотрел заранее, что делает атаку скрытной.

Дополнительные средства защиты канала

Помимо грамотного и повсеместного использования SSL мы можем порекомендовать еще несколько механизмов для повышения уровня безопасности канала.

SSL Pinning

В качестве защиты от компрометации корневых системных сертификатов и специально встроенных пользовательских можно использовать подход SSL Pinning.

Pinning — это процесс ассоциации хоста с его ожидаемым Х509-сертификатом или публичным ключом. Подход заключается во встраивании сертификата или публичного ключа, которому мы доверяем при взаимодействии с сервером, прямо в приложение и отказе от использования встроенного хранилища сертификатов. В итоге, при работе с нашим сервером приложение будет проверять действительность сертификата только на основании криптографического примитива, прошитого в нем.

Приложения для МБ отлично подходят для использования SSL Pinning, так как разработчики точно знают, к каким серверам будет подключаться приложение, и список таких серверов мал.

SSL Pinning бывает двух типов:

Certificate pinning

· Простота реализации

· Низкая гибкость подхода

Public key pinning

· Проблемы с реализацией на некоторых платформах

· Хорошая гибкость подхода

Преимуществом также является возможность использовать:

· Self-Signed сертификаты;

· Private CA-Issued сертификаты.

Для реализации SSL Pinning необходимо пере­определить некоторые стандартные функции и написать собственные обработчики. Стоит отметить, что SSL Pinning не получится реализовать в случае использования WebView в Android и UlWebView в iOS в связи с их спецификой.

Механизм работы SSL Pinning

15.png

App1 для проверки действительности сертификата будет использовать только вшитый сертификат или публичный ключ.

App2 для проверки действительности сертификата пойдет в системное хранилище сертификатов, где последовательно пройдет по всем сертификатам.


Применение SSL Pinning в наши дни

Впервые технология широко распространилась в Chrome 13 для сервисов Google. Далее были Twitter, Cards.io и т. д.

Сейчас уже все магазины мобильных приложений (Google Play, App Store, WindowsPhone Market) используют данный подход для работы со своими устройствами.

К примеру, компания Apple вшивает отпечаток сертификата "Apple Root CA" в устройство для проверки подписи запускаемых на нем приложений, в связи с чем нельзя запустить на iOS-устройстве (без jailbreak) приложение, не проверенное/подписанное Apple (исключение — Ad-Hoc-приложения).

Код для реализации SSL Pinning уже сейчас можно найти на сайте OWASP для Android, iOS и .NET. Начиная с Android 4.2, SSL Pinning поддерживается на системном уровне.

Обход SSL Pinning

SSL Pinning можно обойти/отключить, если на мобильном устройстве присутствует jailbreak или root-доступ. Как правило, это нужно только исследователям для анализа сетевого трафика. Для отключения на Android есть программа Android SSL Bypass, для iOS - программы iOS SSL Kill Switch и TrustMe.

По идее, эти же подходы могут использовать и вредоносные программы.

Как и любой код, проверки при SSL Pinning могут быть реализованы некорректно, и на это стоит обращать внимание.


Двухфакторная аутентификация

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

Вход в систему

· Фактор знания

Пароль/РШ-код/...

· Вещественный фактор

Аппаратный ключ/...

· Биометрический фактор

Голос/Сетчатка глаза/Почерк/...

· Ситуативный фактор

Местоположение/Движение/...

В МБ встречаются следующие механизмы:


Таблица одноразовых ключей

Принцип работы: есть таблица кодов, которые надо вводить по мере совершения платежных операций.

Проблема: как правило, коды в таблице никак не привязаны к деталям операции (например, сумме) и передаются именно по тому каналу, который и контролирует злоумышленник в MitM-атаке. Не защищает от проведения злоумышленником операций, не требующих кодов подтверждения, например, запроса состояния счетов.

Рекомендация: использовать несколько таблиц кодов подтверждений, где каждая таблица соответствует определенному лимиту перевода денег. Например, одна таблица для операций ниже 1000 р., а другая — свыше 1000 р. Данный подход ограничит злоумышленника работой в рамках определенного денежного лимита, но не предотвратит кражу средств. Наилучшим решением является отправка кода подтверждения по другому каналу передачи данных с привязкой к деталям операции.

SMS

Принцип работы: код подтверждения операции присылается клиенту, как правило, на это же мобильное устройство в SMS-сообщении. Код подтверждения вводится в приложение МБ и передается на сервер.

Проблема: как правило, передается приложением МБ по тому же каналу, который контролирует злоумышленник в MitM-атаке. Не защищает от проведения злоумышленником операций, не требующих кодов подтверждения, например, запроса о состоянии счетов. Также, если на мобильном устройстве функционирует вредоносное ПО, оно может перехватить код подтверждения.

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

Специальное мобильное приложение (иногда является частью приложения для МБ)

Принцип работы (описан на основе приложения MobiPass): приложение предназначено для само­стоятельного формирования клиентом одноразовых ключей. Для активации приложения пользователь вводит 32-значный секретный код, предоставленный банком, 28 цифр кода используются для инициализации системы, а 4 являются контрольной суммой. В дальнейшем для генерации кода подтверждения пользователь должен лишь ввести PIN приложения и код операции, для которой нужно вычислить подтверждения. MobiPass основана на открытом стандарте "Open Authentication", и в основе лежит алгоритм RFC-4226 "HOTP: An HMAC- Based One-Time Password Algorithm". Данный подход сейчас становится популярным у банков в связи с повышением цен операторов на отправку SMS.

Проблема: не добавляет никакой защиты от "MitM", так как одноразовый ключ передается по тому же каналу, который контролирует злоумышленник. При этом вычисление кода завязано только на кодовом числе документа, и его детали (сумма, место назначения) никак не учитываются при вводе в программу. В самом приложении могут быть уязвимости и атаки со стороны вредоносного ПО. При компрометации секретного ключа злоумышленник способен самостоятельно генерировать одноразовые ключи.

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

Биометрическая аутентификация

Принцип работы: используется микрофон для распознавания голоса, тачскрин для росписи, камера для определения овала лица, сетчатки глаза. Биометрические данные считываются и передаются на сервер.

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

Рекомендация: для повышения точности использовать специализированные датчики.

Аппаратный генератор кодов подтверждений

Принцип работы: отдельное устройство для генерации кодов. Как правило, представляет собой небольшое устройство с дисплеем. Основным преимуществом является то, что даже если мобильное устройство заражено (но не имеет jail- break или root-доступа), то вредоносное ПО не узнает код подтверждения.

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

Рекомендация: важно, чтобы в этом же сообщении содержалась информация о переводе (сумма, адре­сат). Но возможна невнимательность пользователя.

Не стоит забывать, что недостатки реализации могут свести на нет любые концептуальные особенности механизмов безопасности. Это мы видим на практике анализа защищенности мобильных приложений.

Как видно из данного анализа, второй фактор при "MitM" не решает проблему, так как мобильные устройства обычно получают/передают его по тому жеканалу, который контролирует злоумышленник. Для мобильных устройств актуальна проблема не второго фактора, а скорее второго канала передачи данных.


Защита данных, передаваемых от клиента

Данный раздел концептуален, так как техника не имеет широкого распространения в реальности.

При первом запуске приложения и входе в систему можно генерировать пару «открытый и закрытый ключ» на устройстве [3] . Далее приложение передает на сервер открытый ключ, и он начинает ассо­циироваться с данным клиентом. В дальнейшем сервер ставит в соответствие каждому пользователю его сертификат и использует его по необходимости.

В результате даже при MitM-атаке злоумышленник будет видеть зашифрованные данные. Единственное, что сможет сделать злоумышленник, — это испортить запрос и не дать пройти операции.

Недостатки и возможные риски

· Передача сертификата на сервер должна производиться в надежной сети, чтобы злоумышленник не смог вмешаться в данный процесс

· На некоторых устройствах может быть недостаточно энтропии в нужный момент — например, в момент их первого включения

· Возможны проблемы с восстановлением ключа в случае утраты клиентского устройства

Методика исследования

В связи с изменением концепции трансформировался и подход к исследованию. На этот раз применялся динамический анализ.

Динамический анализ: проводилась атака "MitM" на стадии аутентификации в мобильном банкинге.

Мы проверяли два аспекта:

· Насколько корректна валидация SSL-сертифи­ката на стороне клиента:

Используем самоподписанный сертификат

Используем сертификат, выданный доверенным CA на другое имя хоста

· Используется ли SSL Pinning:

Используем CA-сертификат для данного хоста

Мы проводили активную атаку "MitM". Для этого мы заставляли жертву выходить в сеть Интернет через наш контролируемый шлюз, на котором производили манипуляции с сертификатами.

Для проверки работы с самоподписанными сертификатами мы сгенерировали собственный.

Для проверки наличия SSL Pinning и правильности проверки имени хоста мы генерировали собственный корневой сертификат, устанавливали его на мобильное устройство.

16.png


Результаты исследования

Мы получили неожиданные результаты для столь критичного вида приложений. Если ситуация с SSL Pinning ожидаема, то ситуация с самоподписанными сертификатами и проверкой имени хоста очень удручающая. Напомним, что мы рассматриваем программы, которые напрямую работают с деньгами пользователей. Более того, мы рассматриваем уязвимость, позволяющую украсть деньги.

Распределение приложений МБ для платформ

17.png

iOS

Всего было найдено 68 приложений для мобиль­ного банкинга. Из них удалось протестировать 61. Это связано с тем, что 7 приложений требовали активации и/или персонализации устройства, а значит, взаимодействия с работниками банка или отправки SMS/USSD-запроса.

Используемый протокол

Количество

HTTP/S

57

Другой протокол

4

Работа с Self-Signed сертификатами

Количество

Уязвимо

7

Неуязвимо

50

Работа с CA-Signed Cert Hostname

Количество

Уязвимо

7

Неуязвимо

50

Использование SSL Pinning

Количество

Использует

1

Не использует

56


Android

Всего было найдено 64 приложения для мобиль­ного банкинга. Из них удалось протестировать 59. Это связано с тем, что 5 приложений требовали активации и/или персонализации устройства, а значит, взаимодействия с работниками банка или отправки SMS/USSD-запроса.

Используемый протокол

Количество

HTTP/S

52

Другой протокол

7

Работа с Self-Signed сертификатами

Количество

Уязвимо

8

Неуязвимо

44

Работа с CA-Signed Cert Hostname

Количество

Уязвимо

12

Неуязвимо

40

Использование SSL Pinning

Количество

Использует

4

Не использует

48

Сколько же приложений уязвимы?

Использовались версии программ на 28.02.2014

У iOS 6 % приложений, а у Android 11 % прило­жений имели свой собственный протокол, и безопасность такого взаимодействия требует глубокого, ручного анализа. Из зрительного анализа трафика можно сказать, что он содер­жит как понятные, читаемые данные, так и сжа­тые/зашифрованные данные. По нашей и миро­вой практике можно сказать, что, вероятнее всего, эти приложения уязвимы к атаке "MitM".

SSL Pinning встречается очень редко: в 1 % при­ложений для iOS и в 8 % приложений для An­droid. При этом стоит отметить, что, возможно, эта проверка не прошла по каким-либо иным причинам, не связанным с SSL Pinning, и процент приложений, использующих данный механизм, еще меньше. Также мы не пытались обойти данный защитный механизм, не анализировали корректность его реализации.

14 % iOS-приложений и 15 % Android-приложе­ний уязвимы к самоподписанным сертифика­там. Кража средств для этих приложений — лишь вопрос времени.

14 % iOS приложений и 23 % Android приложе­ний уязвимы к CA-signed cert hostname. Также можно отметить, что при проверке имен хостов может существовать множество ошибок проверок. В связи с тем, что данная проверка производилась только с одним именем, можно считать данные результаты лишь нижней границей количества уязвимых приложений.

При этом стоит сказать, что только один банк имеет одновременно уязвимое приложение для iOS и An­droid.

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

Другие находки

В данном разделе собраны различные интересные факты, которые были замечены в процессе исследования, но не являлись приоритетными в данной работе:

· Есть приложения, которые предупреждают о недействительности сертификата, но позволяют продолжить работу с ним.

· В ряде приложений была обнаружена возможность проведения атаки "User Enumera­tion" — получения списка действующих логинов пользователей.

· Некоторые приложения, помимо SSL, еще используют внутреннее шифрование (иногда «соль» приходит с сервера), но большинство передают логин и пароль в открытом виде.

· Некоторые банки действительно отправляют платные SMS.

· В некоторых клиентах после трехкратного неверного ввода пароля можно заблокировать аккаунт.

· Логин входа — иногда номер телефона клиента.

· Можно встретить интересные ошибки на серверах.

· Почти все приложения отправляют на сервер информацию об устройстве, порой и уникальные идентификаторы устройства.

· В ответах сервера иногда приходят отладочные трейсы, раскрытие внутренней банковской информации (даже информация об АБС).

· Есть банки, у которых Android-приложение не лежит в магазине, а только на сайте, и установка требует возможности установки с «неизвестных источников».

· Для входа в мобильный банк часто используются учетные данные с интернет-банкинга.

· Один разработчик (даже одна платформа), а уязвимости разные.

Рекомендации

Для разработки такого критичного ПО нужны подготовленные тестовые среды.

· Необходимо тестировать на проникновение приложения и серверную сторону.

· Удаляйте отладочный код.

· Часть проблем с сертификатами может решить MDM (но он не всегда возможен).

· Читайте документацию по API и библиотекам.

· Руководствуйтесь принципами best practices при разработке.


Выводы

18.png

· Мобильные технологии все глубже проникают в сферу оплаты

· Наличие технологий защиты в ТЗ не гарантирует их правильного использования

· Техники атакующих развиваются, как и тех­ники защиты, и необходимо своевременно и корректно внедрять обновленные элементы в свои продукты

· Для того чтобы совершить кражу денег у клиен­тов мобильного банкинга, достаточно всего одной уязвимости

· Сочетание других уязвимостей может также привести к краже денег со счетов клиентов.

За помощь в создании и рецензировании данного исследования спасибо:

Алексею Тюрину, Эльдару Заитову, Егору Карбутову, Ивану Чалыкину, Никите Келесису, Николаю Еленкову и всем экспертам исследовательской лаборатории Digital Security Research Group.



[1] Работа SSL описывается в упрощенном виде и выходит за рамки данного исследования. Для более подробного ознакомления с данным протоколом советуем ознакомиться с RFC 6101.

[2] Дальнейшие проверки могут различаться в зависимости от реализации библиотеки, ОС и т. д.

[3] Подобное происходит при первом включении Apple- устройств и их дальнейшем общении с управляющим центром.

Источник: Digital Security





обновить

а вы знаете, что...

… предоплаченные платежные карты возникли как платежный инструмент в середине 1990-х гг., и первыми из них были карты Electronic Benefits Transfer (EBT) в США, на которые заменили ранее выдаваемые нуждающимся бумажные продовольственные сертификаты?