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

 

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

 

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

 

Во-первых: функциональность. С точки зрения использования клиентом собственных или заемных средств это:

 

•   платежи за все, что можно;

 

•   переводы между своими счетами и другим физическим или юридическим лицам с любого банковского счета или карты;

 

•   получение балансов и выписок;

 

•   пополнения наличными своих счетов, получение наличных в сети своего банка и чужих банков (Cash by code).

 

Если мы говорим о «подписных» функциях, то это:

 

•   открытие/закрытие счета или карты;

 

•   перевыпуск, блокировка карты;

 

•   смена или установка ПИНов и логинов-паролей мобильных или интернет-приложений;

 

•   подписка на автоплатежи и постоянно действующие платежные поручения;

 

•   получение кредитов, открытие депозитов.

 

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

 

С точки зрения платформ и то это максимум из того, что наблюдается на смартфонах и планшетах клиентов: iOs, Windows Phone, Android.

 

Что касается безопасности, то, по мнению большинства банкиров и разработчиков специализированного программного обеспечения, системы мобильного банкинга должны соответствовать базовым стандартам безопасности. Еще пару лет назад множество банков с пиететом относилось к стандарту PCI DSS и старалось сделать так, чтобы система мобильного банкинга была по возможности составной частью аудируемого по этому стандарту комплекса информационных систем. Сейчас отношение банков к стандартам безопасности данных начало меняться. Многие обращают внимание на отечественные ГОСТы, что, безусловно, понятно в связи с часто появляющейся информацией о вольном обращении западных коллег и партнеров с защитой банковской тайны, а также с постоянно укрепляющимися сомнениями в надежности импортных систем информационной безопасности. Что касается алгоритмов защиты данных (шифрования), то это или симметричные алгоритмы шифрования (3DES) с длиной ключа не менее 3х64 бит, или асимметричные алгоритмы шифрования (RSA) с диной ключа 1024 бит, а с недавнего времени – 2048 бит. Системы аутентификации: MMA (Master Card Mobile Authentication) или OATH (Open Authentication).

 

Требуемый банками функционал диктует интеграцию систем мобильного банкинга со следующими информационными системами банка (ИС/протокол):

 

•   с процессинговыми системами, по своим картам (SOAP, ISO),

 

•   с процессинговыми системами, по «чужим картам» картам China Union Pay, Visa, Master Card… (ISO, Base1),

 

•   с АБС и ритейловыми системами в онлайне (SOAP, XML),

 

•   с шинами передачи данных, работающими с банковскими и платежными информационными системами (XML).

 

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

 

 

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

 

•   первый фактор: логин и пароль в приложении, напоминающем интернет- браузер;

 

•   второй фактор: одноразовый пароль (СМС, Е-токен: электронный генератор одноразовых паролей, листочек с распечатанным списком паролей);

 

или:

 

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

 

•   второй фактор – ПИН-код в голове пользователя.

 

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

 

Конечно же, все данные, которыми клиент обменивается с банком, и вся чувствительная информация, которая хранится в мобильном приложении, должна быть зашифрована. Поэтому устойчивое шифрование передаваемых и хранимых данных на уровне приложения является обязательным требованием к системам мобильного банкинга. Как уже упоминалось выше, алгоритмы шифрования могут быть как симметричными с длинами ключа хотя бы 3х64 бит или ассиметричными с длиной ключа не менее 1024 бит, а лучше – 2048 бит.

 

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

 

Еще одно требование, которое предъявляется к системам мобильного банкинга, – устойчивое шифрование передаваемых и хранимых данных на уровне канала передачи данных. Это могут быть стандартные протоколы SSL или HTTPS.

 

 

 

Самое простое, что может получить банк, который уже вложил значительные средства в систему интернет-банкинга, – это приложение-браузер: аналог сайта, доступ к которому осуществляется по обычной паре секретных величин «логин-пароль». Такой формат оптимален для банка с развитой системой интернет-банкинга, прост и быстр в построении и внедрении. Безопасность такой системы на уровне канала связи с банком ничуть не хуже, чем у WEB-банкинга (SSL, HTTPS). Поскольку он является «пристройкой» к существующей системе, он «от рождения» интегрирован с прочими информационными системами банка, так же как WEB-банкинг.

 

Приложения-браузеры разрабатываются как мобильные интерфейсы, аналогичные интерфейсам WEB-банкинга, и соответствуют стандарту PCI DSS, хотя аудиторы и затрудняются ответить на многочисленные вопросы критиков.

 

Что касается недостатков, то тут все довольно интересно.

 

 

В качестве двухфакторной аутентификации разработчики представляют (1) логин и пароль, (2) получение одноразовых паролей по sms. Вот тут-то и начинается самое интересное. Меня радуют консультанты одного очень крупного отечественного банка, продвигающие подключение к своей системе мобильного банкинга в отделениях этого банка. Они утверждают, что логин и пароль, введенные в приложение на телефоне клиента, – это первый фактор аутентификации, а sms с одноразовым паролем, пришедшее на тот же телефон, – это второй фактор. Это утверждение имело бы некую обоснованность, если бы не вирусные программы. Операционная система Android, к сожалению, не славится хорошей инкапсуляцией приложений. Это не могло не привести к тому, что в уже не близком 2012 году появилась первая вирусная программа с говорящим постсоветским названием Perkele, позволяющая перехватывать sms. И заверте… Сейчас таких программ уже много, и автора совсем не удивит ситуация, когда пользователь мобильного банкинга спокойно спит, а sms с одноразовыми паролями приходят на его телефон. Далее вирусная программа посылает их на сервер злоумышленников, куда за некоторое время до этого уже были направлены логин и пароль пользователя. Последствия вы себе представляете. Конечно, консультанты банка вам скажут, что вы можете получать sms с одноразовыми паролями на другой телефон, но многие ли так поступают на практике?

 

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

 

Тут все проще. Приложения для айфонов и айпадов довольно пристально проверяются сотрудниками компании Apple, прежде чем разместить на маркет, инкапсуляция данных в приложениях операционной системы iOs не вызывает особых нареканий. Зато вызывает вопросы запрет компании Apple на использование длинных ключей шифрования для симметричных (3х64 бит) и асимметричных (512 бит) алгоритмов для уровня приложения. Ссылается компания, конечно, на законы США, и разработчики, конечно, не сомневаются, что такая уважаемая компания, как Apple, с ЦРУ не сотрудничает. А вы?

 

В завершение краткого обзора недостатков и уязвимостей подобных систем следует отметить их общий недостаток: клиенту просто неудобно каждый раз выходить из приложения, смотреть sms, потом возвращаться и вводить пароль для подтверждения операции. Намного проще было бы просто ввести ПИН. Возможно ли это? Да, мы эту возможность рассмотрим ниже.

 

 

Подобные системы разрабатываются как мобильные интерфейсы для популярных процессинговых систем и соответствуют стандарту PCI DSS. Позволяют клиенту провести операцию, не дожидаясь одноразового пароля по sms, а просто ввести ПИН-код приложения.

 

Такой мобильный банкинг подходит для банка, который активно развивает карточную эмиссию и, возможно, вложил значительные средства в построение процессингового центра. «От рождения» такие системы обеспечивают безопасность в соответствии со стандартом PCI DSS, так как именно процессинговые системы в первую очередь являются объектом аудита по этому стандарту. Системы используют устойчивые алгоритмы шифрования: 3DES (длина ключа 3х64 бит) или RSA (длина ключа минимум 1024 бит). Системы аутентификации также на высоте: MMA/OATH.

 

Недостатки таких систем являются продолжением их достоинств. Подобный мобильный банкинг зачастую интегрирован с АБС банка через процессинговый центр и, как следствие, «картоцентричен». То, чего не может карточная система, того не может мобильный банкинг. Кроме этого, эмитируется и персонализуется такой мобильный банкинг зачастую как карта, при помощи ПИН-конверта, который клиент получает на руки, или новых систем установки или смены ПИН-кода, таких как, например, использование системы IVR: смена ПИН-кода по телефону. Безусловно, разработчики карточных систем стараются минимизировать эти недостатки, но они зачастую проявляются в практике банков и приводят к значительным затратам на интеграцию процессинговых систем банка с прочими информационными системами банка. Специалистов не удивляют миллионные затраты банков на построение шин данных, объединяющих процессинг и АБС банка.

 

К уязвимостям Android тут можно отнести, опять-таки, некоторую «леность» разработчиков карточных систем, что приводит к использованию распространенных библиотек шифрования.

Равно и уязвимости iOs: все тот же знакомый нам запрет на использование длинных ключей шифрования для симметричных и асимметричных алгоритмов для уровня приложения.

 

 

Подобные системы разрабатываются как равноправные средства доступа клиентов к любым счетам наряду с интернет-банкингом, банкоматами и/или терминалами Cash-In, вне зависимости от того, где счета клиента ведутся: в АБС банка или в процессинговой системе. Такие системы, равно как и описанные выше «карточные», от момента внедрения соответствуют стандарту PCI DSS. Также они позволяют клиенту провести операцию, не дожидаясь одноразового пароля по sms, введя ПИН-код мобильного приложения. Интеграция таких мобильных банкингов с другими информационными системами банка осуществляется по независимым протоколам (SOAP, ISO, XML) и обеспечивает доступ клиента ко всем своим инструментам и информационным сервисам, что исключает узкое место в виде карточной системы.

 

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

 

Поскольку системы строятся с учетом опыта разработки карточных систем, то безопасность их как минимум не ниже последних. На уровне канала обмена данными между приложением и сервером обеспечивается шифрование данных по асимметричному алгоритму RSA 1024 (2048). Аутентификация: чаще OATH, но встречается и ММА. При этом первым фактором аутентификации является секретная величина, записываемая в приложение во время процедуры инициализации, а вторым – ПИН-код, который не имеет отношения к приложению и нигде в телефоне не хранится. Кроме этого, отрадно было обнаружить, что для разработки некоторых подобных систем разработчики отказываются от использования популярных библиотек шифрования и реализуют протоколы шифрования самостоятельно.

 

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

 

Уязвимости iOs для подобных систем обычны: все тот же упоминавшийся выше запрет на использование длинных ключей: привет от ЦРУ.

 

 

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

 

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