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

01.11.2013

Оригинал: itsec.ru

Опубликовано: Журнал "Information Security/ Информационная безопасность" #4, 2013

Автор статьи – Александр Миноженко,

Ведущий исследователь ИБ в 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, устанавливаемые в смартфон для взаимодействия с соответствующим банковским сервисом, сейчас наиболее распространены, так как полностью используют возможности мобильного аппарата и имеют наиболее дружественный пользовательский интерфейс. Их мы и рассматривали в данном исследовании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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