Волны цифрового шторма накрывают всё больше секторов экономики, формируя новую реальность. Финансовая отрасль не стала исключением: страны одна за другой разрабатывают и внедряют революционный подход к работе кредитных учреждений — концепцию открытого банкинга или Open Banking.
Open Banking — это унифицированный программный интерфейс к информационным системам банков. Его могут использовать разработчики финансовых приложений — финтех-компании, чтобы предоставлять клиентам финансовые сервисы нового поколения.
Взаимодействие с банками через открытый интерфейс — это не только возможности, но и риски. В этом посте рассмотрим риски и угрозы, возникающие с внедрением Open Banking, и обсудим возможные варианты защиты от них.
О финтех-компаниях
Несмотря на стремление банков создавать инновационные финансовые продукты, им сложно конкурировать в этом плане с финтех-компаниями, которые не связаны требованиями регулятора и внутренними регламентами. А конкуренция между банками и стремление привлечь клиентов на обслуживание именно к себе накладывает естественные ограничения на создание сервисов, интегрирующих услуги нескольких кредитных учреждений.
Финтех-компании выгодно отличаются от консервативных банков. Они могут позволить себе привлекать клиентов из разных банков, оперативно вводить новые нестандартные продукты, используя все преимущества независимости от регулятора.
Динамичный характер финансово-технологических компаний в какой-то степени является следствием их организационных особенностей. Анализ провайдеров финансовых технологий, проведённый Trend Micro в рамках подготовки исследования «Ready or Not for PSD2: The Risks of Open Banking», показал, что большая часть таких компаний:
- имеют небольшое количество сотрудников;
- ограничены в финансовых ресурсах;
- активно используют для работы облачную инфраструктуру;
- применяют виртуализацию и контейнеризацию сервисов;
- пользуются сторонними SDK, чтобы сократить цикл разработки и сосредоточиться на инновациях;
- сокращают цикл тестирования, чтобы сэкономить как время, так и деньги. В этом нет ничего удивительного. Этот подход практикуют в стремлении уменьшить затраты даже такие гиганты, как Microsoft, отказавшаяся от штатных тестировщиков в пользу участников программы Windows Insider.
Обратная сторона этих особенностей — значительно большая по сравнению с банками уязвимость. С ростом числа стран, внедряющих Open Banking, ландшафт угроз становится всё более разнообразным, поскольку киберпреступники получают в своё распоряжение новые цели для атак. Поговорим о них подробнее.
Цели для атак, связанных с Open Banking
Публичные API банков
Open API, внедряемый в европейских банках в соответствии с PSD2 — «Пересмотренной директивой о платёжных услугах» — лишь часть большого процесса. Внедрение подобных программных интерфейсов происходит во многих странах. Где-то эти работы — инициатива объединения частных компаний и банков. Например, разработка Durable Data API в США поддерживается некоммерческим объединением FDX, дочерней компанией информационно-аналитического центра финансовых услуг (FS-ISAC). Правительства других стран предпочитают полностью контролировать процесс, подобно Мексике, принявшей Закон о Финтехе (Fintech Law), или Австралии, в которой открытие финтеху доступа к программным интерфейсам банков — лишь часть большого пула мероприятий под названием Consumer Data Right.
Лавинообразный рост внедряемых в мире финансовых API. Источник: Trend Micro
Увеличение числа публичных банковских API неизбежно приведёт к росту попыток использовать его для получения прибыли. Зачем взламывать защиту банка, если имеется интерфейс, через который можно цивилизованно подключиться к автоматизированной системе и перечислить себе пару миллионов?
Проведённое Trend Micro исследование выявило значительное количество банков, раскрывающих конфиденциальную информацию — одноразовые пароли, маркеры доступа, е-мейлы, IMEI и данные о транзакциях в URL-адресах API и сайтов.
И хотя использование SSL защищает от перехвата трафика, передача такой информации в URL опасна тем, что эти параметры:
- Могут оказаться в логах веб-сервера;
- Будут отображаться в URL браузера;
- Появятся в истории просмотра браузера;
- Будут видны любому устройству, выполняющему перехват SSL, например, оборудованию мониторинга сети с доверенным сертификатом.
Конфиденциальные данные в URL банковских API. Источник: Trend Micro
В некоторых браузерах история просмотров является общей для различных устройств, например, ноутбука, смартфона и планшета. Отображение конфиденциальной информации в URL потенциально ослабит эффективность многофакторной аутентификации, позволив хакерам атаковать наименее защищённые устройства для кражи этой информации.
Пример из реальной жизни: Европейская финтех-компания с миллионами клиентов опубликовала документацию по API, где указано, что в URL-адресах API передаются е-мейл, пароль, секретный код и идентификатор клиента.
Источник: Trend Micro
Ещё один способ злонамеренного использования публичных API — DoS/DDoS-атаки. Любой заинтересованный хакер может попытаться методом проб и ошибок подобрать комбинацию параметров, которые вызовут отказ сервиса.
Мобильные приложения
Помимо традиционных атак на мобильные приложения с использованием оверлеев и других привычных вариантов, дополнительную опасность влечёт за собой применение SDK от сторонних разработчиков.
Известны случаи, когда в них внедрялись вредоносные функции, которые подписывали пользователя программы, использующей эту библиотеку, на премиум SMS или платные сервисы, подобно ExpensiveWall, внедрённой в библиотеку gtk, или DrainerBot, внедрённому в Tapcore SDK и демонстрировавшему невидимые видеоролики для накрутки их просмотров.
В некоторых случаях изначально безопасные и полезные приложения неожиданно становились вредоносными, как, например, CamScanner — Phone PDF creator, который внезапно обзавёлся библиотекой с троянскими функциями.
Очевидно, что скрытая функциональность в программах для работы с финансовыми данными может привести к самым неприятным последствиям.
И даже если приложения Open Banking ограничены в праве на платежи от имени клиентов, злоумышленники всё равно смогут использовать их для получения выгоды. Данные о совершённых транзакциях — тоже ценный товар. Информация о том, когда и где совершаются покупки, позволяет составить представление о ежедневных перемещениях пользователей, их привычках, интересах и финансовом положении.
Ещё одна цель для атаки на мобильные приложения — отчёты об ошибках. При сбоях в приложении информация о состоянии устройства и обстоятельствах, вызвавших ошибку, отправляется на сервер разработчика. При этом передаваемые сведения также могут содержать конфиденциальную информацию:
Отчёт об ошибках. Источник: Trend Micro
Если злоумышленник скомпрометирует разработчика ПО для отчётов о сбоях, он получит доступ к этой информации.
Инфраструктура финтех-компаний
Использование облачной инфраструктуры для реализации финтех-проектов — разумный способ избавить компанию от расходов на приобретение «железных» серверов и обеспечение их бесперебойной работы. Однако в этом случае в компанию к банку, клиенту и финтех-организации добавляется ещё один участник — поставщик облачных сервисов.
Хакеры могут организовать атаку на цепочку поставок, внедрившись в сеть облачного провайдера. Такая атака повлияет на несколько финтех-компаний, имеющих ресурсы в этом облаке. Её опасность в том, что ни клиенты, ни банки, ни сами финтех-компании не узнают о компрометации, поскольку атака произойдёт вне сферы их досягаемости.
Пользователи
Атаки на пользователей находятся на первом месте по эффективности и востребованности. Они гораздо проще и дешевле в реализации, чем «технические» кибернападения.
За время работы с пользователями банки сумели добиться того, что массовые фишинговые рассылки писем типа «Ваши учётные данные для банка SuperCredit устарели. Нажмите здесь, чтобы сбросить пароль» потеряли свою эффективность. Пользователи стали более настороженно относиться к ним.
При работе с финтех-приложением этот опыт уже неприменим. А потому письмо «Мы финтех-компания MegaTech, поставщик услуг банка SuperCredit. Пожалуйста, нажмите здесь, чтобы обновить данные о вашем счёте» кажется вполне безопасным. Пользователи не осознают, что пароль к учётной записи финтех-провайдера также важен, как пароль к интернет-банку. И самое грустное, что банки не узнают о компрометации пользователя.
Более сложный способ атаки на пользователей — фальшивые финтех-приложения, которые выводятся в топ Play Market или App Store, а затем похищают учётные данные, финансовую информацию и деньги.
Как защищают Open Banking
Эффективное противодействие мошенником обеспечивает совокупность мер, и открытый банкинг не исключение. Перечислим способы защиты клиентов финтеха от угроз.
Многофакторная аутентификация
Это обязательное требование директивы PSD2 и аналогичных нормативных актов, связанных с Open Banking. По данным Microsoft использование многофакторной аутентификации блокирует 99,9% попыток взлома учётных записей.
Три кита MFA — знание, владение, биометрия. Источник: WSO2
В дополнение к MFA PSD2 добавляет концепцию динамической связки (dynamic linking)— использование для аутентификации операции кода, который зависит от суммы и получателя. Любое изменение этих параметров аннулирует этот код.
Безопасный API
В этом качестве в Open Banking предлагается использовать Financial-grade API (FAPI) — программный интерфейс на базе OAuth 2.0. FAPI, который разрабатывается фондом OpenID и британской организацией по внедрению открытого банкинга.
FAPI — более безопасная версия протокола OAuth 2.0, позволяющего третьим лицам получать доступ к поставщику услуг без предоставления учётных данных пользователя. Вместо пароля третье лицо получает токен для доступа к данным пользователя после получения его явного согласия. Пользователь контролирует права доступа третьих лиц с помощью токена, например, временный доступ и доступ только для чтения. Он может в любое время отозвать токен, а в случае его кражи изменение пароля не требуется, поскольку пароль никому не предоставлялся.
Взаимодействие с использованием FAPI. Источник: Trend Micro
Разработчики FAPI добавили к OAuth 2.0 дополнительные модули для обеспечения безопасности. Среди этих модулей стоит отметить:
- mTLS (взаимный TLS) — протокол взаимной аутентификации, аналогичный HTTPS, но здесь свою подлинность подтверждает не только сервер клиенту, но и клиент — серверу. Другими словами, для совершения транзакции финтех-приложение должно не только проверить подлинность сервера, но и подтвердить серверу свою аутентичность.
- OAuth 2.0 Token Binding (OAUTB) — привязка токенов доступа и/или кодов авторизации к соединению TLS. Если злоумышленник похитит код авторизации, то не сможет использовать его в другом TLS-соединении. К сожалению, на сегодняшний день Token Binding поддерживается только в Microsoft Edge.
- Клиентские утверждения JSON Web Signature (JWS Client Assertions) — устанавливает, что токен доступа на сервере авторизации банка может использовать только конкретный клиент.
- Проверочный ключ для обмена кодами (PKCE) — позволяет предотвратить использование злоумышленниками клиентского токена доступа. Для этого приложение отправляет на сервер аутентификации дополнительный код верификации, чтобы подтвердить, что именно клиент хочет использует этот токен доступа.
На текущий момент FAPI имеет выявленные проблемы безопасности, которые требуется устранить.
Безопасность инфраструктуры и конечных точек
Защита инфраструктуры финтех-компаний является важным фактором, закрывающим лазейки для хакеров. Необходимо обеспечить защиту конечных точек, облачных систем и механизмов разработки, а также сквозной мониторинг всей инфраструктуры.
О безопасности конечных точек мы подробно рассказывали в публикации «Когда стены недостаточно. Как защитить конечные точки».
Заключение
Любая новая технология требует не только рассмотрения перспектив, но и внимательного анализа рисков, которые она создаёт. Особенно важно рассматривать опасности в случае, если новый подход внедряется в сфере, на которую традиционно направлено самое пристальное внимание киберпреступников.
Open Banking уже меняет ландшафт финансовых взаимоотношений. В ближайшие несколько лет эти изменения могут перевернуть всю нашу жизнь, совершив революцию в том, как мы управляем нашими деньгами. Чтобы эти изменения носили позитивный характер, чрезвычайно важно, чтобы финтех-компании, банки и другие участники процесса не только принимали к сведению выявленные угрозы, но и оперативно дорабатывали API и стандарты для устранения проблем безопасности.
