Требования к безопасности мобильного приложения. Некорректная работа с SSL. Мобильные банковские приложения для Android

В. А. Артамонов

ПРОБЛЕМЫ БЕЗОПАСНОСТИ МОБИЛЬНЫХ УСТРОЙСТВ, СИСТЕМ И ПРИЛОЖЕНИЙ

Часть 5

Угрозы и уязвимости мобильных приложений

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

С ростом популярности разработки мобильных приложений, повышается их капиталоёмкость, а вместе с этим и желание злоумышленников перевести эти капиталы на свои счета. Многие современные мобильные программы предполагают внутренние покупки, а также отправку SMS на платные номера, именно эти лазейки могут использовать хакеры. Одно дело, сколько стоит создание мобильного приложения, а другое – сколько будет стоить сделать его безопасным. Механизмов взлома и вытаскивания денег из мобильных устройств чрезвычайно много, каждый год появляются новые алгоритмы, но вместе с тем растёт и сила противодействия, способная своевременно бороться с угрозами. В наименьшей степени этим тенденциям подвержены закрытые системы, в частности IOS, поскольку архитектура её выполнена так, что в ней практически невозможно появление вирусов.

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

Исследования, проведенные IBM X-Force, наглядно демонстрируют значительный процент уязвимостей, относящийся к мобильным и WEB–приложениям . Для эффективной защиты своих мобильных приложений организациям необходимо проводить широкомасштабное тестирование поддерживающего ПО и самих приложений. Тестирование и проверка на ранних этапах внедрения мобильной технологии помогут уменьшить затраты на обеспечение безопасности.

Решения в области обеспечения безопасности приложений должны быть направлены на решения следующих задач:

– Повышения эффективности управления программами обеспечения безопасности приложений;

– Анализа исходного кода, WEB – и мобильных приложений на наличие уязвимостей;

– Автоматизации результатов статического и динамического тестирования приложений;

–Управления тестированием приложений, отчетами и политиками с помощью одной консоли, в том числе тестированием методом "прозрачного ящика" (разновидность интерактивного тестирования безопасности приложений (IAST).

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

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

По месту расположения приложения:

SIM-приложения – приложение на SIM-карте, написанное в соответствии со стандартом SIM Application Toolkit (STK);
Web-приложения – специальная версия Web-сайта;
мобильные приложения – приложения, разработанные для определенной мобильной ОС с использованием специализированного API, устанавливаемого в смартфон.

По типу используемой технологии взаимодействия с сервером:

Сетевые приложения – используют собственный протокол общения поверх TCP/IP, например HTTP;
SMS-приложения – приложения на основе SMS (Short Messaging Service);
Приложение обменивается с сервером информацией с помощью коротких текстовых сообщений;
USSD-приложения – приложения на основе USSD (Unstructured Supplementary Service Data). Сервис основывается на передаче коротких сообщений, схожих с SMS, но имеет ряд отличий;
IVR-приложения – приложения, базирующиеся на технологии IVR (Interactive Voice Response). Система основана на заранее записанных голосовых сообщениях и тональном наборе.

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

Оценка уровня защищённости некоторых приложений.

Компания Viaforensics провела уникальное исследование в сфере оценки защищённости мобильных приложений, которое дало в итоге достаточно интересные данные. Исследователи этой компании отобрали случайным образом 30 популярных программ мобильных приложений и подвергли их серьёзной проверке на надёжность. В результате порядка четверти заявленных решений вскрыты путём взлома и были названы небезопасными. Специалисты смогли с помощью внешних воздействий вытащить из памяти устройств сохранённые Pin-коды и номера кредитных карт. Также в ряде случаев удалось обеспечить несанкционированный доступ к истории платежей. Безусловно, подобная ситуация выглядит довольно плачевной, по понятным причинам Viaforensics не сообщает, о каких именно приложениях идёт речь.

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

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

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

Digital Security провела аудит безопасности клиентской части приложений на следующих мобильных платформах :

Google Android;
Apple iOS (iPhone/iPad);
Java (J2ME/Java ME);
Windows Phone.

Типовые угрозы.

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

– Секретные данные в открытом виде;

– Небезопасные каналы передачи информации;

– Наличие отладочного кода;

– Внедрение SQL-операторов;

– Межсайтовый скриптинг (XSS);

– Отсутствие проверок входящих данных;

– Неправильная расстановка прав доступа;

– Слабая криптография.

Методика аудита и содержание работ.

Методика аудита безопасности клиентской части мобильного приложения, разработанная исследовательским центром Digital Security, основана на опыте анализа защищенности различных по функциональности и сложности приложений, таких как ERP-системы, автоматизированные банковские системы, банк-клиенты, веб-приложения, системы управления базами данных и др. Подход к анализу основан на общепризнанных методах исследования приложений, описанных в таких документах, как PCI DSS Requirements and Security Assessment Procedures, OWASP Testing Guide, PA-DSS Requirement and Security Assessment Procedures, и доработан с учетом практического исследовательского опыта DSecRG.

Этапы работы.

Процесс анализа приложения состоит из нескольких базовых этапов:

– Анализ архитектуры клиентской части приложения;

– Составление модели угроз;

– Аудит безопасности кода;

– Стресс-тестирование (fuzzing);

– Реализация угроз в соответствии с логикой приложения.

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

Компания «Инфосистемы Джет» обнародовала аналитический отчет по уязвимостям мобильных банковских приложений, функционирующих под управлением iOS, Android и Windows Phone . Результаты исследования показали, что 98% программ имеют уязвимости и 40% из них обладают уязвимостями критического характера.

Отчет основан на данных, полученных экспертами компании в ходе обследования 58 банковских приложений. Был проведен статический и динамический анализ исходного кода продуктов. Эксперты «Инфосистемы Джет» оценили уровень безопасности межсетевого взаимодействия между мобильным приложением и WEB-сервисом, а также настройки защищенного соединения.

«При обследовании мы ориентировались на самые злободневные уязвимости, которым подвержены мобильные банковские приложения. В их числе атаки класса Man-In-The-Middle («человек посередине») и целый ряд брешей, позволяющих злоумышленникам совершать кражи конфиденциальных данных пользователей банковских систем различными способами», – пояснил Георгий Гарбузов, руководитель отдела консалтинга Центра информационной безопасности компании «Инфосистемы Джет».

Выяснилось, что в каждом пятом (22%) из протестированных мобильных банковских приложений используются незащищенные протоколы передач информации, а в каждом четвертом (25%) производится небезопасная аутентификация WEB-сервера. В 87% продуктов специалистами была выявлена недостаточная защита пакета приложения и его компонентов, в 78% – отсутствие проверок наличия несанкционированного привилегированного доступа к мобильному устройству. Больше всего критичных «дыр» было обнаружено в Android-приложениях, меньше всего – в программных решениях, работающих в среде iOS.

Подтвердилась тенденция, отмеченная экспертами в традиционных ежегодных отчетах в области безопасности систем дистанционного банковского обслуживания (ДБО) . Разработчики мобильных банк-клиентов не уделяют достаточного внимания вопросам безопасности приложений, не следуют руководствам по безопасной разработке. Зачастую отсутствуют процессы разработки безопасного кода и архитектуры. Оказалось, что все рассмотренные приложения содержат хотя бы одну уязвимость, позволяющую либо перехватить данные, передающиеся между клиентом и сервером, либо напрямую эксплуатировать уязвимости устройства и самого мобильного приложения. Так, 35% мобильных банков для iOS и 15% мобильных банков для Android содержат уязвимости, связанные с некорректной работой SSL, а это означает возможность перехвата критичных платежных данных с помощью атаки "человек посередине". 22% приложений для iOS потенциально уязвимы к SQL-инъекции, что создает риск кражи всей информации о платежах с помощью нескольких несложных запросов. 70% приложений для iOS и 20% приложений для Android потенциально уязвимы к XSS - одной из самых популярных атак, позволяющей ввести в заблуждение пользователя мобильного банк-клиента и таким образом, например, украсть его аутентификационные данные. 45% приложений для iOS потенциально уязвимы к ХХЕ-атакам, особенно опасным для устройств, подвергнутым столь популярной в России операции jailbreak. Около 22% приложений для Android неправильно используют механизмы межпроцессного взаимодействия, тем самым фактически позволяя сторонним приложениям обращаться к критичным банковским данным .

Защита.

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

Атака.

Для атаки через вредоносное приложение нарушителю необходимо установить вредоносное приложение, используя методы социальной инженерии или атаку Drive-by-Download.

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

Защита.

Необходимо обновлять ПО на устройстве, использовать программные средства защиты и повышать осведомленность пользователей в вопросах ИБ.

Атаки на канал связи.

В ходе классической атаки "человек посередине" перехватываются данные между устройством клиента и сервером. Для этого необходимо находиться в одной сети с жертвой, например в публичной сети Wi-Fi, или использовать поддельные беспроводные точки доступа и поддельные базовые станции. Предпосылки – уязвимость в мобильном приложении, некорректная работа с шифрованием передаваемых данных или полное отсутствие шифрования данных. Самый распространенный пример – неправильная работа с SSL. В результате злоумышленник может прослушивать и подменять передаваемые данные, что может в итоге привести к краже денежных средств со счета клиента.

Защита .

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

Стоит также отметить, что jailbreak устройства (iOS) или наличие root-доступа на устройстве (Android) пользователя значительно снижает уровень защищенности устройства и упрощает атаку для злоумышленника.

Выводы:

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

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

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

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

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

Современные средства защиты для мобильных устройств – антивирусы, MDM-решения и т.д. – могут сократить риск, но не решить весь спектр проблем. Безопасность должна внедряться еще на этапе проектирования системы и присутствовать на всех этапах жизненного цикла программы, включая этап разработки и внедрения. Необходимо осуществлять аудит кода, анализ защищенности приложения, тестирование на проникновение.

1. Осведомлять программистов о вопросах безопасности.

2. Закладывать безопасность в архитектуру.

3. Проводить аудит кода.

4. Проводить анализ защищенности приложения.

5. Применять параметры компилятора, связанные с безопасностью.

6. Контролировать распространение приложения в сети Интернет.

7. Быстро закрывать уязвимости и выпускать обновления.

Литература

Якушин Петр. Безопасность мобильного предприятия// Открытые системы № 01, 2013.
Аналитический Центр InfoWatch. Глобальное исследование утечек корпоративной информации и конфиденциальных данных, 2014.
Шетько Николай. Взлом сотовых сетей GSM: расставляем точки над «i»// ET CETERA – серия цифровых журналов, распространяемых по подписке № 32, 2013.
Коржов Валерий. Скорость и безопасность в LTE// «Сети/network world» №6, 2012.
802.11i-2004 – IEEE Standard for Local and Metropolitan Area Networks– Specific requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 6: Medium Access Control (MAC) Security Enhancements, 2004.
Белорусов Д.И. Wi-Fi – сети и угрозы информационной безопасности/ Д.И. Белорусов, М.С. Корешков // СПЕЦИАЛЬНАЯ ТЕХНИКА № 6, 2009; с. 2-6.
Трифонов Дмитрий. Как взламывают корпоративный Wi-Fi: новые возможности. [Электр. рес. ]// Исследовательский центр Positive Technologies. URL: http://www.securitylab.ru/analytics/471816.php .
Безопасность приложений. Аналитический отчёт IBM X-Force.[Электронный ресурс ]//Постоянный URL: http://www.ibm.com/software/products/ru/category/application-security .
Анализ защищенности мобильных приложений (клиентская часть). Аналитический отчёт компании Digital Security.

[Электронный ресурс ]//Постоянный URL: http://www.dsec.ru/services/security-analysis/mobile-applications/ .

10. 40% мобильных банковских приложений обладают критичными уязвимостям. Аналитический отчёт компании «Инфосистемы Джет»/ [Электронный ресурс ]// Постоянный URL: http://servernews.ru/910462

11.Миноженко Александр. Безопасность мобильных банковских приложений/ [Электронный ресурс]// Постоянный URL:

Ведущий исследователь ИБ в Digital Security

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

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

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

Так, 35% мобильных банков для iOS и 15% мобильных банков для Android содержат уязвимости, связанные с некорректной работой SSL, а это означает возможность перехвата критичных платежных данных с помощью атаки "человек посередине". 22% приложений для iOS потенциально уязвимы к SQL-инъекции, что создает риск кражи всей информации о платежах с помощью нескольких несложных запросов. 70% приложений для iOS и 20% приложений для Android потенциально уязвимы к XSS - одной из самых популярных атак, позволяющей ввести в заблуждение пользователя мобильного банк-клиента и таким образом, например, украсть его аутентификационные данные. 45% приложений для iOS потенциально уязвимы к ХХЕ-атакам, особенно опасным для устройств, подвергнутым столь популярной в России операции jailbreak. Около 22% приложений для Android неправильно используют механизмы межпроцессного взаимодействия, тем самым фактически позволяя сторонним приложениям обращаться к критичным банковским данным.

Мобильный мир

Учитывая растущую популярность мобильных банковских приложений, существуют серьезные опасения относительно их безопасности, ведь бреши в системах защиты могут повлечь за собой финансовые потери сотен десятков пользователей. Команда Digital Security провела исследование, собрав угрозы, уязвимости и векторы атак для банк-клиентов, разработанных для мобильных платформ (Android и iOS). Были изучены мобильные банковские приложения более чем 30 российских банков, включая банки "Санкт-Петербург", "Балтика", Банк24.ру, БФА, ВТБ; ВТБ24, Газпромбанк. Инвестбанк, Крайинвест-банк, КС Банк, Мастер-Банк МДМ Банк, Московский Индустриальный Банк, Московский Кредитный Банк МТС-Банк, НОМОС-Банк; ПримСоцБанк, Промсвязьбанк, Росбанк, РосЕвро-Банк, "Русский Стандарт". Сбербанк и др.

Популярные мобильные ОС

Почему изучались именно эти операционные системы? ОС Android и iOS наиболее распространены на сегодняшний день и имеют наибольшее количество мобильных банковских приложений в своих магазинах (Google Play и Арр Store соответственно).

ОС Windows Phone достаточно молода и еще не так распространена среди пользователей, но уже сейчас имеет в своем магазине (Windows Store) небольшое количество мобильных банковских приложений. В данное исследование приложения для ОС Windows Phone не включены из-за их малого количества на данный момент (в Windows Store их всего 9). Но с учетом появления Windows Phone 8, содержащей новую модель разработки, позволяющую (благодаря легкому портированию) одновременно разрабатывать приложения для обычной ОС Windows 8 и мобильной, можно ожидать роста популярности разработки под Windows Phone 8.

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

По месту расположения приложения:

SIM-приложения - приложение на SIM-карте, написанное в соответствии со стандартом SIM Application Toolkit (STK);
Web-приложения - специальная версия Web-сайта;
мобильные приложения - приложения, разработанные для определенной мобильной ОС с использованием специализированного API, устанавливаемого в смартфон.

По типу используемой технологии взаимодействия с сервером:

сетевые приложения - используют собственный протокол общения поверх TCP/IP, например HTTP;
SMS-приложения - приложения на основе SMS (Short Messaging Service).
Приложение обменивается с сервером информацией с помощью коротких текстовых сообщений;
USSD-приложения - приложения на основе USSD (Unstructured Supplementary Service Data). Сервис основывается на передаче коротких сообщений, схожих с SMS, но имеет ряд отличий;
IVR-приложения - приложения, базирующиеся на технологии IVR (Interactive Voice Response). Система основана на заранее записанных голосовых сообщениях и тональном наборе.

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

Типы приложений для мобильного банкинга

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

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

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

Методы оценки безопасности клиентского приложения:

Динамический анализ:
- отладка запущенного приложения (на эмуляторе или устройстве);
- фаззинг;
- анализ сетевого трафика;
- анализ взаимодействия с файловой системой;
- анализ памяти приложения.
Статический анализ: анализ исходного кода (если доступен);
- обратное проектирование (Reverse Engineering);
- дизассемблирование;
- декомпиляция;
- анализ полученного представления на слабые участки кода.

Модели нарушителя

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

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

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

Атаки на серверную часть ничем не отличаются от атак на обычные системы ДБО.

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

физического доступа к устройству;
вредоносного приложения на устройстве;
возможности контролировать канал, например в результате атаки "человек посередине".

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

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

Для атаки через вредоносное приложение необходимо установить вредоносное приложение, используя методы социальной инженерии или через атаку Drive-by-Download.

Защита: обновлять ПО на устройстве, использовать программные средства защиты и повышать осведомленность пользователей в вопросах ИБ.

Атаки на канал связи: в ходе классической атаки "человек посередине" перехватываются данные между устройством клиента и сервером. Для этого необходимо находиться в одной сети с жертвой, например в публичной сети Wi-Fi, или использовать поддельные беспроводные точки доступа и поддельные базовые станции. Необходима уязвимость в мобильном приложении некорректная работа с шифрованием передаваемых данных или полное отсутствие шифрования данных. Самый распространенный пример - неправильная работа с SSL. В результате злоумышленник может прослушивать и подменять передаваемые данные, что может в итоге привести к краже денежных средств со счета клиента.

Защита: правильная реализация работы с SSL. Также рекомендуется в мобильном приложении при подключении к серверу доверять только SSL-сертификату банка. Это поможет в случае компрометации корневого центра сертификации.

Выводы

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

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

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

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

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

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

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

В прошлом году исследовательский центр Digital Security выпустил отчет «Результаты исследования безопасности банк-клиентов российских производителей за период 2009-2011 гг.», где мы поделились своим опытом анализа систем ДБО и неутешительными результатами оценки их безопасности.

Мы не стоим на месте и стараемся делать сегодня то, что будет востребовано завтра. В этом исследовании описаны угрозы, уязвимости и векторы атак для банк-клиентов, разработанных для мобильных платформ (Android и iOS).

Идет активное развитие мобильных технологий, современные требования бизнеса таковы, что доступ к информации должен осуществляться быстро, надежно и из любой точки мира. Платежные приложения не являются исключением, и они постепенно появляются на наших мобильных устройствах (смартфонах, планшетах и т.д.). Мобильные устройства пока еще недостаточно изучены, и каждая мобильная ОС (Android, iOS, Windows Phone, Symbian, BlackBerry и т.п.) имеет свою специфику, поэтому в каждой из них можно обнаружить большое количество как новых уязвимостей, так и хорошо известных.

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

Альфа-Банк,

Банк «Санкт-Петербург» Банк «Балтика», Банк24.ру,

Банк БФА,

ВТБ, ВТБ 24, Газпромбанк, Инвестбанк, Крайинвестбанк,

Мастер-Банк,

МДМ Банк,

Московский Индустриальный Банк,

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

МТС-Банк,

Народный кредит,

НОМОС-Банк,

Первобанк,

ПримСоцБанк,

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

РосЕвроБанк,

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

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

Сбербанк,

Связь-Банк,

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

Тинькофф Кредитные Системы, УБРиР,

Финансовая группа Лайф,

Ханты-Мансийский Банк, ЮниКредитБанк

и другие.

Мобильные банковские приложения для iOS

Лишь небольшое количество мобильных банков реализуют механизмы защиты. Все рассмотренные приложения содержат хотя бы одну уязвимость.

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

Мобильные банковские приложения для Android

На основе полученных результатов мы составили топ-10 мобильных банков для iOS и Android с наименьшим числом угроз. При составлении рейтинга программе присваивался 1 балл при наличии защитного механизма или отсутствии небезопасного API определенного класса, и 1 балл вычитался в противоположном случае. Стоит заметить, что 4 банка попали в оба рейтинга.

Топ-10 для iOS

Топ-10 для Android

Мастер-Банк

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

Финансовая группа Лайф

РосЕвроБанк

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

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

Примсоцбанк

Сбербанк

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

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

Инвестбанк

OC Android и iOS наиболее распространены на сегодняшний день и имеют наибольшее количество мобильных банковских приложений в своих магазинах (Google Play и App Store соответственно).

ОС Windows Phone достаточно молода и еще не так распространена среди пользователей, но уже сейчас имеет в своем магазине (Windows Store) небольшое количество мобильных банковских приложений. В данное исследование банковские приложения для ОС Windows Phone не включены из-за их малого количества на данный момент (в Windows Store их всего 9). Но с учетом появления Windows Phone 8, содержащей новую модель разработки, позволяющую (благодаря легкому портированию) одновременно разрабатывать приложения для обычной ОС Windows 8 и мобильной, можно ожидать рост популярности разработки под Windows Phone 8.

По месту расположения приложения:

SIM-приложения - приложение на SIM-карте, написанное в соответствии со стандартом SIM Application Toolkit (STK);

Web-приложения - специальная версия web-сайта;

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

По типу используемой технологии взаимодействия с сервером:

Сетевые приложения - используют собственный протокол общения поверх TCP/IP, например HTTP;

SMS-приложения - приложение на основе SMS (Short Messaging Service). Приложение обменивается с сервером информацией с помощью коротких текстовых сообщений;

USSD-приложения - приложение на основе USSD (Unstructured Supplementary Service Data). Сервис основывается на передаче коротких сообщений, схожих с SMS, но имеет ряд отличий;

IVR-приложения - приложение, базирующееся на технологии IVR (Interactive Voice Response). Система основана на заранее записанных голосовых сообщениях и тональном наборе.

Типы приложений для мобильного банкинга

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

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

Методы оценки безопасности клиентского приложения:

1. Динамический анализ:

· Отладка запущенного приложения (на эмуляторе или устройстве);

Фаззинг;
Анализ сетевого трафика;

· Анализ взаимодействия с файловой системой;

Анализ памяти приложения.

2. Статический анализ:

· Анализ исходного кода (если доступен); Обратное проектирование (Reverse Engineering):

o Дизассемблирование;

o Декомпиляция;

· Анализ полученного представления на слабые участки кода.

2. Злоумышленник, не имеющий доступ к устройству, находящийся рядом с жертвой и способный провести атаку типа «человек посередине».

Атаки на серверную часть ничем не отличаются от атак на обычные системы ДБО, рассмотренных в отчете Digital Security «Результаты исследования безопасности банк-клиентов российских производителей за период 2009-2011 гг.»

iOS - это мобильная операционная система от компании Apple. Данная операционная система предназначена только для устройств от компании Apple: iPod, iPhone, iPad и Apple TV. iOS базируется на Mac OS X. Для распространения приложений для данной платформы используется специальный магазин – App Store.

Для разработки используется язык Objective-C, который является компилируемым объектно-ориентированным языком программирования. Objective-C построен на основе языка программирования Си и парадигм языка программирования Smalltalk.

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

График появления банковских мобильных приложений для iOS

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

Из последующих версий SDK данные типы шифрования убрали.

Параметр компиляции PIE

PIE (Position Independent Executable) - это специальный механизм, который задается параметром компиляции и относится к классу параметров безопасности, нацеленных на усложнение процесса эксплуатации ошибок, связанных с некорректной работой с памятью. Позволяет использовать все преимущества ASLR (Address Space Layout Randomization).

ARC (Automatic Reference Counting) - это специальный механизм, который задается параметром компиляции и который косвенно можно отнести к классу параметров безопасности. Берет на себя работу по управлению памятью и помогает избежать ошибок, связанных с утечкой памяти и неправильной работой с указателями, приводящих к уязвимостям типа use-after-free и double free.

Некорректная работа с SSL

Для работы с SSL-соединением существует ряд функций, использование которых приводит к отключению проверки сертификата. Разработчики используют их в процессе тестирования приложения и часто забывают убрать соответствующий код перед публикацией приложения в App Store. В результате злоумышленник способен провести атаку «человек посередине», прослушивать данные между клиентом и сервером и манипулировать ими в своих целях. Например, он сможет подменять данные платежей или переводов.

Keychain в iOS - это специальное зашифрованное хранилище, предназначенное для хранения критичной информации приложений.

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

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

XXE (XML eXternal Entity) - атака, с помощью которой злоумышленник может внедрять внешние или внутренние сущности (entities) в XML-запрос, и они будут соответствующим образом обработаны системой.

В результате атаки злоумышленник имеет возможность читать произвольные файлы в директории приложения, если устройство не имеет jailbreak, и любые файлы, если устройство имеет jailbreak (при jailbreak механизм sandbox выключен). Это значит, что возможно чтение любых конфиденциальных файлов приложения. Кроме того, злоумышленник имеет возможность вызвать отказ приложения в обслуживании.

Характеристика

Количество

Потенциально уязвимо к XXE

Отсутствие XXE

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

Характеристика

Количество

Потенциально уязвимо к обходу директории

Отсутствие уязвимости обхода директории

Функция NSLog используется для записи отладочной информации в общий системный лог. Любое приложение может читать и записывать данные из этого лога.

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

Характеристика

Количество

Используют

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

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

Характеристика

Скриншоты

Автокоррекция

Безопасное использование

Небезопасное использование

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

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

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

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

Необходимо перед релизом новой версии приложения в App Store внимательно просматривать итоговое приложение на наличие конфиденциальной информации.

Из всех исследуемых приложений:

Ни одно не использовало антиотладочные техники;

Ни одно не использовало техники обфускации кода;

Два приложения детектировали наличие jailbreak на устройстве.

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

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

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

Результаты исследования безопасности приложений под Android

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

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

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

Анализ AndroidManifest.xml

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

	Количество приложений с этими правами
android.permission.INTERNET
android.permission.ACCESS_FINE_LOCATION
android.permission.ACCESS_COARSE_LOCATION
android.permission.ACCESS_NETWORK_STATE
android.permission.READ_PHONE_STATE
Android.permission.CALL_PHONE
Android.permission.WRITE_EXTERNAL_STORAGE
android.permission.RECEIVE_SMS
Android.permission.READ_CONTACTS
android.permission.ACCESS_MOCK_LOCATION
android.permission.VIBRATE
android.permission.ACCESS_WIFI_STATE
android.permission.SEND_SMS
android.permission.ACCESS_GPS
android.permission.CHANGE_CONFIGURATION
Android.permission.CAMERA
android.permission.CONTROL_LOCATION_UPDATES
Android.permission.READ_SMS
Android.permission.WRITE_CONTACTS
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.CHANGE_WIFI_STATE
Android.permission.READ_LOGS
android.permission.WRITE_SMS
Android.permission.BROADCAST_STICKY
android.permission.GET_TASKS
Android.permission.WRITE_SETTINGS

В таблице красным отмечены критичные права приложения, которые позволяют читать логи устройства, настройки устройства и нужны при использовании в небезопасных API-вызовах. Например, право WRITE_EXTERNAL_STORAGE позволяет читать и записывать данные на внешнюю SD-карту. При этом в Android не действует разграничение прав для приложений на SD-карту: любое приложение может считать с нее любые данные. Следовательно, стороннее приложение может прочитать критичные данные клиента с SD-карты.

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

Данный график отображает, сколько приложений имеют права высокой, средней и низкой критичности.

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

СontentProvider предоставляет данные другим приложениям.

Receivers являются обработчиками сообщений от других процессов.

Services – это службы в Android, которые работают как фоновые процессы.

Activities – визуальный компонент приложения, который отображает интерфейс. Неправильная валидация входящих данных в этих компонентах может привести к уязвимостям SQL-инъекции, XSS, утечки данных и другим.

Некоторые приложения получают и используют уникальную критичную информацию телефона, такую как IMEI или IMSI. Данная информация считается личной информацией, поскольку идентифицирует абонента и может использоваться для его отслеживания. Кроме того, IMEI и IMSI нельзя использовать в качестве уникального идентификатора, поскольку сторонние приложения также могут его получить.

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

Характеристика

Количество

Получают IMEI/IMSI

Не используют IMEI/IMSI

Некоторые приложения использует компонент webView. Данный компонент позволяет отображать HTML- страницы, находящиеся локально или удаленно. В нем есть функции, которые позволяют использовать JavaScript, плагин Flash и доступ к файловой системе. По умолчанию эти функции отключены, поскольку при соединении по незащищенному протоколу HTTP или при наличии уязвимости XSS на удаленном сервере злоумышленник сможет выполнить произвольный JavaScript-код. Мобильный банк при заходе на страничку с этой уязвимостью загрузит вредоносный JavaScript, и злоумышленник получит частичный контроль над мобильным банком клиента.

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

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

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

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

Характеристика

Количество

Есть публичные файлы

Нет публичных файлов

Некоторые приложения используют парсер XML с поддержкой External Entities. В случае обработки данным парсером нефильтрованного ввода злоумышленник может провести атаку типа XXE и прочитать произвольный файл приложения.

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

Характеристика

Количество

Потенциальная XXE

Отсутствует XXE

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

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

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

Устройства с root-доступом значительно больше подвержены угрозам безопасности. Поэтому для обеспечения безопасности следует проводить проверку на наличие root-доступа на устройстве. Из рассмотренных приложений только одно проверяло наличие root-доступа на смартфоне.

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

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

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

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

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

1. Осведомлять программистов по вопросам безопасности;

2. Закладывать безопасность в архитектуру;

3. Проводить аудит кода;

4. Проводить анализ защищенности приложения;

5. Применять параметры компилятора, связанные с безопасностью;

6. Контролировать распространение приложения в сети Интернет;

7. Быстро закрывать уязвимости и выпускать обновления.

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

Анализ содержимого магазинов приложений для Apple- и Android-устройств выявил 14тыс. сомнительных программ.

Всего же эксперты изучили порядка 400 тыс. приложений, которые обычно устанавливаются сотрудниками корпораций, специализирующихся на самых разных отраслях - финансовых услугах, СМИ, телекоммуникациях и так далее. Выяснилось, что 3% из исследованных программ сталкиваются с проблемами безопасности.

В частности 85% такого рода приложений не обеспечивают надежную сохранность важной конфиденциальной информации - например, такой, как местоположение абонента, история, контакты, отметки в календаре, SMS сообщения, идентификаторы устройств.

Кроме того 32% из 14 тыс. приложений выполняют подозрительные действия. Скажем эти программы требуют права администратора, что в конечном счете может позволить им удалять, устанавливать или запускать другие приложения, прослушивать телефонные разговоры, отключать антивирусное ПО, просматривать данные КЭШа, куда возможно, попадут и банковские пароли.

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

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

Отчет, опубликованный компанией FireEye, рисует мрачную картину уязвимости приложений для iOS и Android, которые были загружены в совокупности более 6 млрд. раз. Это по-прежнему так, по данным FireEye, даже после того, как Apple выпустила патч, исправляющий уязвимости iOS: «Даже после патчей для Android и iOS такие приложения все еще уязвимы для FREAK, когда устройство подключается к серверам, которые принимают шифры RSA_EXPORT».

Атака FREAK возможна, потому что серверы можно вынудить принимать 512-битные ключи RSA, одобренные правительством США для отправки на экспорт (устаревший артефакт, который как считалось, может перехватывать зашифрованный трафик и дешифровывать его, используя достаточно скромные вычислительные ресурсы).

FireEye сообщила, что просканировала 11 тыс. приложений в Google Play, каждое из которых было скачано не меньше миллиона раз, и обнаружила 1228 приложений, подверженных риску из-за использования уязвимой библиотеки OpenSSL для подключения к уязвимому серверу. 664 из них использовали библиотеку OpenSSL, идущую с Android, а 564 - библиотеку, скомпилированную отдельно. По данным FireEye, на стороне iOS проблема менее серьезна: из 14 тыс. сканированных приложений 771 подключалось к уязвимым серверам HTTPS. «Эти приложения уязвимы для атак FREAK под iOS версии ниже, чем 8.2, - написали исследователи. - Семь приложений из этих 771 пользуются собственными уязвимыми версиями OpenSSL, и они остаются уязвимыми и на iOS 8.2». Большинство уязвимых приложений попадают в категории, которые влияют на неприкосновенность частной жизни и информационную безопасность пользователей, и включают в себя фото- и видео-приложения, приложения социальных сетей, приложения, касающиеся здоровья и фитнеса, финансов, коммуникаций, шопинга, образа жизни, бизнеса, а также медицинские приложения. 512-битные ключи являются артефактом криптографических воин - правительство США одобрило их для экспортного использования. Большинство экспертов полагали, что поддержка ослабленных криптопакетов была удалена с большинства серверов, но это было не так до сообщения, сделанного Microsoft Research и INRIA (национальный исследовательский институт во Франции, работающий в области компьютерных наук, теории управления и прикладной математики).

Исследование Королевского колледжа так же продемонстрировало, что администраторы серверов и крупные технологические провайдеры оперативно искореняют поддержку ослабленных криптопакетов. Изначальные расчеты показывали 26% серверов, уязвимых для FREAK, но Королевский колледж определил, что это число упало примерно до 11%. При этом эксплойты FREAK имеют свои ограничения, согласно мнению экспертов, так как требуют активного вмешательства злоумышленника в TLS - подключения, то есть у них уже должен быть доступ к серверу. Тод Бредсли (Tod Beardsley), главный инженер в Rapid7, сообщил, что практический эффект от этого бага ограничен. «Из-за требования активного «человека посередине» этот баг может быть весьма полезен для шпионов, атакующих определенных пользователей в среде сетей высокого уровня безопасности, - сказал он. - Это не очень полезно для типичных интернет-преступников, так как есть гораздо более простые способы, чтобы перенаправлять и собирать пользовательский трафик при разных уровнях сложности».

Так, 35% мобильных банков для iOS и 15% мобильных банков для Android содержат уязвимости, связанные с некорректной работой SSL, а это означает возможность перехвата критичных платежных данных с помощью атаки «человек посередине». 22% приложений для iOS потенциально уязвимы к SQL-инъекциям, что создает риск кражи всей информации о платежах с помощью нескольких несложных запросов. 70% приложений для iOS и 20% приложений для Android потенциально уязвимы к XSS - одной из самых популярных атак, позволяющей ввести в заблуждение пользователя мобильного банк-клиента и таким образом, например, украсть его аутентификационные данные. 45% приложений для iOS потенциально уязвимы для XXE-атакам, особенно опасным для устройств, подвергнутым столь популярной в Росси операции jailbreak. Около 22% приложений для Android неправильно используют механизмы межпроцессного взаимодействия, тем самым фактически позволяя сторонним приложениям обращаться к критичным банковским данным.

Почему подвергались атаке именно эти операционные системы? OC Android и iOS наиболее распространены на сегодняшний день и имеют наибольшее количество мобильных банковских приложений в своих магазинах Google Play и App Store соответственно). При физическом доступе злоумышленник может получить доступ к файловой системе. Если приложение хранит аутентификационные данные или другие критичные данные в открытом виде, то для злоумышленника несложно получить эти данные и украсть деньги.

Для атаки через вредоносное приложение необходимо установить вредоносное программное обеспечение, используя метод социальной инженерии или через атаку Drive-by-Dowload.

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

Атаки на канал связи: в ходе классической атаки «человек посередине» перехватываются данные между устройством клиента и сервером. Для этого необходимо находиться в одной сети с жертвой, например в публичной сети Wi-Fi или использовать поддельные беспроводные точки доступа и поддельные базовые станции. Необходима уязвимость в мобильном приложении некорректная работа с шифрованием передаваемых данных или полное отсутствие шифрования данных. Самый распространенный пример - неправильная работа с SSL. В результате злоумышленник может прослушивать и подменять передаваемые данные, что может в итоге привести к краже денежных средств со счета клиента. Стоит так же отметить, что jailbreak устройство (iOS) или наличие root-доступа на устройстве (Android) пользователя значительно снижает уровень защищенности устройства и упрощает атаку для злоумышленника.

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

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

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

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

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

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

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

Александр Миноженко
Ведущий исследователь ИБ в Digital Security

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

Мобильный мир

Популярные мобильные ОС
Почему изучались именно эти операционные системы? ОС Android и iOS наиболее распространены на сегодняшний день и имеют наибольшее количество мобильных банковских приложений в своих магазинах (Google Play и Арр Store соответственно).

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

По месту расположения приложения:

SIM-приложения - приложение на SIM-карте, написанное в соответствии со стандартом SIM Application Toolkit (STK);
Web-приложения - специальная версия Web-сайта;
мобильные приложения - приложения, разработанные для определенной мобильной ОС с использованием специализированного API, устанавливаемого в смартфон.

По типу используемой технологии взаимодействия с сервером:

сетевые приложения - используют собственный протокол общения поверх TCP/IP, например HTTP;
SMS-приложения - приложения на основе SMS (Short Messaging Service).
Приложение обменивается с сервером информацией с помощью коротких текстовых сообщений;
USSD-приложения - приложения на основе USSD (Unstructured Supplementary Service Data). Сервис основывается на передаче коротких сообщений, схожих с SMS, но имеет ряд отличий;
IVR-приложения - приложения, базирующиеся на технологии IVR (Interactive Voice Response). Система основана на заранее записанных голосовых сообщениях и тональном наборе.

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

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

Методы оценки безопасности клиентского приложения:

Динамический анализ:
- отладка запущенного приложения (на эмуляторе или устройстве);
- фаззинг;
- анализ сетевого трафика;
- анализ взаимодействия с файловой системой;
- анализ памяти приложения.
Статический анализ: анализ исходного кода (если доступен);
- обратное проектирование (Reverse Engineering);
- дизассемблирование;
- декомпиляция;
- анализ полученного представления на слабые участки кода.

Модели нарушителя
1. Злоумышленник, имеющий физический доступ к устройству клиента. При этом на устройстве не включена блокировка экрана и не используется шифрование.

Атаки на серверную часть ничем не отличаются от атак на обычные системы ДБО.

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

физического доступа к устройству;
вредоносного приложения на устройстве;
возможности контролировать канал, например в результате атаки "человек посередине".

Выводы

Проводить аудит кода.

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