Мобильные приложения для работы с банками подвержены MitM-атаке


Zashita informaciiАналитики нашли уязвимость типа MitM примерно в каждом четвертом и каждом седьмом приложении для работы с мобильными банками под Android и iOS соответственно, которые предлагаются финансовыми организациями России.

Так, согласно результату исследования компании Digital Security, уязвимым к MitM-атаке является примерно каждое четвертое приложение для мобильного банкинга под Android (23%), а также каждое седьмое аналогичное приложение для iOS (14%).

Напомним, что MitM-атака (Man-in-the-Middle) - это перехват трафика между отправителем и адресатом, когда ни один из них не догадываются о наличии перехватчика. При этом злоумышленник может не только читать трафик, но и незаметно изменять его.

В ходе исследования было проверено 59 приложений для мобильного банкинга под Android и 61 приложение для iOS. Данные приложения используют финансовые организации на российском рынке.

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

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

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

Конечно, для защиты своих клиентов от MitM-атак, разработчики шифруют канал связи при помощи SSL, в которой клиент и сервер обмениваются сертификатами для установления подлинности друг друга.

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

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

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

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

  • Self-Signed - с использованием самоподписанных сертификатов;
  • CA-Signed Cert Hostame - с использованием сертификатов, выданных центрами сертификации.


Второй способ более надежный. Однако, еще более надежно — применение SSL Pinning, т.е., встраивание сертификата или публичного ключа, которому клиент доверяет при взаимодействии с сервером. При этом встраивание происходит непосредственно в само приложение.


Обновлено (15.05.2014 23:23)