56e70f90cbcc8c092f036d8005351fd9

CONNECTING 

BANK ///// 

23 Android 

14 

% % 

iOS

Оглавление 

1) Введение 

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

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

SSL и Android 

SSL и iOS 

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

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

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

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

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

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

SSL Pinning 

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

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

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

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

iOS 

Android 

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

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

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

9) Выводы 

О компании 

Контакты 

____ 

1 

3 

6 

9 

11 

13 

13 

13 

14 

15 

16 

16 

18 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30

Введение 

В прошлом году мы постарались систематизировать сферу мобильного банкинга и подход к оценке его безопасности, 

а также провели статический анализ около 40 приложений для iOS и Android. 

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

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

Банки, естественно, реагируют на запросы потребителей. В рамках данного исследования будет рассмотрено 

уже не по 40 приложений для двух ОС, а примерно по 60. 

Возможности дистанционного банковского обслуживания физических лиц 

среди топ-200 российских розничных банков (2014 год) 

86 % 54 % 

2013 2014 

64 % 67 % 

2013 2014 

38 % 20 % 25 % 48 % 

21 % 25 % 

36 % 19 % 25 % 47 % 

23 % 13 % 11 % 24 % 

1 % 1 % 

3 % 3 % 4 % 18 % 

22 % 12 % 11 % 12 % 

Исследование проведено в январе 2014 года. 

Данные за 2013 год собраны в январе 2013 года. 

7 % 7 % 7 % 7 % 

6 % 5 % 

Аналитическое агентство Markswebb Rank & Report 

1

Введение 

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

Infin Bank 

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

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

Актив Банк 

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

Альфа-Банк 

Банк «2Т» 

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

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

Банк «БКФ» 

Банк «БФА» 

Банк «Веста» 

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

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

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

Банк «Зенит» 

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

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

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

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

Банк «Нейва» 

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

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

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

Банк24.ру 

Бинбанк 

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

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

ВТБ 

ВТБ24 

Вятка-банк 

Газпромбанк 

Живаго-Банк 

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

Инвестбанк 

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

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

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

КС Банк 

Лайф-Мобайл 

МДМ-Банк 

МИнБ 

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

МПСБ 

МТС-Банк 

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

Банк 

НОМОС-Банк 

Первобанк 

Примсоцбанк 

Приорбанк 

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

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

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

Рокетбанк 

Росбанк 

РосЕвроБанк 

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

РСХБ 

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

РусСлавБанк 

Сбербанк 

Связь-Банк 

СДМ-Банк 

СИАБ 

Ситибанк 

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

Собинбанк 

Солид Банк 

Татфондбанк 

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

УБРиР 

Уралсиб 

ФБИиР 

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

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

Экопромбанк 

Экспобанк 

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

Данное исследование, в первую очередь, направлено на повышение осведомленности пользователей, 

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

2

Атака “MitM”: 

сценарии и последствия 

По сравнению с прошлогодним исследованием, 

текущее претерпело значительные концептуальные 

изменения. 

Вместо поиска большого количества типов 

уязвимостей будет рассмотрена лишь одна — 

недостаточная защита транспортного уровня или ее 

отсутствие. В “OWASP Mobile Security Project — Top 

Ten Mobile Risks” эта проблема занимает 3-е место. Эту 

опаснейшую атаку особенно легко провести именно 

на мобильном устройстве. Поэтому данная проблема 

чрезвычайно важна и требует быстрого решения. 

Данные этого исследования применимы не только 

к МБ, но и к другим приложениям, требующим 

высокого уровня безопасности. Также некоторые 

из упомянутых техник применимы к ПО для 

стандартного ПК. 

Client 

MitM 

Server 

Normal Flow (broken) 

Man-in-the-Middle Flow 

В ходе исследования будет рассмотрена и оценена 

защищенность российских MБ от атаки типа 

«человек посередине», MitM. Проверка возможности 

реализации данной атаки выбрана не случайно: при 

контролировании канала передачи данных между 

приложением мобильного банкинга и сервером 

злоумышленник может украсть деньги со счета 

клиента, то есть нанести прямой финансовый ущерб. 

В основном, речь будет идти об ОС Android и iOS, как 

наиболее распространенных и имеющих наибольшее 

количество приложений для мобильного банкинга. 

Стоит сказать, что мы приводим лишь несколько 

сценариев из множества возможных. Главное, что 

необходимо злоумышленнику, — добиться того, 

чтобы сетевой трафик от жертвы на сервер шел через 

подконтрольный ему хост. 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

/* 

В рамках данного исследования рассматривается 

ситуация, когда устройство пользователя 

не имеет ни jailbreak, ни root-доступа. 

При наличии jailbreak или root-доступа уровень 

безопасности снижается на порядок, 

появляется еще больше векторов атаки, в том 

числе, нацеленных на кражу денег. Также наше 

«идеальное» устройство не заражено никакими 

вредоносными программами, ворующими 

средства (типа ZitMo (ZeuS-in-the-Mobile), 

SpitMo (SpyEye-in-the-Mobile)). Это верно везде, 

где не сказано обратное. 

*/ 

3


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

Подключение пользователя 

к поддельной Wi-Fi-точке 

доступа 

Это самый распространенный 

и реальный сценарий 

MitM-атаки. Может быть 

легко воспроизведен в кафе, 

торговом или бизнес-центре. 

Подключение к поддельной 

базовой станции оператора 

Эта схема становится все 

более доступной для широких 

масс благодаря широкому 

выбору аппаратного и 

программного обеспечения 

и его низкой стоимости. 

Ситуацию необходимо взять 

под контроль как можно 

оперативнее. 

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

сетевого оборудования 

Под заражением сетевого 

оборудования понимается не 

только исполнение на нем 

вредоносного кода, но и его 

целенаправленное злонамеренное 

переконфигурирование, 

например, через уязвимость. 

Уже известно немало примеров 

реализации подобных атак. 


Подключение через зараженное сетевое оборудование 

Internet 

1 2 

4

Атака “MitM” 

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

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

устройства. В результате устройство автоматически подсоединится к такой точке доступа и будет работать через 

нее. 

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

злоумышленника. 

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

Кража денежных 

средств со счетов 

клиента 

Раскрытие 

информации о счетах 

клиента и его прошлых 

операциях 

Просмотр данных 

о текущей операции 


Отказ 

в обслуживании 


5

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

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

шифрование и контроль целостности. Но не стоит забывать, что не все криптографические алгоритмы 

остаются стойкими и не всегда применение криптографии происходит корректно. 

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

Открытые 

Находясь в одной сети 

с жертвой, злоумышленник 

видит все клиент-серверное 

взаимодействие в открытом 

виде 

Защищенные 

нестандартными 

методами 

Как показывает наша практика, 

это не лучшее решение: оно 

приводит к ряду ошибок, 

которые ведут к компрометации 

передаваемых данных 

Защищенные 

стандартными 

методами 

Самый распространенный 

вариант — SSL/TLS 

SSL (Secure Sockets Layer) — общепринятый стандарт безопасного обмена сообщениями через Интернет. 

Безопасность SSL-соединения при защите от злоумышленника, активно атакующего из Сети, зависит от 

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

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

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

передаваемых между клиентом и сервером. 

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

6


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

3 

1 

4 

2 

5 

6 

7 

9 

8 

В SSL* все взаимодействие основывается на паре «открытый и закрытый ключ» сертификата сервера, и важным 

условием является то, что сертификат действителен. Это означает, что сертификат должен быть: 

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

не истекшим; 

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

имя/имена, перечисленные в списке соответствия 

сертификата(ов), и название домена, к которому 

подключается клиент, совпадают. 

* Работа SSL описывается в упрощенном виде и выходит за рамки данного исследования. Для более подробного 

ознакомления с данным протоколом советуем ознакомиться с RFC 6101. 

7


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

version 

serial no. 

singing algo. 

issuer name: 

Enterprise CA 

validate period 

subject name: 

www.enterprise.com 

... 

extentions 

basic constraint 

CA bit: 0 

key usage: 

keyEncipherment 

other extentions 

version 

serial no. 

singing algo. 

issuer name: 

Root CA 


subject name: 

Enterprise CA 

... 

extentions 


CA bit: 1, parthlen: 0 

name constraint 

*.enterprise.com 

key usage: 

keyCertSign 


version 

serial no. 

singing algo. 

issuer name: 

Root CA 


subject name: 

Root CA 

... 

extentions 


CA bit: 1 

key usage: 

keyCertSign 


Для обеспечения работоспособности данной 

схемы на устройстве находится много корневых 

сертификатов (CA), которые хранятся в специальном 

хранилище доверенных корневых сертификатов, и 

все, что ими подписано, является доверенным для 

устройства. 

Проверка сертификатов идет по цепочке: от 

присланного на устройство до корневого (CA), которому 

доверяет устройство. Далее* идут проверки 

имени хоста, отозванности и т. д. 

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

в систему) и пользовательские (установлены 

пользователем). 

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

8



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

В ОС Android до версии 4.0 все сертификаты 

хранились в едином файле — 

Bouncy Castle Keystore File. 

Изменить его без root-привилегий 

было невозможно, и ОС 

не предоставляла никаких 

способов его модификации. 

Любое изменение сертификата 

(добавление, отзыв) требовало 

обновления ОС. 

Начиная с версии Android 4.0, подход 

к работе с сертификатами изменился. 

Теперь все сертификаты хранятся 

отдельными файлами, и при 

необходимости можно удалять 

их из доверенных. 

/system/etc/security/cacerts 

/system/etc/security/cacerts.bks 

/data/misc/keychain/cacerts-added 

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

KitKat 

API 

Froyo 

2.2 

Froyo 

8 

1.0 

Gingerbread 

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 

Honeycomb 

Ice Cream Sandwich 

4.1.x 

4.2.x 

4.x 

Jelly Bean 

16 

17 

18 

33.5 

18.8 

8.5 

Jelly Bean 

4.3 

KitKat 

19 

8.5 

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

9



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

Для установки пользьзовательского сертификата 

в ОС Android необходимо загрузить корневой 

сертификат на SD-карту и зайти в меню Настройки -> 

Безопасность -> Установить с карты памяти или, в 

новых версиях, воспользоваться MDM (DevicePolicy- 

Manager). 

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

можно, но не очень просто. 

Для просмотра сертификатов в ОС Android необходимо 

зайти в меню Настройки -> Безопасность -> 

Надежные сертификаты (Settings -> Security -> Trusted 

credentials). 

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

в различных версиях Android 

4.0.3 

4.2.2 

4.4.2 

134 

140 

150 

Количество сертификатов также может меняться 

от производителя к производителю и для каждой 

модели устройства. 

10


SSL и iOS 

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

В ОС iOS посмотреть встроенные сертификаты нельзя, 

и получить информацию о них можно только с сайта 

компании Apple. Для просмотра пользовательских 

сертификатов необходимо зайти в меню Настройки 

-> Основные -> Профиль(и). 

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

различных версия iOS 

IOS 5 

IOS 6 

IOS 7 

183 

183 

211 

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

/private/var/Keychains/TrustStore.sqlite3 

В ОС iOS существует несколько путей установки 

пользовательских сертификатов: 

Через браузер Safari — необходимо зайти по 

ссылке, на которой лежит сертификат с расширением 

.pem или профиль конфигурации с 

расширением .profile; 

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

Через MDM API. 

Возможные векторы установки 

сертификатов через социальную 

инженерию: 

1) Пользователь делает все сам из-за неосведомленности 

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

вредоносным сертификатом 

3) Сертификат устанавливается на телефон с iOS за 

несколько секунд, если оказывается случайно в 

руках злоумышленника (например, он попросил 

позвонить) 

4) Сертификат устанавливается принудительно для доступа 

к бесплатной точке Wi-Fi 

Видно, что провести установку пользовательского 

сертификата через социальную инженерию на iOS 

намного проще, чем на Android. 

11


SSL и iOS 

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

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

12

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

В данном разделе мы рассмотрим, какие проблемы 

существуют при взаимодействии между клиентским 

приложением (в нашем случае приложением для 

мобильного банкинга) и сервером. 

Все примеры, приведенные здесь, — реальные, 

данную информацию мы получили в процессе 

аудитов защищенности приложений для мобильного 

банкинга. 

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

Как бы удивительно это ни звучало, еще год назад мы 

встречали приложения для мобильного банкинга, 

в которых все общение, включая финансовые 

операции, происходило по HTTP-протоколу: 

аутентификация, данные о переводах, — все было 

в открытом виде. Это значит, что злоумышленнику 

для получения финансовой выгоды необходимо 

было просто находиться с жертвой в одной сети и 

обладать минимальной квалификацией. Тогда для 

успешной атаки было достаточно исправлять номера 

счетов назначения и, при желании, суммы. 

Что касается взаимодействия приложения со 

сторонними сервисами, по сравнению с прошлым 

годом ситуация стала немного лучше, но 

по-прежнему большинство из них ходит за 

дополнительной информацией для своего 

функционирования по открытому каналу, на который 

легко может влиять злоумышленник. Как правило, 

эта информация связана: 

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

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

С курсом валют 

С социальными сетями 

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

С рекламой 

В лучшем случае, злоумышленник может просто 

дезинформировать жертву, а в худшем — внедрить 

собственный код, который выполнится на 

устройстве жертвы, что в дальнейшем поможет 

похитить аутентификационные данные или деньги. 

Причина в том, что ОС Android позволяет подгружать 

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

код злоумышленник может при определенных 

обстоятельствах внедрить в открытый канал. 

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

Данный вариант нам также встречался как на практике, 

так и в процессе исследования. Использование 

его нам непонятно, но, по нашим предположениям, 

оно может быть связано с устоявшимися внутренними 

процессами банка. При этом трафик в SSL дополнительно 

разработчиком не заворачивается. 

Как показывает наша практика, использование 

собственного шифрования до добра не доводит. 

Порой это даже не шифрование, а просто свой 

бинарный протокол, который на первый взгляд 

кажется непонятным, зашифрованным. 

13


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

Самый распространенный класс ошибок — это 

некорректное использование SSL. Чаще всего оно 

связано со следующими причинами: 

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

В процессе разработки используется различный 

тестовый код для ускорения процесса тестирования. 

И перед выпуском программы про этот код 

забывают. 

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

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

библиотеки для работы с SSL, каждая имеет свою 

специфику, и ее нужно учитывать. Так, с переходом 

с библиотеки на библиотеку разработчик 

может неправильно выставить константу при 

инициализации или переопределить функцию на 

свою. 

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

Данный пункт частично связан с предыдущим и 

приводит к тому, что разработчикам приходится 

идти на ряд ухищрений для проверки корректности 

работы приложения. 

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

с SSL: 

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

Некорректное переопределение стандартных 

обработчиков на собственные 

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

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

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

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

Отсутствие проверки на имя хоста или использование 

неправильных регулярных выражений 

для проверки 

• Использование уязвимых фреймворков 

Часто для упрощения разработчики применяют 

различные фреймворки. Другими словами, 

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

которого часто скрыта и недоступна. Этот код также 

содержит уязвимости, о чем разработчик часто 

даже не догадывается. Особенно это актуально в 

свете активной кроссплатформенной разработки 

для мобильных устройств. 

14


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

При использовании SSL существует зависимость 

от корневых сертификатов. Нельзя исключать 

возможность их компрометации — вспомним, к 

примеру, последние инциденты с Bit9, DigiNator и 

Comodo. Не стоит забывать и о сертификатах других 

стран, компаний, для которых трафик, можно сказать, 

является открытым. 

Как уже было показано, на устройствах находится 

большое количество сертификатов CA, и при 

компрометации любого из них компрометируется 

почти весь SSL-трафик для устройства. 

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

1) Пользователь может удалить сертификат из 

доверенных. 

В ОС Android пользователь может это 

сделать как со встроенными сертификатами, 

так и с пользовательскими. 

В iOS пользователь может удалить только 

пользовательские сертификаты. 

Надеяться на то, что пользователь сам будет 

управлять корневыми сертификатами, сложно. Так 

что единственный путь — это ждать обновления 

ОС. Пользователь в промежуток времени между 

компрометацией и обновлением системы уязвим. 

CA-сертификаты бывают разных типов — точнее, 

могут служить для разных целей (шифрования 

почты, подписи кода и т. д.), но они, как правило, 

хранятся в одном безопасном хранилище и могут 

использоваться для проверки доверия к HTTPSсоединению. 

К сожалению, корректная проверка 

назначения сертификата не везде реализована. 

Таким образом, злоумышленник может получить 

легитимный сертификат от выпускающего центра для 

одних целей, а использовать для установки HTTPSсоединения 

в процессе MitM-атаки. 

Кроме того, когда пользователь работает в браузере, 

он может заметить работу с подозрительным 

сертификатом по красному значку замочка в 

строке адреса. В такой же ситуации при работе 

через приложение пользователь никак не будет 

информирован, если разработчик этого не 

предусмотрел заранее, что делает атаку скрытной. 

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

3) Издатель сертификата может отозвать свой 

сертификат. Механизм проверки сертификата 

может динамически проверить это (например, 

OCSP, “Online Certificate Status Protocol”). 

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

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

15

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

SSL Pinning 

Помимо грамотного и повсеместного использования 

SSL мы можем порекомендовать еще несколько 

механизмов для повышения уровня безопасности 

канала. 

SSL Pinning 

В качестве защиты от компрометации корневых 

системных сертификатов и специально встроенных 

пользовательских можно использовать подход SSL 

Pinning. 

Pinning — это процесс ассоциации хоста с его 

ожидаемым X509-сертификатом или публичным 

ключом. Подход заключается во встраивании 

сертификата или публичного ключа, которому мы 

доверяем при взаимодействии с сервером, прямо в 

приложение и отказе от использования встроенного 

хранилища сертификатов. В итоге, при работе с 

нашим сервером приложение будет проверять 

действительность сертификата только на основании 

криптографического примитива, прошитого в нем. 

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

использовать: 

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

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

Для реализации SSL Pinning необходимо переопределить 

некоторые стандартные функции и 

написать собственные обработчики. Стоит отметить, 

что SSL Pinning не получится реализовать в случае 

использования WebView в Android и UIWebView в 

iOS в связи с их спецификой. 

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

app 1 app 2 

Приложения для МБ отлично подходят для 

использования SSL Pinning, так как разработчики 

точно знают, к каким серверам будет подключаться 

приложение, и список таких серверов мал. 

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

Certificate pinning 

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

Низкая гибкость 

подхода 

Public key pinning 

Проблемы с реализацией на 

некоторых платформах 

Хорошая гибкость 

подхода 

App1 для проверки действительности сертификата 

будет использовать только вшитый сертификат или 

публичный ключ. 

App2 для проверки действительности сертификата 

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

последовательно пройдет по всем сертификатам. 

16


SSL Pinning 

Применение 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 поддерживается 

на системном уровне. 

16 

17 

18 

19 

20 

21 

22 

23 

23 

25 

26 

27 

28 

29 

30 

31 

32 

33 

/* 

Обход SSL Pinning 

SSL Pinning можно обойти/отключить, если 

на мобильном устройстве присутствует 

jailbreak или root-доступ. Как правило, это 

нужно только исследователям для анализа 

сетевого трафика. Для отключения на Android 

есть программа Android SSL Bypass, для iOS – 

программы iOS SSL Kill Switch и TrustMe. 

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

и вредоносные программы. 

Как и любой код, проверки при SSL Pinning 

могут быть реализованы некорректно, и на 

это стоит обращать внимание. 

*/ 

17




Данную меру безопасности в сфере банковских 

операций вряд ли можно назвать дополнительной, 

так как она уже стала почти стандартом де-факто. 

Сейчас при проведении платежных действий 

часто недостаточно знать логин и пароль от своего 

аккаунта: необходимо подтвердить легитимность 

производимого действия с помощью еще одного 

фактора. Это и называется двухфакторной 

аутентификацией. В данном разделе рассмотрим 

преимущества и недостатки способов двухфакторной 

аутентификации, присутствующих на рынке и используемых 

в МБ. 

**** 

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

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

Принцип работы: есть таблица кодов, которые надо 

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

Проблема: как правило, коды в таблице никак не 

привязаны к деталям операции (например, сумме) 

и передаются именно по тому каналу, который 

и контролирует злоумышленник в MitM-атаке. 

Не защищает от проведения злоумышленником 

операций, не требующих кодов подтверждения, 

например, запроса состояния счетов. 

Рекомендация: использовать несколько таблиц кодов 

подтверждений, где каждая таблица соответствует 

определенному лимиту перевода денег. Например, 

одна таблица для операций ниже 1000 р., а другая 

— свыше 1000 р. Данный подход ограничит 

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

денежного лимита, но не предотвратит кражу 

средств. Наилучшим решением является отправка 

кода подтверждения по другому каналу передачи 

данных с привязкой к деталям операции. 

SMS 

Принцип работы: код подтверждения операции 

присылается клиенту, как правило, на это же 

мобильное устройство в SMS-сообщении. Код 

подтверждения вводится в приложение МБ и 

передается на сервер. 

Проблема: как правило, передается приложением 

МБ по тому же каналу, который контролирует 

злоумышленник в MitM-атаке. Не защищает от 

проведения злоумышленником операций, не 

требующих кодов подтверждения, например, запроса 

о состоянии счетов. Также, если на мобильном 

устройстве функционирует вредоносное ПО, оно 

может перехватить код подтверждения. 

Рекомендация: важно, чтобы в этом же сообщении 

содержалась информация о переводе (сумма, 

адресат). Но здесь не исключена невнимательность 

пользователя. Наилучшим решением является 

передача кода подтверждения по другому каналу 

передачи данных или на другое устройство. 

18



Специальное* мобильное приложение 

* иногда является частью приложения для МБ. 

Принцип работы (описан на основе приложения 

MobiPass): приложение предназначено для самостоятельного 

формирования клиентом одноразовых 

ключей. Для активации приложения пользователь 

вводит 32-значный секретный код, предоставленный 

банком, 28 цифр кода используются для 

инициализации системы, а 4 являются контрольной 

суммой. В дальнейшем для генерации кода 

подтверждения пользователь должен лишь ввести 

PIN приложения и код операции, для которой нужно 

вычислить подтверждения. MobiPass основана 

на открытом стандарте “Open Authentication”, и в 

основе лежит алгоритм RFC-4226 “HOTP: An HMAC- 

Based One-Time Password Algorithm”. Данный подход 

сейчас становится популярным у банков в связи с 

повышением цен операторов на отправку SMS. 

Проблема: не добавляет никакой защиты от “MitM”, так 

как одноразовый ключ передается по тому же каналу, 

который контролирует злоумышленник. При этом 

вычисление кода завязано только на кодовом числе 

документа, и его детали (сумма, место назначения) 

никак не учитываются при вводе в программу. В 

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

со стороны вредоносного ПО. При компрометации 

секретного ключа злоумышленник способен 

самостоятельно генерировать одноразовые ключи. 

Рекомендация: проверять безопасность таких 

программ и делать привязку генерации ключа хотя 

бы к сумме или счету, чтобы минимизировать потери. 

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

Принцип работы: используется микрофон для 

распознавания голоса, тачскрин для росписи, 

камера для определения овала лица, сетчатки глаза. 

Биометрические данные считываются и передаются 

на сервер. 

Проблема: наши исследования и опыт проверки таких 

систем показывают, что мобильным устройствам 

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

операций. Данные опять же передаются по каналу, 

который контролирует злоумышленник в MitM-атаке. 

В случае компрометации бинарного представления 

биометрического фактора могут возникнуть 

проблемы с его сменой. 

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

использовать специализированные датчики. 

Аппаратный генератор 

кодов подтверждений 

Принцип работы: отдельное устройство для 

генерации кодов. Как правило, представляет собой 

небольшое устройство с дисплеем. Основным 

преимуществом является то, что даже если 

мобильное устройство заражено (но не имеет jailbreak 

или root-доступа), то вредоносное ПО не узнает 

код подтверждения. 

Проблема: скорее всего, код будет передаваться 

по тому же каналу, который контролирует 

злоумышленник. Постоянная необходимость в 

данном устройстве при совершении операций 

негативно сказывается на мобильности. 

Рекомендация: важно, чтобы в этом же сообщении 

содержалась информация о переводе (сумма, адресат). 

Но возможна невнимательность пользователя. 

Не стоит забывать, что недостатки реализации могут 

свести на нет любые концептуальные особенности 

механизмов безопасности. Это мы видим на практике 

анализа защищенности мобильных приложений. 

Как видно из данного анализа, второй фактор при 

“MitM” не решает проблему, так как мобильные 

устройства обычно получают/передают его по тому 

жеканалу, который контролирует злоумышленник. 

Для мобильных устройств актуальна проблема не 

второго фактора, а скорее второго канала передачи 

данных. 

19


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

Данный раздел концептуален, так как техника не 

имеет широкого распространения в реальности. 

При первом запуске приложения и входе в систему 

можно генерировать пару «открытый и закрытый 

ключ» на устройстве*. Далее приложение передает 

на сервер открытый ключ, и он начинает ассоциироваться 

с данным клиентом. В дальнейшем 

сервер ставит в соответствие каждому пользователю 

его сертификат и использует его по необходимости. 

В результате даже при MitM-атаке злоумышленник 

будет видеть зашифрованные данные. Единственное, 

что сможет сделать злоумышленник, — это испортить 

запрос и не дать пройти операции. 

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

Передача сертификата на сервер должна 

производиться в надежной сети, чтобы 

злоумышленник не смог вмешаться в данный 

процесс 

На некоторых устройствах может быть 

недостаточно энтропии в нужный момент — 

например, в момент их первого включения 

Возможны проблемы с восстановлением 

ключа в случае утраты клиентского устройства 

* Подобное происходит при первом включении Appleустройств 

и их дальнейшем общении с управляющим 

центром. 

20

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

В связи с изменением концепции трансформировался 

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

динамический анализ. 

Динамический анализ: проводилась атака “MitM” на 

стадии аутентификации в мобильном банкинге. 

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

1) Насколько корректна валидация SSL-сертификата 

на стороне клиента: 

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

Мы проводили активную атаку “MitM”. Для этого мы 

заставляли жертву выходить в сеть Интернет через 

наш контролируемый шлюз, на котором производили 

манипуляции с сертификатами. 

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

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

Для проверки наличия SSL Pinning и правильности 

проверки имени хоста мы генерировали 

собственный корневой сертификат, устанавливали 

его на мобильное устройство. 

Используемые устройства: 

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

доверенным CA на другое имя хоста 

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

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

хоста 

Android 

4.0.3 

iPhone 

iOS 7 

21

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

Мы получили неожиданные результаты для столь 

критичного вида приложений. Если ситуация с SSL 

Pinning ожидаема, то ситуация с самоподписанными 

сертификатами и проверкой имени хоста очень 

удручающая. Напомним, что мы рассматриваем 

программы, которые напрямую работают с деньгами 

пользователей. Более того, мы рассматриваем 

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

Распределение приложений МБ 

для платформ 

24 44 20 

22


iOS 

Всего было найдено 68 приложений для мобильного 

банкинга. Из них удалось протестировать 61. 

Это связано с тем, что 7 приложений требовали 

активации и/или персонализации устройства, а 

значит, взаимодействия с работниками банка или 

отправки SMS/USSD-запроса. 

HTTP/S 57 

4 

7 

50 

7 

50 

1 

56 

23


Android 

Всего было найдено 64 приложения для мобильного 

банкинга. Из них удалось протестировать 59. 

Это связано с тем, что 5 приложений требовали 

активации и/или персонализации устройства, а 

значит, взаимодействия с работниками банка или 

отправки SMS/USSD-запроса. 

HTTP/S 52 

7 

8 

44 

12 

40 

4 

48 

24


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

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

6 % 

11 % 

1 % 

8 % 

У iOS 6 % приложений, а у Android 11 % приложений 

имели свой собственный протокол, и 

безопасность такого взаимодействия требует 

глубокого, ручного анализа. Из зрительного 

анализа трафика можно сказать, что он содержит 

как понятные, читаемые данные, так и сжатые/зашифрованные 

данные. По нашей и мировой 

практике можно сказать, что, вероятнее 

всего, эти приложения уязвимы к атаке “MitM”. 

SSL Pinning встречается очень редко: в 1 % приложений 

для iOS и в 8 % приложений для Android. 

При этом стоит отметить, что, возможно, 

эта проверка не прошла по каким-либо иным 

причинам, не связанным с SSL Pinning, и 

процент приложений, использующих данный 

механизм, еще меньше. Также мы не пытались 

обойти данный защитный механизм, не 

анализировали корректность его реализации. 

14 % 15 % 

14 % 

23 % 

14 % iOS-приложений и 15 % Android-приложений 

уязвимы к самоподписанным сертификатам. 

Кража средств для этих приложений — 

лишь вопрос времени. 

При этом стоит сказать, что только один банк имеет 

одновременно уязвимое приложение для iOS и Android. 

14 % iOS приложений и 23 % Android приложений 

уязвимы к CA-signed cert hostname. Также 

можно отметить, что при проверке имен 

хостов может существовать множество ошибок 

проверок. В связи с тем, что данная проверка 

производилась только с одним именем, можно 

считать данные результаты лишь нижней 

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

32 

33 

34 

35 

36 

37 

38 

39 

40 

/* 

Как показывает наш опыт в анализе безопасности мобильных приложений, почти всегда присутствует 

код, отвечающий за отключение проверки действительности сертификата. Данный код используется 

разработчиками для тестовых целей. В связи с этим, из-за невнимательности разработчика код может 

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

может появляться в одной версии и исчезать в другой, что делает данную уязвимость 

«плавающей» от версии к версии. В итоге, безопасность данного кода зависит от правильности 

процессов, организованных у разработчика. 

*/ 

25


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

В данном разделе собраны различные интересные 

факты, которые были замечены в процессе 

исследования, но не являлись приоритетными в 

данной работе: 

Есть приложения, которые предупреждают о 

недействительности сертификата, но позволяют 

продолжить работу с ним. 

В ряде приложений была обнаружена 

возможность проведения атаки “User Enumeration” 

— получения списка действующих 

логинов пользователей. 

Некоторые приложения, помимо SSL, еще 

используют внутреннее шифрование (иногда 

«соль» приходит с сервера), но большинство 

передают логин и пароль в открытом виде. 

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

платные SMS. 

В некоторых клиентах после трехкратного 

неверного ввода пароля можно заблокировать 

аккаунт. 

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

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

серверах. 

Почти все приложения отправляют на 

сервер информацию об устройстве, порой и 

уникальные идентификаторы устройства. 

В ответах сервера иногда приходят отладочные 

трейсы, раскрытие внутренней банковской 

информации (даже информация об АБС). 

Есть банки, у которых Android-приложение не 

лежит в магазине, а только на сайте, и установка 

требует возможности установки с «неизвестных 

источников». 

Для входа в мобильный банк часто используются 

учетные данные с интернет-банкинга. 

Один разработчик (даже одна платформа), а 

уязвимости разные. 

26

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

Для разработки такого критичного ПО нужны 

подготовленные тестовые среды. 

Необходимо тестировать на проникновение 

приложения и серверную сторону. 

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

Часть проблем с сертификатами может решить 

MDM (но он не всегда возможен). 

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

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

при разработке. 

27

Выводы 

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

в сферу оплаты 

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

их правильного использования 

14 % 23 % 

Техники атакующих развиваются, как и техники 

защиты, и необходимо своевременно и 

корректно внедрять обновленные элементы в 

свои продукты 

Для того чтобы совершить кражу денег у клиентов 

мобильного банкинга, достаточно всего 

одной уязвимости 

подвержены краже 

денег только 

с помощью MitMатаки 

подвержены краже 

денег только 

с помощью MitMатаки 

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

к краже денег со счетов клиентов. 

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

Алексею Тюрину, Эльдару Заитову, Егору Карбутову, Ивану Чалыкину, Никите Келесису, Николаю Еленкову и всем 

экспертам исследовательской лаборатории Digital Security Research Group. 

28


Digital Security — ведущая российская консалтинговая 

компания в области информационной безопасности, 

основанная в 2003 году. Мы предоставляем широкий 

спектр услуг в области оценки защищенности, в том 

числе проведение аудитов ИБ и тестов на проникновение, 

подготовку и сертификацию по PCI и PA-DSS, 

СТО БР ИББС, аудит защищенности систем ДБО, SCADA, 

ERP-систем, бизнес-приложений, веб-приложений и 

платформ виртуализации. 

Digital Security является членом Технического комитета 

362 ФСТЭК России и Технического комитета 122 

ЦБ РФ и принимает активное участие в разработке 

государственных стандартов защиты информации. 

Digital Security имеет статус PCI QSA с 2007 года и PA 

QSA с 2010 года. 

Digital Security является официальным партнером SAP 

AG, международным лидером по поиску и анализу 

уязвимостей в продуктах SAP, а также разработчиком 

ERPScan Security Monitoring Suite — инновационного 

продукта по комплексной оценке защищенности и 

проверке соответствия стандартам для платформы 

SAP. Только в 2010 году из 58 уязвимостей в продуктах 

SAP, опубликованных исследователями со всего мира, 

19 уязвимостей были обнаружены исследовательской 

лабораторией Digital Security. Всего к июню 2013 года 

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

продуктах SAP. С 2010 года специалисты Digital Security 

проводят тренинги по ИБ для SAP Product Security 

Response Team, с 2013 оказывают корпорации услуги 

по повышению защищенности новых разработок SAP. 

В 2007 году открылся исследовательский центр в 

области информационной безопасности Digital Security 

Research Group, пользующийся международным 

признанием и получивший множество официальных 

благодарностей от таких мировых лидеров индустрии 

информационных технологий, как Oracle, SAP, Apache, 

SUN, IBM, Alcatel и др. Исследовательский центр Digital 

Security стал уникальным явлением для российского 

рынка ИБ: ранее поиск уязвимостей осуществлялся 

бессистемно и нерегулярно, в любительском формате. 

Открытие лаборатории Digital Security вывело эту 

деятельность на профессиональный уровень. 

За все время работы лаборатории было обнаружено 

318 уязвимостей, из которых 199 закрыто 

производителями, а по остальным все еще ведется 

работа. Количество найденных уязвимостей 

составляет около 0,8% от всех уязвимостей, закрытых 

в мире за последние пять лет, и превышает опыт всех 

остальных российских компаний в совокупности. 

За время работы исследовательского центра было 

проведено 42 исследования, результатами которых 

стали различные статьи, отчеты и выступления на 

конференциях. Так, с 2009 по 2011 год экспертами Digital 

Security Research Group проводилось масштабное 

исследование российских систем дистанционного 

банковского обслуживания. В 2012 году специалисты 

Digital Security Research Group опубликовали 

множественные уязвимости промышленных 

контроллеров и SCADA в поддержку проекта Base- 

Camp. 

29


В 2012 году проведено исследование «Безопасность 

SAP в цифрах» — первый в мире высокоуровневый 

обзор актуальных проблем безопасности SAPсистем. 

В 2013 году опубликованы результаты 

исследования уязвимостей российских систем 

для мобильного банкинга за 2012 год. В истории 

центра более 40 выступлений на крупных западных 

конференциях по практической безопасности, таких 

как BlackHat, RSA, HackInTheBox и многих других. 

Кроме того, специалисты Digital Security Research 

Group возглавляют проект OWASP-EAS, посвященный 

безопасности бизнес-приложений. 

В 2009 году компанией Digital Security было создано 

PCIDSS.RU — открытое Сообщество профессионалов 

в области стандарта безопасности данных индустрии 

платежных карт (PCI DSS), которое служит для 

аккумулирования и обсуждения информации 

о стандарте и способствует его внедрению и 

продвижению в среде организаций, формирующих 

рынок платежных услуг. 

Начиная с 2010 года, Digital Security совместно с Ассоциацией 

Российских Членов Европей при официальной 

поддержке Visa, MasterCard и Совета PCI SSC проводит 

единственную в России специализированную 

международную конференцию по безопасности 

данных индустрии платежных карт PCI DSS 

Russia, предназначенную для всестороннего 

взаимодействия Совета PCI, международных 

платежных систем, консультантов в области 

PCI и участников индустрии платежных карт — 

представителей банковского сектора. С 2014 года 

конференцию организует партнер Digital Security — 

компания «Авангард Центр». 

С 2011 года Digital Security проводит ZeroNights 

— международную конференцию, посвященную 

практическим аспектам информационной 

безопасности. Данное мероприятие рассказывает 

о новых методах атак и угрозах, показывает 

возможности для нападения и защиты, предлагает 

нестандартные методы решения задач ИБ, собирает 

экспертов, специалистов-практиков по ИБ, 

аналитиков и хакеров со всего мира. 

Среди клиентов Digital Security такие компании, 

как ОАО «Альфа-Банк», ОАО «АК БАРС» Банк, АО 

«КазТрансОйл», холдинг «Металлоинвест», ОАО 

«Пивоваренная компания «Балтика», Mail.Ru Group, 

Commerzbank, SAP AG и многие другие. 

Штаб-квартира 

Россия, 115093 

Москва, Партийный пер., д. 1, корп. 57, стр. 3 

тел./факс: +7 (495) 223-0786, +7 (499) 277-7924 

Центр R & D 

Россия, 197183 

Санкт-Петербург, ул. Сабировская, д. 37 

тел./факс: +7 (812) 703-1547, +7 (812) 430-9130 

Электронная почта: 

• По общим вопросам: info@dsec.ru 

• Отдел продаж: sales@dsec.ru 

Пресса: pr@dsec.ru • 

Адрес в Интернете: www.dsec.ru 

30

56e70f90cbcc8c092f036d8005351fd9

Create successful ePaper yourself

Delete template?

Save as template?