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

Главные уязвимости онлайн-банков: авторизация, аутентификация и 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 («Состояние гонки»), — в ряде случаев злоумышленник может получать неограниченные суммы денежных средств.

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

Замедление Telegram привело к проблемам у мобильных разработчиков

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

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

Директор по инновациям Fork-Tech Владислав Лаптев отметил, что Telegram стал одним из ключевых инструментов доставки тестовых сборок — версий приложений, которые ещё не опубликованы в официальных магазинах, но уже требуют проверки тестировщиками и другими сотрудниками. Альтернативные сервисы оказались недоступны после ухода зарубежных вендоров или из-за санкций.

Руководитель направления разработки iOS в red_mad_robot Александр Тузовский пояснил: «В мобильной разработке Telegram часто выступает как оперативный “транспорт” для команды: это тематические чаты по проектам и релизам, уведомления от CI/CD (набор принципов и практик, позволяющих чаще и надёжнее развёртывать изменения ПО), боты для сбора фидбэка от тестировщиков, а также автоматические сообщения о статусе публикаций в магазинах приложений».

Руководитель направления Android-разработки red_mad_robot Сергей Иванов среди ключевых преимуществ Telegram назвал его широкое распространение, низкий порог входа, удобный API и относительную бесплатность.

По словам Владислава Лаптева, ранее российские разработчики активно использовали Firebase App Distribution от Google и App Center от Microsoft. Однако из-за санкций — а в ряде случаев и сопутствующих ограничений со стороны Роскомнадзора — эти инструменты стали недоступны. Google ввела ограничения на оплату для россиян и начала удалять аккаунты российских пользователей. Microsoft закрыла App Center ещё в марте 2025 года, а его замена работает на инфраструктуре Azure, которая в России также недоступна.

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

Директор по продуктам студии разработки «Решение» Анфиса Кондрашова добавила, что ограничения Telegram могут привести к росту затрат на отдельные процессы: «Речь идёт, например, о стоимости отправки кода авторизации при регистрации пользователя. Отправка кода через Telegram обходится примерно в 5 рублей, а СМС — более чем в 40 рублей за сообщение. Экономика наших клиентов может серьёзно пострадать».

Вице-президент по операционной деятельности и информационным технологиям финансовой группы «БКС Холдинг» Сергей Путятинский отметил: «Для нашей компании это неактуально — мы используем внутренние инструменты, внедрённые несколько лет назад. Но я знаю много крупных организаций в России, которые по-прежнему задействуют Telegram в процессах мобильной разработки. Для них это создаёт существенные риски, поэтому проблема на рынке действительно существует».

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

О замедлении Telegram стало известно 10 февраля, однако фактически проблемы начались раньше — волна жалоб пользователей стартовала вечером 9 февраля.

RSS: Новости на портале Anti-Malware.ru