BIS Journal №3(10)/2013

15 июля, 2013

High tech, low life

Специалисты по информационной безопасности вряд ли нуждаются в особых доказательствах стремительного роста популярности мобильных технологий и, следовательно, связанных с ними угроз. В отчёте корпорации Cisco, опубликованном в феврале 2013 года, предсказан лавинообразный рост мобильного трафика в ближайшие несколько лет. К 2017 году объём интернет-трафика, проходящего через смартфоны и планшеты, будет в 3 раза большим, чем через настольные компьютеры. В связи с бурным ростом и развитием мобильных платформ растёт популярность и мобильного банкинга.

ЦЕЛИ ИССЛЕДОВАНИЯ

В течение 2012 года исследовательский центр Digital Security проводил анализ разнообразных мобильных приложений для дистанционного банковского обслуживания – ДБО. Очевидно, что уже через несколько лет именно они станут одним из основных средств работы с банковским счетом, что неминуемо привлечет живой интерес злоумышленников. В то же время уровень защищённости мобильного банка в большинстве случаев не превосходит уровень защищённости обычных мобильных приложений, в то время как связанные с ними риски подразумевают повышенные требования к безопасности. Угрозы безопасности мобильных банков создают риски компрометации ключевых данных пользователей, хищения денежных средств и нанесения ущерба репутации банка.

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

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

МЕТОДИКА

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

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

  • Альфа-Банк
  • Банк «Санкт-Петербург»
  • Банк «Балтика»
  • Банк24.ру
  • Банк БФА
  • Банк ВТБ . ВТБ 24
  • Газпромбанк
  • Инвестбанк
  • Крайинвестбанк
  • КС Банк
  • Мастер-Банк
  • МДМ Банк
  • Московский Индустриальный Банк
  • Московский Кредитный Банк
  • Мордовпромстройбанк
  • МТС-Банк
  • Народный кредит
  • НОМОС-Банк
  • Первобанк
  • ПримСоцБанк
  • Промсвязьбанк
  • Росбанк
  • РосЕвроБанк
  • РосИнтерБанк
  • Россельхозбанк
  • Русский Стандарт
  • Сбербанк России
  • Связь-Банк
  • СИАБ
  • Смоленский Банк
  • Тинькофф Кредитные Системы
  • УБРиР
  • Финансовая группа Лайф
  • Ханты-Мансийский Банк
  • ЮниКредитБанк

и другие.

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

Следует отметить, что описанные проблемы составляют не более 20–30% всей совокупности проблем безопасности мобильного банкинга. Не проводился динамический анализ кода, не исследовались уязвимости серверной части и недостатки взаимодействия клиента и сервера. Таким образом, не было возможности дать комплексную оценку безопасности мобильного банкинга как услуги того или иного банка.

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

ВОЗМОЖНЫЕ АТАКИ

У злоумышленников есть множество направлений для атак. При этом затраты на проведение атаки могут быть совсем низкими по сравнению с возможной выгодой. Атаки на клиентскую часть удалённого банкинга возможны при наличии физического доступа к устройству, вредоносного приложения на устройстве или возможности контролировать канал, например, в результате атаки типа «человек посередине» (Man-in-the-Middle).

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

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

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

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

Самый распространенный пример – неправильная работа с SSL позволяет злоумышленнику считывать и подменять передаваемые данные, в том числе и для кражи денежных средств со счёта клиента. Поэтому при работе с мобильным приложением при подключении к серверу, чтобы предохраниться от возможной компрометации корневого центра сертификации, рекомендуется доверять только SSL-сертификату банка. Стоит также отметить, что jailbreak устройства (iOS) или наличие root-доступа на устройстве (Android) пользователя значительно снижает уровень защищённости, упрощают злоумышленнику атаку.

РЕЗУЛЬТАТЫ

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

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

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

Если говорить о безопасности канала связи между клиентом и сервером, многие разработчики попросту оставляют проверку SSL-сертификата отключенной после отладки приложения. Этим грешат 35% мобильных банков для iOS и 15% мобильных банков для Android... В результате злоумышленник способен провести атаку «человек посередине», манипулировать по своему усмотрению данными, перехваченными между клиентом и сервером. Например, чтобы подменять данные платежей, денежных переводов. Больше четверти приложений для Android не используют защищённое SSL-соединение в принципе, – что является прямым игнорированием азов web-безопасности.

Вообще, халатность при доработке тестовой версии приложения до рабочей, похоже, характерная черта разработчиков мобильных банк-клиентов. В процессе анализа приложений было найдено много отладочной информации, позволяющей составить представление о внутренней инфраструктуре разработчика приложения. Также были найдены файлы для внутреннего использования с перепиской разработчиков, отметками о состоянии закрытия той или иной ошибки или реализации нового функционала. 80% приложений в Apple Store используют функцию NSLog для записи отладочной информации в общий системный лог. Достаточно часто в него попадает критично важная информация, доступ к которой может полностью или частично скомпрометировать банковские данные пользователя. А ведь читать данные общесистемного лога может любое приложение!..

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

  • 75% приложений под iOS могут хранить критичную информацию (логин, пароль, PIN, номер счета и т.д.) на скриншотах, 60% сохраняют её в словарях автокоррекции и буфере обмена;
  • 22% приложений для iOS и 20% для Android потенциально уязвимы к SQL-инъекции, что создаёт риск кражи всей информации о платежах с помощью нескольких несложных запросов;
  • 70% приложений для iOS и 20% для Android потенциально уязвимы к XSS – одной из самых популярных атак, позволяющей ввести в заблуждение пользователя мобильного банк-клиента и, в частности, украсть его аутентификационные данные;
  • 45% приложений для iOS потенциально уязвимы к XXE-атакам, когда безобидный с первого взгляда XML-запрос подгружает в приложение вредоносные команды злоумышленника. Эти атаки особенно опасны для устройств, перенесших столь популярную в России операцию jailbreak.

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

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

Из всех проверенных программных продуктов под iOS ни один не использовал ни антиотладочные техники, ни обфускацию кода, для предотвращения «обратной разработки» приложения злоумышленником. Всего 2 приложения детектировали наличие jail-break на устройстве. Что касается защитных механизмов на Android-устройствах, то обфускацию кода использовали 25% приложений. Очевидно, потому, что, как известно, приложения для Android легко декомпилировать. Обнаружить root-доступ на смартфоне оказалось способно только одно приложение.

ВЫВОДЫ

На основе результатов статического анализа мы составили топ-10 мобильных банков для iOS и Android с наименьшим числом угроз для мобильной части. Следует ещё раз подчеркнуть, что высокие позиции в рейтинге говорят лишь о внимательном отношении банка к безопасности конкретного клиентского приложения для мобильного банкинга. Но не значат отсутствия риска для его клиентов в целом. Верно и обратное (см. таблицу):

ТОП-10

 

Для iOS

Для Android

1.

СИАБ

СИАБ

2.

Мастер-Банк

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

3.

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

МТС-Банк

4.

Банк24.ру

ФБИиР

5.

РосЕвроБанк

РосЕвроБанк

6.

Банк БФА

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

7.

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

Примсоцбанк

8.

Сбербанк

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

9.

МТС-Банк

МДМ-Банк

10.

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

Инвестбанк

ТАБЛИЦА. Рейтинг безопасности клиентских приложений мобильного банкинга.

РЕКОМЕНДАЦИИ ДЛЯ РАЗРАБОТЧИКОВ

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

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

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

  1. информировать программистов о вопросах безопасности;
  2. закладывать безопасность в архитектуру;
  3. проводить аудит кода;
  4. анализировать защищённость приложений;
  5. применять параметры компилятора, связанные с безопасностью;
  6. контролировать распространение приложения в сети интернет;
  7. быстро закрывать уязвимости и выпускать обновления.

Полный текст исследования доступен по ссылке: http://dsecrg.ruhttps://journal.ib-bank.ru/files/pub/pdf/Mobile_Banking_Security_2012.pdf.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

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

28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
28.03.2024
Почему путешествовать «налегке» не всегда хорошо
28.03.2024
«Тинькофф»: Несколько платёжных систем лучше, чем одна
28.03.2024
В РФ готовят базу для «усиленной блокировки» незаконного контента
28.03.2024
Термин «риск ИБ» некорректен по своей сути
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента
27.03.2024
Crypto Summit 2024. Трейдинг, майнинг и перспективы развития рынка ЦФА
27.03.2024
РКН начал работу по контролю за «симками» иностранцев

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

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