Компания
300,25
рейтинг
20 мая 2015 в 13:21

Разработка → Главные уязвимости онлайн-банков: авторизация, аутентификация и Android



Уязвимости высокого уровня риска в исходном коде, а также серьезные недостатки механизмов аутентификации и авторизации во многих системах дистанционного банковского обслуживания позволяют проводить несанкционированные транзакции или даже получить полный контроль над системой со стороны внешнего злоумышленника, что может привести к существенным финансовым и репутационным потерям. Такие выводы содержатся в исследовании уязвимостей ДБО, обнаруженных экспертами Positive Technologies в 2013 и 2014 годах в ходе работ по анализу защищенности для ряда крупнейших российских банков. В данной статье мы представляем некоторые результаты этого исследования.

В рамках исследования было рассмотрено 28 систем дистанционного банковского обслуживания физических (77%) и юридических лиц (23%). Среди них были и мобильные системы ДБО, представленные серверной и клиентской частью (54%). Две трети систем (67%) являлись собственными разработками банков (использовались Java, C# и PHP), остальные были развернуты на базе платформ известных вендоров. Большинство систем ДБО (74%) находились в промышленной эксплуатации и были доступны для клиентов, а четверть ресурсов составляли тестовые стенды, готовые к переводу в эксплуатацию.

Общие результаты


Почти половина обнаруженных уязвимостей систем ДБО (44%) имеет высокий уровень риска. Примерно одинаковое количество уязвимостей имеют среднюю и низкую степень риска (26% и 30%). В целом, уязвимости высокого уровня риска были выявлены в 78% исследованных систем.

Большая часть уязвимостей (42%) связана с ошибками реализации механизмов защиты систем ДБО, заложенных разработчиками. В частности, к данной категории уязвимостей относятся недостатки механизмов идентификации, аутентификации и авторизации. На втором месте — уязвимости, связанные с ошибками в коде приложений (36%). Остальные уязвимости в основном связаны с недостатками конфигурации (22%).

Наиболее часто в системах ДБО встречались уязвимости, связанные с возможностью идентификации используемого ПО и с предсказуемыми форматами идентификаторов пользователей (57% систем). Более чем в половине систем (54%) обнаружены ошибки в программном коде типа «Межсайтовое выполнение сценариев». Если при наличии этой уязвимости в системе клиент банка перейдет по специально сформированной вредоносной ссылке, атакующий может получить доступ к системе ДБО с привилегиями данного клиента.

Распространены также уязвимости, позволяющие реализовать атаки на сессии пользователей (54% систем). Сюда относятся уязвимости, связанные с некорректным завершением сессий, некорректной настройкой cookie-параметров, возможностью параллельной работы нескольких сессий для одного пользователя, отсутствием привязки сессии к IP-адресу клиента и др. При успешной атаке злоумышленник может получить доступ к личному кабинету пользователя с его привилегиями.

В число наиболее распространенных вошла уязвимость высокой степени риска «Внедрение внешних сущностей XML», которая обнаружена в 46% систем. В результате ее эксплуатации злоумышленник может получить содержимое файлов, хранящихся на уязвимом сервере, данные об открытых сетевых портах узла, вызвать отказ в обслуживании всей системы ДБО, — а также, в ряде случаев, обратиться к произвольному узлу от лица уязвимого сервера и развить атаку.

Отказ в обслуживании системы ДБО может быть вызван с использованием различных уязвимостей в половине исследованных ресурсов (52%).



Самые распространенные уязвимости систем ДБО (доля систем)

Большинство распространенных уязвимостей имеет средний или низкий уровень риска. Тем не менее, в сочетании с особенностями функционирования конкретных систем ДБО это может привести к реализации серьезных угроз безопасности, включая кражу конфиденциальных данных (89% систем) и кражу денежных средств (46%).

Исследованные системы ДБО содержат также ряд существенных недостатков на уровне логики. К примеру, в ряде систем была обнаружена возможность атак на основе некорректного использования алгоритмов округления чисел. Скажем, злоумышленник переводит 0,29 рублей в доллары США. При стоимости одного доллара в 60 рублей, сумма в 0,29 рублей соответствует 0,00483333333333333333333333333333 долларов. Данная сумма будет округлена до двух знаков после запятой, т. е. до 0,01 доллара (один цент). Затем злоумышленник переводит 0,01 доллара обратно в рубли и получает 0,60 рублей. Таким образом злоумышленник «выигрывает» 0,31 рублей. В результате автоматизации данной процедуры, учитывая отсутствие ограничений по количеству транзакций в сутки и минимальному размеру транзакции, а также возможности эксплуатации уязвимости типа Race Condition («Состояние гонки»), — в ряде случаев злоумышленник может получать неограниченные суммы денежных средств.

Уязвимости по разработчикам


Уязвимостей высокой степени риска больше в системах ДБО, предоставленных вендорами (49%), чем в системах собственной разработки конкретного банка (40%). Кроме того, системы, поставляемые профессиональными разработчиками, в среднем содержат в 2,5 раза больше уязвимостей на уровне кода приложения, чем системы собственной разработки. Данный факт можно объяснить тем, что при использовании ПО от вендора банк в вопросах качества кода полагается главным образом на поставщика. При этом сложная архитектура, кроссплатформенность и большое количество функций систем ДБО не всегда позволяют вендору обеспечить должный уровень защищенности на уровне кода приложения.



Среднее количество уязвимостей в системах (в зависимости от разработчика)

Уязвимости механизмов защиты


Наиболее распространенным недостатком механизмов идентификации систем ДБО является предсказуемость формата идентификатора учетной записи (64% систем). Зная несколько существующих в системе идентификаторов, злоумышленник может вычислить механизм их формирования и подобрать нужный. 32% исследованных систем раскрывали информацию о существующих в системе учетных записях, возвращая различные ответы в зависимости от существования введенного идентификатора; в 20% случаев системы ДБО содержали обе вышеупомянутые уязвимости идентификации.

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



Уязвимости механизмов аутентификации (доли систем)

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



Недостатки механизмов авторизации (доля уязвимых систем)

Уязвимости мобильных клиентов


Клиентское ПО для ОС Android более уязвимо по сравнению с приложениями для iOS. В частности, критически опасные уязвимости содержатся в 70% приложений для Android и в 50% приложений для iOS.



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

В среднем каждое приложение на базе Android содержит 3,7 уязвимостей, в то время как для iOS-приложения данный показатель равен 2,3.

Наиболее часто в мобильных системах ДБО встречались уязвимости, связанные с небезопасной передачей данных (73%), далее идут недостаточная защита сессий (55%) и небезопасное хранение данных в мобильном приложении (41%).



Наиболее распространенные уязвимости клиентского ПО мобильных систем

Хотя наиболее распространенные уязвимости мобильных систем ДБО имеют среднюю или низкую степень риска, в ряде случаев совокупность выявленных недостатков позволяла реализовать серьезные угрозы безопасности. Например, одно из исследованных приложений отправляло широковещательное сообщение, содержащее полученное от банка SMS-сообщение (с одноразовым паролем для проведения транзакции), которое могло быть перехвачено сторонним приложением. Кроме того, данное мобильное приложение осуществляло журналирование важных данных, таких как учетная запись пользователя, вследствие чего при успешном заражении устройства пользователя вредоносным кодом атакующий мог получить полный доступ к аутентификационным данным и проводить транзакции от лица пользователя мобильного приложения.

Более детальные результаты данного исследования будут представлены на международном форуме по безопасности Positive Hack Days V, который пройдет 26 и 27 мая в Москве. Там же можно поучаствовать в конкурсах по взлому банкоматов и онлайновых банковских сервисов. Подробности на сайте www.phdays.ru.
Автор: @ptsecurity
Positive Technologies
рейтинг 300,25

Комментарии (12)

  • 0
    Скажем, злоумышленник переводит 0,29 рублей в доллары США. При стоимости одного доллара в 60 рублей, сумма в 0,29 рублей соответствует 0,00483333333333333333333333333333 долларов. Данная сумма будет округлена до двух знаков после запятой, т. е. до 0,01 доллара (один цент). Затем злоумышленник переводит 0,01 доллара обратно в рубли и получает 0,60 рублей. Таким образом злоумышленник «выигрывает» 0,31 рублей.

    Пример идеализированный. Курс продажи от курса покупки же отличается. Хотя, конечно, мошенник все равно получит сумму из ниоткуда, но все же меньше.
    • +4
      Проверил свой банк — заработал 1р. за 5 шагов… (4 раза купил евро по .29 и 1 раз продал). Надо отдать должное зачатки защиты есть — меньше .29 указать не дают. Хотя я думаю это всего лишь пример, есть наверно более успешный вариант использования ошибок округления.
    • 0
      Тему с округлением на практике неплохо поковырял Adrian Furtunã в 2013: 2013.zeronights.org/includes/docs/Adrian_Furtuna_-_Practical_exploitation_of_rounding_vulnerabilities_in_internet_banking_applications.pdf
    • 0
      НЕКОРРЕКТНЫЙ КУРС КОНВЕРТАЦИИ. ОТКЛОНЕНИЕ СУММЫ ОТ ВЫЧИСЛЕННОЙ ПО КУРСУ ЦБ НА 90.04%, ЧТО БОЛЬШЕ, ЧЕМ ПРЕДЕЛЬНЫЕ 40.00%
  • –1
    Снимал доклад от Digital Security эту тему «Мобильный банкинг — кража по воздуху» — в целом, там более алармичные настроения.
    • 0
      «Более алармичные настроения» — красивое выражение для рекламы. Однако было бы интересней, если бы вы говорили более конкретными фактами и цифрами.

      В исследовании Positive Technologies, которое является темой данного поста, написано:

      «Критически опасные уязвимости содержатся в 70% приложений для Android и в 50% приложений для iOS».

      А в исследовании по вашей ссылке написано:

      «Уязвимы 23% приложений Android, 14% приложений iOS».

      То есть Digital Security видит в три раза меньше уязвимостей в мобильных приложениях? Вы это хотели сказать?

      • –1
        Гм. Я помню из доклада, что уж очень пугали, а тут как-то спокойней. А по сухим цифрам вы нашли получается больше, да. Я никоим образом не наезжал на ваше исследование, сорри, что могло создаться такое впечатление.
        • +1
          Я — автор исследования: «Мобильный банкинг — кража по воздуху».

          Сравнивать два данных исследования некорректно:
          1) В данном исследовании рассматриваются все типы уязвимостей, а в моем исследовании целенаправленно анализируется только один тип уязвимостей, реализация которых позволяет осуществить атаку MiTM. Наличие проблем безопасности этого класса почти наверняка позволяет злоумышленнику удаленно (без физического доступа к устройству) осуществить кражу денег со счета и/или получить информацию о финансовых данных.
          2) В данном исследовании непонятна выборка анализируемых приложений (2?,5?,10?,...), а в моем абсолютно все из магазинов Google Play и App Store на момент исследования с наличием платежного функционала.

          Как вы наверняка понимаете, факт наличия уязвимости не гарантирует успешность проведения атаки и тем более компрометацию счета.
          • 0
            Ага, спасибо за пояснения. Хотя, как простой пользователь, хочу тоже просто «позорного списка» банков и производителей зафейлившегося софта, хотя понимаю, что скорее всего, исследователи безопасности связаны NDA о неразглашении проблем с заказчиком.
  • +1
    По тексту куча процентов. А, кроме количества исследованных систем, не нашел ни одного из значений от которых эти проценты вычисляются. Интереснее были бы абсолютные значения.
  • +5
    а список банков с указанием степени защищенности почему не показан?
  • 0
    А на третьей и четвёртой диаграммах цвета для одних и тех же сущностей сделаны разными чтобы запутать читателя?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка