D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Переведено специально для XSS.is
Ссылка на исходную статью: http://damaga377vyvydeqeuigxvl6g5sbmipoxb5nne6gpj3sisbnslbhvrqd.onion/d/7hmgnkfxd5I2JzCkFxWUpb
Аннотация.
3 Domain Secure 2.0 (3DS 2.0) — это ведущий протокол подтверждения личности пользователей для онлайн-платежей с использованием кредитных карт. Протокол полагается на анализ рисков для принятия решения о том, стоит ли запрашивать у инициатора платежа данные для двухфакторной аутентификации (напр. одноразовый пароль). Сам стандарт 3DS 2.0 не определяет, как должен осуществляться анализ рисков транзакций. В данной статье рассматриваются следующие вопросы:
⦁ Каким образом осуществляется анализ рисков транзакций для исследуемых кредитных карт.
⦁ Существуют ли практические уязвимости в подходе 3DS 2.0 к анализу рисков.
Мы проводим первое в своем роде подробное исследование обратного инжиниринга 3DS 2.0 для платежей через браузер. Определим данные и процесс принятия решений, используемые банками-эмитентами при оценке рисков транзакций для разных карт. Также мы продемонстрируем атаку, позволяющую обойти двухфакторную аутентификацию, используя только данные, полученные в ходе исследования с помощью обратного инжиниринга.
1. Введение
В 2001 году платежные сети (Visa, MasterCard и Amex) представили протокол 3 Domain Secure 1.0 (3DS 1.0) [35]. 3DS 1.0 ввел процедуру проверки пользователей, требуя от инициаторов платежей подтвердить свою личность с помощью статических паролей. Например, сервис «Verified by Visa» запрашивал три символа из установленного пароля. Однако, 3DS 1.0 подвергся критике по причинам безопасности и удобства использования. Безопасность оказалась под угрозой, потому что ввод пароля не мог гарантировать проведение операции владельцем карты. Не исключалось также проведение фишинговых атак на данные карты и пароли. Однако решающим недостатком 3DS 1.0 для продавцов была «потеря продаж», когда покупатели не завершали покупку, потому что не могли вспомнить или отказывались проходить процедуру ввода пароля [3, 23, 20, 16].
Европейская комиссия в 2015 году предложила Директиву 2015/2366 (Вторая Директива об оказании платёжных услуг), регулирующий стандарт, который обязывает эмитентов карт в Европе обеспечивать усиленную процедуру проверки клиента для каждой онлайн-транзакции [13], аналогично реализованной в 3DS 1.0. Индустрия (банки-эмитенты, процессинговые центры и онлайн-продавцы) выразила обеспокоенность тем, что в предложенных в Директиве методах не учтены требования удобства использования, и заявила, что данная процедура проверки должна применяться только к транзакциям, находящихся в «зоне риска» в рамках анализа рисков транзакции. После полугода переговоров с участием более 200 заинтересованных сторон из платежной индустрии, в Директиву в качестве дополнения к усиленной процедуре проверки был добавлен анализ рисков транзакций.
В октябре 2016 года EMVCo (консорциум платежных сетей) пересмотрела 3DS 1.0, включив в него анализ рисков, что привело к созданию текущего протокола 3D Secure 2.0 [10]. 3DS 2.0 предлагает две процедуры проверки: аутентификация и авторизация. Аутентификация применяется для покупок с высоким риском и требует от инициатора платежа прохождения дополнительной проверки. Авторизация не требует дополнительной информации и предназначена для «зеленых» транзакций. Анализ рисков транзакции, с точки зрения безопасности, пренебрегает строгими требованиями безопасности в пользу удобства. Протокол 3DS 2.0 можно считать «разработанным, чтобы быть взломанным».
Протокол 3DS 2.0 не указывает, как именно должен быть реализован анализ рисков, за исключением некоторых общих рекомендаций. В этой статье проводится подробное исследование существующих способов применения 3DS 2.0. Мы покажем, что риски транзакции анализируются на основе данных, собранных через браузер инициатора платежа, а также информации о транзакции или сети (например, суммы транзакции или IP-адреса). Файлы cookie создают «отпечаток» пользователя (см. Раздел 2). В Разделе 4 проводятся дополнительные эксперименты с различными транзакциями и с разных локаций для того, чтобы понять, когда система применяет процедуру проверки «авторизация». Мы увидим, что исследуемые банки-эмитенты по-своему реализуют процедуру анализа рисков, проявляя к ним разные подходы.
В нашем исследовании с использованием обратного проектирования рассматривается пять кредитных карт, как Visa, так и Mastercard, использованных на ряде различных веб-сайтов. Эксперименты с кредитными картами сопряжены с определенными трудностями, например, из-за возможности блокировки карт. Поэтому неудивительно, что литература по экспериментальным исследованиям онлайн-платежей сравнительно невелика и подобные эксперименты ранее не проводились. Пять использованных карт обобщают информацию о банковских картах, поскольку в ходе эксперимента были отмечены похожие «отпечатки». Мы отмечаем, что все карты принадлежали авторам, и получение одобрения этических норм происходило в соответствии с обычными процедурами, проводимыми институтом защиты прав авторов. Ответственное раскрытие информации путем информирования выбранных партнеров было осуществлено через нашу партнерскую сеть.
Дизайн 3DS 2.0 также указывает на очевидную уязвимость — служба анализа транзакции может ошибочно решить не запрашивать дополнительную информацию для проведения платежа. В рамках исследования, мы продемонстрируем атаку с подменой личности, при которой злоумышленник представляется инициатором платежа, "обманывая" службу анализа и позволяя завершить транзакцию без вызова двухфакторной аутентификации, даже для крупных сумм. Мы продемонстрируем две версии атаки: одна предполагает копирование отпечатка пользователя на другую машину, настроенную произвольно, а другая — создание такого же отпечатка на машине с конфигурацией пользователя. Эксплуатация уязвимости может стать практической атакой, если удастся установить вредоносное ПО, с помощью которого отпечаток попадет к злоумышленнику, использующему его для совершения покупки, подменив владельца карты (подробности см. в Разделе 3). Здесь показывается, как подобный способ атаки может быть проведен любым, кто займется обратным проектированием используя информацию из данной статьи.
Рис. 1: Схема обратного проектирования, перехватывающая транзакции 3DS 2.0 с помощью прокси.
2. Подробное рассмотрение анализа рисков транзакции. Создание отпечатка.
Протокол 3DS 2.0 не дает четких указаний по тому, как банки-эмитенты должны реализовывать анализ рисков. Чтобы понять, как продавцы и банки оценивают риски потребительских платежей, мы детально исследовали существующие способы.
2.1 Настройка системы для обратного проектирования
На рис. 1 показана схема настройки системы. В рамках 3DS 2.0 задействовано несколько сервисов и участников:
⦁ инициатор платежа, использующий браузер;
⦁ продавец, предоставляющий страницу оформления заказа для каждой покупки;
⦁ набор служб и серверов для аутентификации, называемых сервером аутентификации платежа (ACS).
ACS хранит данные инициатора платежа, которые могут использоваться для подтверждения личности владельца карты во время покупки.
Чтобы перехватить коммуникации, мы используем прокси Fiddler, доступный в виде ПО с открытым исходным кодом [32]. Прокси запускается на машине инициатора платежа (то есть на нашем собственном компьютере). Мы настраиваем веб-браузер машины на отправку запросов HTTP(S) через Fiddler, который затем перенаправляет трафик продавцу или ACS. Ответы возвращаются в Fiddler, который передает трафик обратно в браузер. Когда включено дешифрование HTTPS, прокси Fiddler генерирует самоподписанный корневой сертификат и соответствующий закрытый ключ. Корневой сертификат используется для создания сертификатов HTTPS для каждого посещаемого защищенного сайта.
Кроме перехвата коммуникации браузера, мы используем два других метода. Во-первых, с помощью Fiddler мы симулируем запросы браузера, как если бы мы были продавцом или эмитентом карты. Во-вторых, используя Fiddler, мы симулируем запросы продавца, как если бы запрос исходил от браузера. Чтобы обрабатывать запросы, Fiddler предоставляет функцию точек прерывания, которая приостанавливает коммуникацию. В это время мы можем изменять данные в запросах.
Всего для наших экспериментов мы использовали пять тестовых карт: три карты Visa (C1-C3) и две карты Mastercard (C4, C5). Чтобы убедиться, что на машине нет предварительно установленных идентификаторов, связанных с 3DS 2.0, мы установили новую операционную систему Windows 10 и браузер Chrome версии 59.x. Использованные веб-сайты торговых площадок, поддерживали оплату через 3D Secure 2.0 и были выбраны из списка торговых сайтов Alexa [2]. Значок «Verified by Visa» на сайте указывает на поддержку 3D Secure. Чтобы гарантировать репрезентативность выборки сайтов, мы отследили URL-адреса ACS, на которые перенаправлялись наши транзакции. Все сайты с пометкой «Verified by Visa» перенаправляли нас на один и тот же URL-адрес ACS, что указывает на то, что реализация 3D Secure зависит от банка. Для каждой тестовой карты мы провели несколько «зеленых» транзакций и записали полные сеансы оформления платежа для каждой транзакции с помощью Fiddler. После прохождения проверки через ACS с использованием бесконтактной авторизации было решено прекратить транзакции. Это гарантирует, что ACS достаточно доверяет браузеру. По мере необходимости, мы декодировали данные транзакций 3D Secure и подробно проанализировали результаты.
2.2 Протокол аутентификации 3DS 2.0
На рис. 2 показана последовательность транзакции для осуществления бесконтактной авторизации в системе 3DS 2.0, объединяя ее спецификации с информацией о транзакциях, извлеченной из Fiddler. Блок «Туннель (Покупатель, ACS)» представляет собой часть транзакции, над которой было проведено обратное проектирование. Этот блок виден в браузере, в то время как другие шаги последовательности транзакции для остальных сторон происходят из спецификаций 3DS 2.0.
Шаг 1 - покупатель инициирует платеж.
Шаг 2 - продавец решает запустить процесс аутентификации пользователя через 3DS 2.0.
Шаги 3-4 - устанавливается соединение между инициатором платежа и ACS.
На шагах 5-11 детально отображено взаимодействие между браузером и ACS, где ACS извлекает данные из браузера, используемые для оценки рисков транзакции.
Шаг 6 - ACS отправляет JavaScript файл dfp.js в браузер и возвращает результаты на шаге 8.
Отметим, что dfp означает "отпечаток устройства" (device fingerprint), который предназначен для идентификации устройства по его характеристикам, чтобы последующий платеж мог быть связан с той же машиной (и, следовательно, с тем же инициатором платежа). Если это первый раз, когда браузер загружает этот JavaScript, ACS повторяет процесс на шагах 9-11 для установки постоянных cookie-файлов в браузер. Далее транзакция обрабатывается в соответствии с правилами, установленными спецификациями EMV 3DS 2.0, которые требуют от сервера 3DS отправки запроса на аутентификацию в ACS. Анализ рисков транзакции завершается на шаге 13, в результате чего принимается решение о проведении транзакции через бесконтактную авторизацию. Теперь продавец может отправить запрос на авторизацию (шаг 15).
Рис. 2: Последовательность проведения транзакции через бесконтактную авторизацию.
2.3 Данные для анализа рисков транзакции в 3DS 2.0
С помощью обратного проектирования можно увидеть, как ACS создает отпечаток машины инициатора платежа. Он использует три типа информации для создания отпечатка, речь о них пойдет далее:
⦁ Информация об отпечатке, извлекаемая из браузера с помощью JavaScript.
⦁ Идентификаторы 3DS 2.0, полученные с помощью cookie-файлов браузера.
⦁ HTTP-заголовки, отправляемые браузером инициатора платежа и передаваемые продавцом в ACS.
Отпечаток данных с использованием JavaScript
Анализируемые нами скрипты для снятия отпечатков с помощью JavaScript содержат функции для:
⦁ Сбора информации, предоставляемой браузером с устройства пользователя
⦁ Отправки собранных данных на сервер 3DS 2.0 в виде одной строки, закодированной в формате Base-64 (спецификации 3DS 2.0 [10] требуют, чтобы все сообщения данных были в формате Base-64).
В таблице 2 (Приложение A) представлен исчерпывающий список атрибутов устройства, передаваемых от браузера инициатора платежа в ACS для карт C1-C5. В ходе процесса оформления заказа, загрузка и выполнение скрипта
Полученные данные очень разнообразны. От информации о браузере и операционной системе до характеристик экрана, времени, геолокации и некоторых плагинов. Скрипт для снятия отпечатков получает информацию, которая является частью HTTP-заголовков, через функции
⦁
⦁
Пример зашифрованного отпечатка устройства представлен на рисунке 5 в Приложении A.
Cookie-файлы
Мы обнаружили три типа cookie-файлов, установленных ACS на наших машинах. Они также описаны в нижних строках таблицы 2. Полные cookie-файлы приведены на рисунке 6 в Приложении A.
⦁ Session_cookie. Сессионный cookie удаляется после закрытия браузера пользователем.
⦁ Test_cookie. Тестовый cookie с именем TESTCOOKIE и значением Y наблюдался при обмене данными в ходе транзакции. Он устанавливается сервером аутентификации для проверки того, разрешены ли cookies в настройках браузера пользователя.
⦁ IDcookie. Когда держатель карты впервые регистрируется в системе 3DS 2.0, в браузер пользователя добавляется токен в виде ID Cookie(s). Количество устанавливаемых cookies варьируется от одного до трех. Во всех случаях мы обнаружили, что срок действия этих cookies составляет три года с момента установки, и они имеют метку безопасности HTTP-only. Эта метка защищает cookie от доступа со сторонних веб-сайтов.
Данные, передаваемые продавцом в ACS
Данные, передаваемые продавцом в сообщении AReq (шаг 12 на рис. 2), содержат элементы, которые идентифицируют конфигурацию браузера инициатора платежа. Например, таблица A.1 в спецификациях EMV 3DS 2.0 [10] предлагает продавцам передавать заголовки браузера, язык, параметры экрана и user agent в сообщении AReq. Конфигурация браузера помогает ACS корректно отображать iframe для устройства держателя карты и может использоваться сервером аутентификации для сравнения информации, передаваемой скриптом
2.4 Обсуждение реализаций 3DS 2.0
Существуют несколько заметных различий между реализациями 3DS 2.0. Их можно классифицировать следующим образом:
⦁ Различие в использовании версии протокола 3DS.
⦁ Различие в передаче данных об отпечатке устройства: обфусцированные данные против данных в открытом виде.
⦁ Различие в объеме данных, собираемых для создания отпечатка: на основе JavaScript против данных, собранных только с использованием HTTP-заголовков и cookies.
Различие в использовании версии протокола 3DS
Мы обнаружили, что ACS, связанный с картой C2, добавляет слой бесконтактной авторизации поверх протокола 3DS 1.0. В отличие от 3DS 2.0, браузер собирает и отправляет сообщение AReq с идентификатором транзакции, следуя спецификации 3DS 1.0. ACS устанавливает и собирает данные отпечатка из браузера. Аналогично бесконтактной авторизации в 3DS 2.0, ACS повторяет сообщения для установки ID Cookie в случае, если это первая транзакция через 3DS 1.0 с этого устройства. Далее транзакция обрабатывается в соответствии со спецификацией 3DS 1.0. Решение ACS (не запрашивать данные) добавляется в сообщение ARes, которое затем передается продавцу через браузер. Сравнивая бесконтактную авторизацию в 3DS 1.0 и 3DS 2.0, можно сказать, что оба этих протокола захватывают статические данные отпечатка в формате Base-64 и используют HTTP-only ID Cookies для анализа рисков транзакции.
Различие в реализации отпечатка устройства
В двух случаях (C2 и C5) мы заметили, что для того, чтобы затруднить чтение и анализ JavaScript, применялись техники обфускации кода. Однако они, в свою очередь, имеют определенные общие ограничения, поскольку это метод кодирования (а не шифрования), и код должен сохранять свою функциональность при выполнении на системе. Тем не менее, JavaScript для создания отпечатков устройств в 3DS 2.0 все еще может выполняться для получения значений отпечатка устройства в формате Base-64.
Кроме того, техника обфускации кода давно используется авторами вредоносного ПО для скрытия своего кода. Поэтому, в открытом доступе существует множество учебных материалов и инструментов безопасности, предназначенных для деобфускации JavaScript. Самый надежный из нами обнаруженных, разработан компанией Intelligent Systems Lab, Zurich [18] и имеет открытый исходный код.
Различие в объеме собираемых данных устройства
Хотя таблица 2 показывает исчерпывающий список всех элементов данных, собираемых скриптами и HTTP-заголовками, объем данных, собираемых при каждой реализации JavaScript, значительно варьируется. Некоторые банки вообще не внедряют JavaScript для создания отпечатков устройства. Например, банк-эмитент карты C3 реализует бесконтактную авторизацию на основе 3DS 1.0 и полагается только на данные, полученные в сообщении AReq.
Напоследок отметим, что протокол 3DS 2.0 также определяет этап регистрации, в ходе которого банк собирает отпечатки устройства компьютера держателя карты и подписывает данные об отпечатках для создания ID Cookies. Затем, для создания ID Cookies, компьютер держателя карты "помечается" с помощью стандартного механизма cookie. Этот этап регистрации несовершенен, так как невозможно определить, является ли инициатор платежа ее законным пользователем.
3. Атака с подменой личности
В этом разделе мы разработаем реалистическую атаку с подменой личности, при которой злоумышленник использует полученные данные, описанные в предыдущем разделе, и постарается избежать запроса на предоставление данных для двухфакторной аутентификации. Сначала, в разделе 3.1, мы опишем модель атаки, а затем, в разделе 3.2 метод реализации подобной атаки, в особенности часть, касающуюся получения данных. На различных машинах, нами было проведено определенное количество экспериментов, чтобы продемонстрировать, что атака с подменой личности действительно может быть успешной, что и будет показано в разделе 3.3.
3.1 Модель атаки
Цель атаки заключается в том, чтобы использовать кредитную карту другого человека для совершения онлайн-покупки, несмотря на использование торговой точкой протокола 3DS 2.0. Мы предполагаем, что злоумышленник не может успешно пройти двухфакторную аутентификации. Следовательно, цель злоумышленника — избежать запроса и завершить транзакцию путем бесконтактной аутентификации. Атака считается успешной, если злоумышленник избегает прохождение проверки в ситуациях, когда на самом деле ACS должен был отреагировать иначе.
Для совершения успешной транзакции, злоумышленнику необходимо получить данные кредитной карты, cookies и данные отпечатка устройства, используемые для анализа рисков транзакции, как описано в предыдущем разделе. Не предполагается, что злоумышленник располагает правами доступа администратора на машине инициатора платежа или на каких-либо службах 3DS 2.0. Предполагается, что злоумышленник устанавливает вредоносное ПО или плагин, который собирает необходимые данные с машины инициатора платежа, включая выполнение JavaScript для создания отпечатка устройства (в следующем разделе обсуждается, что это вполне возможно). После отправки этих данных злоумышленник может подменить личность держателя карты, сгенерировав данные для аутентификации в 3DS 2.0, соответствующие данным инициатора платежа.
3.2 Осуществление атаки
Процесс атаки должна состоять из двух этапов:
⦁ Получение данных о карте и анализе рисков транзакции
⦁ Использование полученных данных
Получение данных о карте и анализе рисков транзакции
На этом этапе злоумышленнику необходимо получить данные кредитной карты и отпечатки устройства (включая cookies). Существует ряд причин, по которым это можно сделать только через атаку типа "человек в браузере" (Man in the Browser).
Проблема заключается в том, что cookie-файлы с идентификаторами (см. Раздел 2.3) защищены флагом HTTP-only, то есть они не могут быть прочитаны с других доменов или через JavaScript. Однако браузеры предоставляют доступ к таким HTTP-only cookie расширениям (включая вредоносные программы), так как расширения считаются "доверенными" после установки, в отличие от обычного JavaScript. Поэтому атаки типа межсайтового скриптинга (XSS) [5, 4, 33], при которых скрипт с веб-сайта, отличного от сайта продавца или сервера 3DS 2.0, пытается получить доступ к информации, такой как cookie, невозможны.
Самый простой способ получения необходимых данных — это использование плагина, который может отслеживать коммуникации в браузере, чтобы украсть cookies с флагом HTTP-only, записывать нажатия клавиш для кражи данных пользователя и выполнять скрипты JavaScript для создания отпечатков устройства. Более продвинутое вредоносное ПО имеет такие функции и находится в открытом доступе (например, ZeuS, SpyEye, Dridex и Tinba). Как только такое ПО установлено, оно может получать данные о транзакциях, связанные с покупкой, а также данные об анализе рисков транзакций и cookies с флагом HTTP-only. Например, такое ПО как SpyEye проникает в браузер, предлагая пользователю установить PDF-reader или плагин для Flash Player. После проникновения оно обновляется по мере необходимости, чтобы настроить поддельные сертификаты в хранилище браузера, записывать нажатия клавиш, перехватывать коммуникации браузера, фиксировать сессии браузера и даже делать скриншоты [31, 15].
Использование полученных данных
На этом этапе, задача состоит в том, чтобы подменить личность владельца карты в браузере злоумышленника. Последний копирует cookies в свой браузер и инициирует транзакцию, даже если продавец использует 3DS 2.0. Он также использует данные кредитной карты и отпечатки устройства. При оплате злоумышленник создает или воспроизводит правильные ответы в протоколе, показанном на рис. 2. Поскольку в данных отпечатков устройства нет случайных элементов, те же самые данные dfp.js и HTTP-заголовков, полученные с машины инициатора платежа, можно воспроизвести на машине злоумышленника с использованием Fiddler. Чтобы изменять данные, в Fiddler добавляются точки прерывания всякий раз, когда продавец и ACS подключаются к браузеру злоумышленника.
3.3 Демонстрация атаки
Демонстрация атаки нацелена на определение возможности подмены личности инициатора платежа с другого устройства. В этом эксперименте мы использовали данные, полученные с машины M1, используя установку, показанную на рис. 1. Мы случайным образом выбрали продавца с поддержкой оформления заказов через 3DS 2.0 и провели транзакции с использованием всех тестовых карт (C1-C5), пока M1 не стал доверенным для бесконтактной авторизации. Платежные сеансы, выполненные с M1, были записаны через прокси Fiddler и использовались на другой машине M2 с иной конфигурацией. Далее также показано, что на машине M3, настроенной идентично, генерируются такие же отпечатки. Стоит отметить, что M2 и M3 находились в разных сетях, то есть IP-адреса источников были разными.
Примененный нами подход к исследованию выглядит следующим образом: для всех пяти карт проводится один и тот же эксперимент. Во-первых, проверяется, что транзакции с машины M2 с иной конфигурацией действительно заканчиваются вызовом двухфакторной аутентификации, если введены только данные карты (и отпечаток инициатора не подделывается). Эта проверка была успешной во всех случаях, за исключением карты C1, где были одобрены транзакции на небольшие суммы, менее 10 фунтов стерлингов (мы вернемся к этому позже). Затем был проведен эксперимент, в ходе которого использовались данные об анализе рисков транзакции для подмены личности владельца карты, чтобы проверить, удастся ли провести «зеленую» покупку. Мы создали транзакции на товары стоимостью от 1 до 300 фунтов на онлайн-платформе с поддержкой 3DS 2.0.
Нам удалось успешно выполнить атаку для всех тестовых карт, и транзакции были одобрены без каких-либо запросов со стороны ACS. Примечательно, что только для тестовой карты C5, ACS банка выдал запрос на двухфакторную аутентификацию при проведении платежа выше 200 фунтов стерлингов (стандартный лимит бесконтактной авторизации).
Затем, был проведен второй эксперимент с использованием другой, но идентично настроенной машины M3 с тем же аппаратным и программным обеспечением, что и M1. Таким образом, мы хотели выяснить, генерируют ли разные машины с идентичной конфигурацией одинаковые данные отпечатков устройства. Это имитирует сценарий, при котором злоумышленник не смог получить данные отпечатков устройства, но получил ID Cookies. Во всех случаях транзакции были осуществлены успешно. Тщательный анализ данных, отправленных с M3 продавцу и ACS, показал, что данные об анализе рисков транзакции были практически идентичны для M1 и M3.
Заключение
Для покупателей важно понимать, как продавцы и банки реагируют в случае подобной атаки. Мы связались с последними, чтобы узнать, как они отреагируют, если мы сообщим о транзакциях, выполненных с машины злоумышленника. Банк-эмитент карты C3 попросил держателя карты указать несколько предыдущих транзакций, сделанных с машины жертвы, и не отметил транзакции, совершенные с машины злоумышленника, как мошеннические. Он также заблокировал и переиздал держателю карту. Однако в двух случаях (C4 и C5) банки-эмитенты заявили, что транзакции должно быть, были осуществлены с устройства держателя карты. Они утверждали, что держатель пытается совершить «дружественное мошенничество», и отказали в возмещении убытков. Это исследование показывает, что приводимые банками заключения не всегда являются верными.
4. Обратное проектирование анализов рисков транзакции: принятие решений
В разделе 2 рассмотрено, какие данные используются в подходе 3DS 2.0 к анализу рисков транзакций. А нами было показано, что с помощью этих данных можно выполнить атаку с подменой личности. Однако это все еще не дает полного понимания того, каким именно образом ACS анализирует риски. Во-первых, сервер может использовать дополнительные источники данных, например, IP-адрес или другую информацию о владельце карты, доступную банку-эмитенту. Во-вторых, он устанавливает определенные правила о том, когда следует запрашивать двухфакторную аутентификацию. Эти правила определяют, какие данные об отпечатках устройства следует учитывать, и устанавливают пороговые значения для транзакции (напр. лимит на сумму транзакции).
Таблица 1: Результаты проведенных экспериментов для карт С1 и С2.
Есть несколько интересных вопросов, благодаря которым проводится дальнейшее обратное проектирование подхода к анализу рисков. Во-первых, это позволяет узнать, какие варианты атаки с подменой личности могут быть успешными, и таким образом оценить безопасность и риски онлайн-платежей. Во-вторых, это может предложить методологию для оценки последствий анализа рисков транзакций для покупателей. TRA перекладывает ответственность на банк, но при этом, потребитель все равно подвергается возможным рискам в случае осуществления подобной атаки. Таким образом, можно утверждать, что должна быть осуществлена прозрачность в реализации анализа рисков транзакций в интересах общественности. Благодаря проведенному в этом разделе обратному проектированию мы можем наблюдать осуществление этой прозрачности.
По результатам проведенных в данном разделе экспериментов, ожидается получение ответов от ACS для транзакций в восьми разных сценариях.
Эти сценарии включают все комбинации следующих трех характеристик:
⦁ Отправка или не отправка данных устройства и ID Cookies.
⦁ Различные суммы транзакций.
⦁ Транзакции, осуществляемые из разных регионов.
На таблице 1 показаны результаты экспериментов с картами C1 и C2. Наша настройка была идентична описанной в разделе 3, с использованием данных, полученных с машины M1 на альтернативной машине M2. Платежи осуществлялись на двух веб-сайтах (W1 и W2), взаимодействующих через 3DS. W1 — это онлайн-магазин, находящийся в стране держателя карты, а W2 — зарубежный продавец.
Строки таблицы показывают различные сценарии. Например, сценарий S1 копирует данные устройства и ID Cookie для транзакции на небольшую сумму внутри региона. Что касается региона, эксперименты для C1 и C2 проводились из Великобритании и Германии. Галочка в графе «Регион» указывает, что попытки транзакций проводились на территории страны держателя карты. Разные банки по-своему анализируют риски. В частности, банк-эмитент карты C1 позволяет проводить больше транзакций через бесконтактную авторизацию, тогда как банк-эмитент C2 чаще требует подтверждения от инициатора платежа. Сравнивая транзакции T4 и T10 для карты C2, мы видим, что банк запрашивает подтверждение для каждой транзакции, если веб-мерчант находится в другой стране. Из таблицы 1 также видно, что карты, как правило, подвергаются более строгим проверкам, если транзакции осуществляются из других регионов. Например, при совершении транзакции из другой страны, данные устройства были изменены, и вероятность необходимости подтверждения и отказа в транзакции возрастает (в отличие от транзакций, инициированных из страны, где находится эмитент карты).
Рис. 3: Результаты анализа рисков для C1 на веб-сайтах W1 и W2.
Рис. 4: Результаты анализа рисков для C2 на веб-сайтах W1 и W2.
Рисунки выше представляют собой этапы транзакции в рамках 3DS 2.0, где «Оплата» обозначает начало платежа, а остальные состояния относятся к возможным исходам: «одобрено», «проверка/отклонение» или «блокировка». Обратите внимание, что для наших целей нет необходимости разделять «проверка» и «отклонение», так как оба означают, что транзакция не была проведена через бесконтактную аутентификацию. Дуги помечены сценариями, указанными во втором столбце Таблицы 1. CAC (Challenge Limit Counter) обозначает счётчик лимита запросов подтверждения, который отсчитывает от заданного лимита до нуля. В данном случае лимит равен 4, и при пятой попытке карта блокируется. Для злоумышленника Рисунки 3 и 4 могут служить картой-ориентиром на случай, если будет собрано больше данных, относящихся к картам, выпущенным банками C1 и C2.
5. Обсуждение безопасности систем платежей по картам
Проблема подтверждения личности держателей карт в системе онлайн-платежей усугубляется стремлением повысить уровень комфорта в процессе оформления заказа. Введение протокола 3DS 2.0 решает проблему баланса между безопасностью и удобством благодаря использованию анализа рисков транзакции. Очевидно, что индустрия активно поддерживает подходы, основанные на анализе рисков, поскольку, как показывают данные, около 75% банков-эмитентов в США внедрили риск-ориентированную аутентификацию [7]. Тем не менее, как было показано в данной работе, оставшимся брешами в обеспечении безопасности остаются:
⦁ надёжное хранение данных аутентификации устройства;
⦁ безопасная передача этих данных и http-only cookie с устройства клиента в сервис аутентификации;
Когда 3DS 2.0 будет использоваться повсеместно, и транзакции через бесконтактную авторизацию перестанут быть уязвимыми, то атака, описанная в этой статье, может стать объектом внимания для злоумышленников. Её основным эффектом будет возможность использовать украденные данные для проведения транзакции без аутентификации 3DS 2.0 в интернет-магазинах без каких-либо последствий для держателя карты, точно так же, как это происходило с системами, основанными только на авторизации, до внедрения 3D Secure. Этот метод атаки не требует синхронизации мошеннической покупки с действиями ничего не подозревающего клиента (как в случае с релейной атакой). Вредоносное ПО может быть легко создано для перехвата данных транзакции и их последующей передачи на сервер злоумышленника. На самом деле, существует ряд подобных расширений браузеров с открытым исходным кодом, которые доступны и установлены в тысячах браузеров, например, HTTPWatch [17] и LiveHTTPHeaders [11]. Другие разработки, такие как FraudFox [37], также вызывают серьёзные опасения. FraudFox нацелен на то, чтобы упростить и ускорить изменение отпечатка браузера, чтобы он соответствовал отпечатку жертвы, например, с помощью генераторов профилей.
Попытки усложнить выполнение атаки с помощью обфускации JavaScript, как это реализовано в некоторых системах, вряд ли окажутся эффективными. В Интернете существует множество инструментов и руководств, которые позволяют восстановить исходные данные, поэтому обфускация скриптов далеко не достаточная мера. Более полезным является подход к хранению cookie-файлов, наблюдаемый в рассматриваемых реализациях. Все обнаруженные нами cookie-файлы с идентификаторами имели атрибут secure, что означает, что они передаются только по защищённым соединениям (HTTPS). Во-вторых, они были помечены как http-only, что подразумевает, что JavaScript не имеет к ним доступа. Это предотвращает доступ к cookie-файлам с междоменных веб-сайтов, то есть защищает от атак типа межсайтового скриптинга (XSS). Тем не менее, хранение cookie-файлов в браузерах остаётся небезопасным, если на устройстве не используется надёжное хранилище.
С технологической точки зрения, очевидным решением для безопасной передачи данных могло бы быть использование методов с закрытым и открытым ключом для шифрования и подписания сообщений между инициатором платежа и сервером 3DS. Однако для того чтобы такое решение было принято, потребуется отдельная надёжная среда для хранения криптографических ключей и сертификатов. Стандарты платёжной индустрии [27, 28] требуют, чтобы платёжные данные, включая ключи и сертификаты, хранились в «модуле защиты от несанкционированного доступа», который определяется как набор аппаратного, программного обеспечения, прошивки или их комбинации, реализующий криптографическую логику или процесс (включая криптографические алгоритмы и генерацию ключей) и находящийся внутри криптографической границы. Современные компьютерные системы и их программное обеспечение пока недостаточно надёжны для обеспечения такой безопасности. Эта проблема уже поднималась, когда Google впервые представил Android Pay с концепцией эмуляции карты на хосте в Android KitKat 4.4 [14] в 2014 году. Модель безопасности хранения ключей в случае с концепцией эмуляции карты управлялась программным обеспечением, что создавало угрозу компрометации операционной системы мобильного устройства для кражи данных. Поэтому этот подход был признан неподходящим для размещения платёжных приложений стандарта EMV [1].
6. Смежные направления исследований
В этом разделе представлено сравнение протоколов оплаты по картам и технологий безопасности, которые они используют. Также рассматриваются зарегистрированные атаки на карточные платежи, которые становятся возможными при отсутствии определённых функций безопасности в протоколе. Полный разбор всех технологий и протоколов выходит за рамки данного обсуждения, однако нами предлагается краткое изложение ключевых аспектов.
Решения для физически присутствующих карт
Эта категория относится к платежам, когда карта физически присутствует. В случае карт с магнитной полосой функции обеспечения целостности данных и аутентификации карты (подтверждения её подлинности) не были реализованы непосредственно на самой карте. Данные, хранящиеся на магнитной полосе, являются статичными и представлены в открытом виде, что делало такие карты уязвимыми для атак, связанных с кражей идентификационных данных [23], подделкой личности держателя карты [24] и клонированием карт [6].
EMV расширил возможности смарт-карт, обеспечив безопасное, "неподделываемое" хранилище для криптографических закрытых ключей карты. В протоколе Chip and PIN, определённым EMV, используется инфраструктура открытых ключей RSA в трёх вариантах. Карта со статической аутентификацией данных (Static Data Authentication) имеет постоянную подпись, которая генерируется банком-эмитентом, подписывается с использованием его закрытого ключа и записывается на карту в процессе её производства. Однако статические подписи используются для одобрения каждой транзакции, что делает такие карты уязвимыми для атак с помощью копирования данных [6][25]. В то время как в картах с динамической аутентификацией данных (Dynamic Data Authentication) генерируется уникальная подпись RSA "вызов-ответ" для каждой транзакции, включая случайные. Комбинированная аутентификация данных улучшает динамическую, кодируя прикладную криптограмму в подписи, а не данные транзакции. Это делает динамический и, особенно, комбинированный методы аутентификации крайне устойчивыми к любым формам атак.
EMV contactless обеспечивает удобство для клиента, аутентифицируя карту вместо того, чтобы просить держателя одобрить транзакцию [9]. Fast DDA (fDDA) (динамический и CDA (fCDA) — это улучшенные версии DDA и CDA в протоколе Chip and PIN, исключающие методы аутентификации держателя из протокола. Оба варианта DDA и SDA обеспечивают защиту от известных атак на платёжную систему. Однако каждая транзакция с использованием DDA и SDA требует от держателя карты подтверждения своей личности, что негативно сказывается на удобстве использования. Эта проблема была решена с помощью улучшенных версий fDDA и fCDA в EMV contactless [8].
Решения для физически не присутствующих карт
Если карта не присутствует, то ситуация, как мы увидели в этой статье, становится очень сложной. Как обсуждалось во введении, осложнения, связанные с реализацией протокола 3DS 1.0, позволяли злоумышленникам обходить его функции безопасности и выполнять атаки связанные с кражей личных данных [23][16]. Программа аутентификации с чипом (Chip Authentication Program) и номера аутентификации транзакции (Transaction Authentication Number) [30][29] — это две технологии генерации токенов, которые используются потребителями для создания ответа на запрос из системы авторизации. Обычно это делается с помощью небольшого устройства, которое считывает данные с кредитной карты и/или использует ПИН-код для создания ответа на запрос. Эти технологии все чаще предоставляются банками, однако в большинстве случаев они ограничены платежами, выполняемыми через банковские транзакции.
В заключение, для разных целей были разработаны различные платежные протоколы. Удовлетворительные решения находят успешное сочетание удобства использования и безопасности, а также управляют рисками на случай, если что-то пойдет не так. Например, лимиты транзакций для бесконтактных карт и лимит для платежей через бесконтактную авторизацию 3DS 2.0 оба управляют рисками, ограничивая возможные потери для потребителей. Неудивительно, что разумные подходы требуют двухфакторной аутентификации путем ввода ПИН-кода, как в системе Chip and PIN, или через подтверждение личности держателя в 3DS 2.0, либо с использованием генераторов токенов, как в CAP и TAN. Однако эти методы не удовлетворяют требованиям удобства для продавцов, оставляя потребителей с системами, такими как 3DS 2.0, которые спроектированы таким образом, чтобы допускать менее безопасные платежи и, следовательно, неизбежно (и по замыслу) подвергать потребителей и банков-эмитентов риску мошенничества.
7. Заключение
В данной работе представлено первое практическое исследование реализаций протокола 3DS 2.0. В ходе обратного проектирования мы определили последовательности транзакций для бесконтактной авторизации. В большинстве рассмотренных способов, машина инициатора платежа идентифицируется с помощью JavaScript, за исключением реализации на основе 3DS 1.0. В наших экспериментах мы получили дополнительные сведения о процессе принятия решений службой авторизации, проводя эксперименты с различными суммами транзакций и регионами, из которых проводились платежи. Мы обнаружили, что банки-эмитенты различаются по степени готовности принимать риски: некоторые из них значительно более лояльно разрешают проводить транзакции без дополнительных проверок.
Нами была также продемонстрирована атака с подменой личности против 3DS 2.0, используя только данные, которые доступны благодаря обратному проектированию, описанному в этой статье. Этот способ атаки практически осуществим и использует тот факт, что информация об отпечатке устройства инициатора платежа может быть воссоздана с помощью вредоносного ПО или плагинов, если они установлены на устройстве. Этот эксплойт подчеркивает уязвимость платежей с использованием браузеров на основе кредитных карт по сравнению с более продвинутыми методами безопасности мобильных платежей.
Ключевой вопрос для регулятора заключается в том, было ли оправданным разрешить подход, основанный на оценке рисков, для обеспечения безопасности онлайн-платежей в результате переговоров по PSD II. Полноценный ответ на этот вопрос потребовал бы учета множества факторов, включая технологическую реализуемость и принятие, удобство использования, ответственность, а также уязвимости и угрозы. Кроме того, необходимо было бы более глубокое понимание специфики анализа рисков, проводимого банком. Тем не менее, подход к обратному проектированию, представленный в этой статье, предлагает интересный набор инструментов для изучения того, как этот самый анализ реализован, а также для оценки того, соответствуют ли полученные решения регулятора интересам клиентов.
Спойлер: Источники
1. Ahmad, Z., Francis, L., Ahmed, T., Lobodzinski, C., Audsin, D., Jiang, P.: Enhancing the security of mobile applications by using TEE and (U)SIM. In: 2013 IEEE 10th International Conference on Ubiquitous Intelligence and Computing and 2013 IEEE 10th International Conference on Autonomic and Trusted Computing. pp. 575–582 (Dec 2013). https://doi.org/10.1109/UIC-ATC.2013.76
2. Alexa: Alexa - Top Sites by Category: Business/E-Commerce (2018), https://goo.gl/V52tcs
3. Ali, M.A., Arief, B., Emms, M., van Moorsel, A.: Does the online card payment
landscape unwittingly facilitate fraud? IEEE Security and Privacy 15(2), 78–86 (2017)
4. AOWASP: Cross-site scripting (XSS) OWASP (2018), https://goo.gl/x54ner
5. Barth, A., Caballero, J., Song, D.: Secure content sniffing for web browsers, or how to stop papers from reviewing themselves. In: Security and Privacy, 2009 30th IEEE Symposium on. pp. 360–371. IEEE (2009)
6. van den Breekel, J., Ortiz-Yepes, D.A., Poll, E., de Ruiter, J.: EMV in a nutshell (2016)
7. CardinalCommerce: Use of consumer authentication in ecommerce, annual survey 2017: The fraud practice (2017), https://goo.gl/z2mByt
8. Emms, M., Arief, B., Freitas, L., Hannon, J., van Moorsel, A.: Harvesting high value foreign currency transactions from EMV contactless credit cards without the PIN. In: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. pp. 716–726. CCS ’14, ACM, New York, NY, USA (2014). https://doi.org/10.1145/2660267.2660312, http://doi.acm.org/10.1145/ 2660267.2660312
9. Emms, M., Arief, B., Little, N., van Moorsel, A.: Risks of offline verify PIN on contactless cards. In: Sadeghi, A.R. (ed.) Financial Cryptography and Data Security. pp. 313–321. Springer Berlin Heidelberg, Berlin, Heidelberg (2013)
10. EMVCo: 3D Secure 2.0 (2017), https://goo.gl/d1ksLf
11. E.solutions: Live HTTP Header (2018), https://www.esolutions.se/
12. Etaher, N., Weir, G.R., Alazab, M.: From ZeuS to ZitMo: Trends in banking malware. In: Trustcom/BigDataSE/ISPA, 2015 IEEE. vol. 1, pp. 1386–1391. IEEE (2015)
13. EU Council: Directive (EU) 2015/2366 (2015), https://goo.gl/psyvps
14. GoogleAndroid: Android pay (2014), https://www.android.com/pay/
15. Harshit Nayyar: Clash of the Titans: ZeuS v SpyEye. SANS Institute InfoSec Reading Room (2010), https://www.sans.org/reading-room/whitepapers/malicious/clash-titans-zeus-spyeye-33393
16. Herley, C., Van Oorschot, P.C., Patrick, A.S.: Passwords: If we’re so smart, why are we still using them? In: International Conference on Financial Cryptography and Data Security. pp. 230–237. Springer (2009)
17. HTTP Watch: HttpWatch 11: HTTP Sniffer for Chrome, IE, iPhone and iPad (2018), https://www.httpwatch.com/
18. Intelligent Systems Lab: JS NICE: Statistical renaming, Type inference and Deobfuscation (2018), http://jsnice.org/
19. Kim, D., Kwon, B.J., Dumitra¸s, T.: Certified malware: Measuring breaches of trust in the windows code-signing PKI. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. pp. 1435–1448. CCS’17, ACM, New York, NY, USA (2017). https://doi.org/10.1145/3133956.3133958, http://doi.acm.org/10.1145/3133956.3133958
20. King, R.: Verified by Visa: bad for security, worse for business - Richard’s Kingdom (2009), https://goo.gl/NgUUvn
21. MalShare: Malware Repository for Researchers (2018), https://malshare.com/
22. Mastercard: Merchant SecureCode implementation guide (2014), https://goo.gl/DyQ7Jb
23. Murdoch, S.J., Anderson, R.: Verified by Visa and MasterCard SecureCode: Or, how not to design authentication. In: Proceedings of the 14th International Conference on Financial Cryptography and Data Security. pp. 336–342. Springer Verlag (2010)
24. Murdoch, S.J., Anderson, R.: Security protocols and evidence: Where many payment systems fail. In: International Conference on Financial Cryptography and Data Security. pp. 21–32. Springer (2014)
25. Murdoch, S.J., Drimer, S., Anderson, R., Bond, M.: Chip and PIN is Broken. In: 2010 IEEE Symposium on Security and Privacy. pp. 433–446. IEEE (2010). https://doi.org/10.1109/SP.2010.33
26. PayPal: PayPal Pro - 3D secure developer guide (2018), https://goo.gl/7mPWWt
27. PCIDSS: Payment card industry (PCI) data security standard requirements and security assessment procedures (2016), https://goo.gl/PNSEq3
28. PCISCC: Payment card industry (PCI) hardware security module (HSM) security requirements (2009), https://goo.gl/JQKH3T
29. RedTeam Pentesting: Man-in-the-Middle Attacks against the chipTAN comfort Online Banking System. Tech. rep. (2009), https://www.redteam-pentesting.de/publications/2009-11-23-MitM-chipTAN-comfort_RedTeam-Pentesting_
EN.pdf
30. RedTeam Pentesting: New banking security system iTAN not as secure as claimed. Tech. rep. (2009), https://www.redteam-pentesting.de/e...security-system-itan-not-as-secure-as-claimed
31. Sood, A.K., Zeadally, S., Enbody, R.J.: An empirical study of HTTP-based financial botnets. IEEE Transactions on Dependable and Secure Computing 13(2), 236–251 (2016)
32. Telerik: Fiddler web debugging tool (2018), https://goo.gl/BURSaH
33. Ter Louw, M., Venkatakrishnan, V.: Blueprint: Robust prevention of cross-site scripting attacks for existing browsers. In: Security and Privacy, 2009 30th IEEE Symposium on. pp. 331–346. IEEE (2009)
34. Thomas, K., Li, F., Zand, A., Barrett, J., Ranieri, J., Invernizzi, L., Markov, Y., Comanescu, O., Eranti, V., Moscicki, A., Margolis, D., Paxson, V., Bursztein, E.: Data breaches, phishing, or malware?: Understanding the risks of stolen credentials. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. pp. 1421–1434. CCS ’17, ACM, New York, NY, USA (2017). https://doi.org/10.1145/3133956.3134067, http://doi.acm.org/10.1145/3133956.3134067
35. Visa Inc: 3D Secure (2017), https://goo.gl/TZSTEc
36. Visa Inc: Visa Developer Centre (2018), https://goo.gl/8dDqWv
37. WickyBay: FRAUDFOX VM, WickyBay Store (2017), https://goo.gl/aAZY1K
38. Zeltser, L.: (2018), https://zeltser.com/malware-sample-sources/
Рис. 5: Зашифрованные данные об отпечатке устройства, отправленные на Сервер аутентификации.
Рис. 6: Зашифрованные данные об отпечатке устройства, отправленные на Сервер аутентификации.
Приложение А: Данные, используемые для анализа рисков
В таблице 2 содержится исчерпывающий список атрибутов устройства для карт C1–C5, которые передаются из браузера инициатора платежа на ACS. Загрузка и выполнение файла dfp.js ACS в рамках процесса оформления заказа были схожими для всех тестовых карт. Колонка «Функции» указывает функции, реализованные в dfp.js, которые извлекают информацию из браузера (для удобства чтения, некоторые названия функций были упрощены). Подробности, извлекаемые каждой функцией, приведены в колонке «Описание функций». Колонка «Источник» указывает источник каждого атрибута (JavaScript или HTTP). Наконец, в правой колонке представлен пример выходного значения каждой функции.
На рисунках 5 и 6 показаны соответственно зашифрованные данные об отпечатке устройства и полный состав cookies.
Таблица 2: Данные, используемые для анализа рисков, которые были извлечены из файла dfp.js.
Ссылка на исходную статью: http://damaga377vyvydeqeuigxvl6g5sbmipoxb5nne6gpj3sisbnslbhvrqd.onion/d/7hmgnkfxd5I2JzCkFxWUpb
Аннотация.
3 Domain Secure 2.0 (3DS 2.0) — это ведущий протокол подтверждения личности пользователей для онлайн-платежей с использованием кредитных карт. Протокол полагается на анализ рисков для принятия решения о том, стоит ли запрашивать у инициатора платежа данные для двухфакторной аутентификации (напр. одноразовый пароль). Сам стандарт 3DS 2.0 не определяет, как должен осуществляться анализ рисков транзакций. В данной статье рассматриваются следующие вопросы:
⦁ Каким образом осуществляется анализ рисков транзакций для исследуемых кредитных карт.
⦁ Существуют ли практические уязвимости в подходе 3DS 2.0 к анализу рисков.
Мы проводим первое в своем роде подробное исследование обратного инжиниринга 3DS 2.0 для платежей через браузер. Определим данные и процесс принятия решений, используемые банками-эмитентами при оценке рисков транзакций для разных карт. Также мы продемонстрируем атаку, позволяющую обойти двухфакторную аутентификацию, используя только данные, полученные в ходе исследования с помощью обратного инжиниринга.
1. Введение
В 2001 году платежные сети (Visa, MasterCard и Amex) представили протокол 3 Domain Secure 1.0 (3DS 1.0) [35]. 3DS 1.0 ввел процедуру проверки пользователей, требуя от инициаторов платежей подтвердить свою личность с помощью статических паролей. Например, сервис «Verified by Visa» запрашивал три символа из установленного пароля. Однако, 3DS 1.0 подвергся критике по причинам безопасности и удобства использования. Безопасность оказалась под угрозой, потому что ввод пароля не мог гарантировать проведение операции владельцем карты. Не исключалось также проведение фишинговых атак на данные карты и пароли. Однако решающим недостатком 3DS 1.0 для продавцов была «потеря продаж», когда покупатели не завершали покупку, потому что не могли вспомнить или отказывались проходить процедуру ввода пароля [3, 23, 20, 16].
Европейская комиссия в 2015 году предложила Директиву 2015/2366 (Вторая Директива об оказании платёжных услуг), регулирующий стандарт, который обязывает эмитентов карт в Европе обеспечивать усиленную процедуру проверки клиента для каждой онлайн-транзакции [13], аналогично реализованной в 3DS 1.0. Индустрия (банки-эмитенты, процессинговые центры и онлайн-продавцы) выразила обеспокоенность тем, что в предложенных в Директиве методах не учтены требования удобства использования, и заявила, что данная процедура проверки должна применяться только к транзакциям, находящихся в «зоне риска» в рамках анализа рисков транзакции. После полугода переговоров с участием более 200 заинтересованных сторон из платежной индустрии, в Директиву в качестве дополнения к усиленной процедуре проверки был добавлен анализ рисков транзакций.
В октябре 2016 года EMVCo (консорциум платежных сетей) пересмотрела 3DS 1.0, включив в него анализ рисков, что привело к созданию текущего протокола 3D Secure 2.0 [10]. 3DS 2.0 предлагает две процедуры проверки: аутентификация и авторизация. Аутентификация применяется для покупок с высоким риском и требует от инициатора платежа прохождения дополнительной проверки. Авторизация не требует дополнительной информации и предназначена для «зеленых» транзакций. Анализ рисков транзакции, с точки зрения безопасности, пренебрегает строгими требованиями безопасности в пользу удобства. Протокол 3DS 2.0 можно считать «разработанным, чтобы быть взломанным».
Протокол 3DS 2.0 не указывает, как именно должен быть реализован анализ рисков, за исключением некоторых общих рекомендаций. В этой статье проводится подробное исследование существующих способов применения 3DS 2.0. Мы покажем, что риски транзакции анализируются на основе данных, собранных через браузер инициатора платежа, а также информации о транзакции или сети (например, суммы транзакции или IP-адреса). Файлы cookie создают «отпечаток» пользователя (см. Раздел 2). В Разделе 4 проводятся дополнительные эксперименты с различными транзакциями и с разных локаций для того, чтобы понять, когда система применяет процедуру проверки «авторизация». Мы увидим, что исследуемые банки-эмитенты по-своему реализуют процедуру анализа рисков, проявляя к ним разные подходы.
В нашем исследовании с использованием обратного проектирования рассматривается пять кредитных карт, как Visa, так и Mastercard, использованных на ряде различных веб-сайтов. Эксперименты с кредитными картами сопряжены с определенными трудностями, например, из-за возможности блокировки карт. Поэтому неудивительно, что литература по экспериментальным исследованиям онлайн-платежей сравнительно невелика и подобные эксперименты ранее не проводились. Пять использованных карт обобщают информацию о банковских картах, поскольку в ходе эксперимента были отмечены похожие «отпечатки». Мы отмечаем, что все карты принадлежали авторам, и получение одобрения этических норм происходило в соответствии с обычными процедурами, проводимыми институтом защиты прав авторов. Ответственное раскрытие информации путем информирования выбранных партнеров было осуществлено через нашу партнерскую сеть.
Дизайн 3DS 2.0 также указывает на очевидную уязвимость — служба анализа транзакции может ошибочно решить не запрашивать дополнительную информацию для проведения платежа. В рамках исследования, мы продемонстрируем атаку с подменой личности, при которой злоумышленник представляется инициатором платежа, "обманывая" службу анализа и позволяя завершить транзакцию без вызова двухфакторной аутентификации, даже для крупных сумм. Мы продемонстрируем две версии атаки: одна предполагает копирование отпечатка пользователя на другую машину, настроенную произвольно, а другая — создание такого же отпечатка на машине с конфигурацией пользователя. Эксплуатация уязвимости может стать практической атакой, если удастся установить вредоносное ПО, с помощью которого отпечаток попадет к злоумышленнику, использующему его для совершения покупки, подменив владельца карты (подробности см. в Разделе 3). Здесь показывается, как подобный способ атаки может быть проведен любым, кто займется обратным проектированием используя информацию из данной статьи.
Рис. 1: Схема обратного проектирования, перехватывающая транзакции 3DS 2.0 с помощью прокси.
2. Подробное рассмотрение анализа рисков транзакции. Создание отпечатка.
Протокол 3DS 2.0 не дает четких указаний по тому, как банки-эмитенты должны реализовывать анализ рисков. Чтобы понять, как продавцы и банки оценивают риски потребительских платежей, мы детально исследовали существующие способы.
2.1 Настройка системы для обратного проектирования
На рис. 1 показана схема настройки системы. В рамках 3DS 2.0 задействовано несколько сервисов и участников:
⦁ инициатор платежа, использующий браузер;
⦁ продавец, предоставляющий страницу оформления заказа для каждой покупки;
⦁ набор служб и серверов для аутентификации, называемых сервером аутентификации платежа (ACS).
ACS хранит данные инициатора платежа, которые могут использоваться для подтверждения личности владельца карты во время покупки.
Чтобы перехватить коммуникации, мы используем прокси Fiddler, доступный в виде ПО с открытым исходным кодом [32]. Прокси запускается на машине инициатора платежа (то есть на нашем собственном компьютере). Мы настраиваем веб-браузер машины на отправку запросов HTTP(S) через Fiddler, который затем перенаправляет трафик продавцу или ACS. Ответы возвращаются в Fiddler, который передает трафик обратно в браузер. Когда включено дешифрование HTTPS, прокси Fiddler генерирует самоподписанный корневой сертификат и соответствующий закрытый ключ. Корневой сертификат используется для создания сертификатов HTTPS для каждого посещаемого защищенного сайта.
Кроме перехвата коммуникации браузера, мы используем два других метода. Во-первых, с помощью Fiddler мы симулируем запросы браузера, как если бы мы были продавцом или эмитентом карты. Во-вторых, используя Fiddler, мы симулируем запросы продавца, как если бы запрос исходил от браузера. Чтобы обрабатывать запросы, Fiddler предоставляет функцию точек прерывания, которая приостанавливает коммуникацию. В это время мы можем изменять данные в запросах.
Всего для наших экспериментов мы использовали пять тестовых карт: три карты Visa (C1-C3) и две карты Mastercard (C4, C5). Чтобы убедиться, что на машине нет предварительно установленных идентификаторов, связанных с 3DS 2.0, мы установили новую операционную систему Windows 10 и браузер Chrome версии 59.x. Использованные веб-сайты торговых площадок, поддерживали оплату через 3D Secure 2.0 и были выбраны из списка торговых сайтов Alexa [2]. Значок «Verified by Visa» на сайте указывает на поддержку 3D Secure. Чтобы гарантировать репрезентативность выборки сайтов, мы отследили URL-адреса ACS, на которые перенаправлялись наши транзакции. Все сайты с пометкой «Verified by Visa» перенаправляли нас на один и тот же URL-адрес ACS, что указывает на то, что реализация 3D Secure зависит от банка. Для каждой тестовой карты мы провели несколько «зеленых» транзакций и записали полные сеансы оформления платежа для каждой транзакции с помощью Fiddler. После прохождения проверки через ACS с использованием бесконтактной авторизации было решено прекратить транзакции. Это гарантирует, что ACS достаточно доверяет браузеру. По мере необходимости, мы декодировали данные транзакций 3D Secure и подробно проанализировали результаты.
2.2 Протокол аутентификации 3DS 2.0
На рис. 2 показана последовательность транзакции для осуществления бесконтактной авторизации в системе 3DS 2.0, объединяя ее спецификации с информацией о транзакциях, извлеченной из Fiddler. Блок «Туннель (Покупатель, ACS)» представляет собой часть транзакции, над которой было проведено обратное проектирование. Этот блок виден в браузере, в то время как другие шаги последовательности транзакции для остальных сторон происходят из спецификаций 3DS 2.0.
Шаг 1 - покупатель инициирует платеж.
Шаг 2 - продавец решает запустить процесс аутентификации пользователя через 3DS 2.0.
Шаги 3-4 - устанавливается соединение между инициатором платежа и ACS.
На шагах 5-11 детально отображено взаимодействие между браузером и ACS, где ACS извлекает данные из браузера, используемые для оценки рисков транзакции.
Шаг 6 - ACS отправляет JavaScript файл dfp.js в браузер и возвращает результаты на шаге 8.
Отметим, что dfp означает "отпечаток устройства" (device fingerprint), который предназначен для идентификации устройства по его характеристикам, чтобы последующий платеж мог быть связан с той же машиной (и, следовательно, с тем же инициатором платежа). Если это первый раз, когда браузер загружает этот JavaScript, ACS повторяет процесс на шагах 9-11 для установки постоянных cookie-файлов в браузер. Далее транзакция обрабатывается в соответствии с правилами, установленными спецификациями EMV 3DS 2.0, которые требуют от сервера 3DS отправки запроса на аутентификацию в ACS. Анализ рисков транзакции завершается на шаге 13, в результате чего принимается решение о проведении транзакции через бесконтактную авторизацию. Теперь продавец может отправить запрос на авторизацию (шаг 15).
Рис. 2: Последовательность проведения транзакции через бесконтактную авторизацию.
2.3 Данные для анализа рисков транзакции в 3DS 2.0
С помощью обратного проектирования можно увидеть, как ACS создает отпечаток машины инициатора платежа. Он использует три типа информации для создания отпечатка, речь о них пойдет далее:
⦁ Информация об отпечатке, извлекаемая из браузера с помощью JavaScript.
⦁ Идентификаторы 3DS 2.0, полученные с помощью cookie-файлов браузера.
⦁ HTTP-заголовки, отправляемые браузером инициатора платежа и передаваемые продавцом в ACS.
Отпечаток данных с использованием JavaScript
Анализируемые нами скрипты для снятия отпечатков с помощью JavaScript содержат функции для:
⦁ Сбора информации, предоставляемой браузером с устройства пользователя
⦁ Отправки собранных данных на сервер 3DS 2.0 в виде одной строки, закодированной в формате Base-64 (спецификации 3DS 2.0 [10] требуют, чтобы все сообщения данных были в формате Base-64).
В таблице 2 (Приложение A) представлен исчерпывающий список атрибутов устройства, передаваемых от браузера инициатора платежа в ACS для карт C1-C5. В ходе процесса оформления заказа, загрузка и выполнение скрипта
dfp.js сервером аутентификации идентичны для всех используемых карт.Полученные данные очень разнообразны. От информации о браузере и операционной системе до характеристик экрана, времени, геолокации и некоторых плагинов. Скрипт для снятия отпечатков получает информацию, которая является частью HTTP-заголовков, через функции
nav.userAgent() и test() (см. таблицу 2). Основная функция называется deviceprint browser(), которая собирает информацию о браузере и операционной системе. Что касается геолокации, насколько нам известно, ACS использует только информацию о том, включена ли геолокация и в каком часовом поясе находится устройство (через deviceprint timez()). Он, вероятно также использует информацию об URL-адресе и/или IP-адресе в качестве показателя местоположения, но это собирается другим способом. Информация о аппаратном обеспечении устройства собирается с помощью deviceprint display() и window information(). Настройки браузера о предпочтениях по отслеживанию и рекламе предоставляются функциями DoNotTrack и Useofadblock. Наконец, deviceprint software() и flashscript() предоставляют информацию о конкретных программных компонентах. В наших экспериментах только один ACS запрашивал информацию о Flash через flashscript(). Для передачи данных об отпечатке скрипт dfp.js использует еще два метода:⦁
encode deviceprint() комбинирует собранные данные в одну строку. Он форматирует строку, удаляя пробелы, добавляя разделители и другие символы, как того требует ACS.⦁
asyncpost deviceprint(url) отправляет данные на URL-адрес ACS. Данные конвертируются в Base-64 перед отправкой в виде элемента формы на URL-адрес ACS.Пример зашифрованного отпечатка устройства представлен на рисунке 5 в Приложении A.
Cookie-файлы
Мы обнаружили три типа cookie-файлов, установленных ACS на наших машинах. Они также описаны в нижних строках таблицы 2. Полные cookie-файлы приведены на рисунке 6 в Приложении A.
⦁ Session_cookie. Сессионный cookie удаляется после закрытия браузера пользователем.
⦁ Test_cookie. Тестовый cookie с именем TESTCOOKIE и значением Y наблюдался при обмене данными в ходе транзакции. Он устанавливается сервером аутентификации для проверки того, разрешены ли cookies в настройках браузера пользователя.
⦁ IDcookie. Когда держатель карты впервые регистрируется в системе 3DS 2.0, в браузер пользователя добавляется токен в виде ID Cookie(s). Количество устанавливаемых cookies варьируется от одного до трех. Во всех случаях мы обнаружили, что срок действия этих cookies составляет три года с момента установки, и они имеют метку безопасности HTTP-only. Эта метка защищает cookie от доступа со сторонних веб-сайтов.
Данные, передаваемые продавцом в ACS
Данные, передаваемые продавцом в сообщении AReq (шаг 12 на рис. 2), содержат элементы, которые идентифицируют конфигурацию браузера инициатора платежа. Например, таблица A.1 в спецификациях EMV 3DS 2.0 [10] предлагает продавцам передавать заголовки браузера, язык, параметры экрана и user agent в сообщении AReq. Конфигурация браузера помогает ACS корректно отображать iframe для устройства держателя карты и может использоваться сервером аутентификации для сравнения информации, передаваемой скриптом
dfp.js. Чтобы изучить методы, с помощью которых продавец собирает данные для создания сообщения AReq, мы обратились к руководствам разработчиков от платежных сетей Visa [36] и MasterCard [22], а также от платежных сервисов, таких как PayPal [26], которые предлагают использовать HTTP-заголовки, передаваемые продавцом во время оформления заказа как часть данных для аутентификации в браузере.2.4 Обсуждение реализаций 3DS 2.0
Существуют несколько заметных различий между реализациями 3DS 2.0. Их можно классифицировать следующим образом:
⦁ Различие в использовании версии протокола 3DS.
⦁ Различие в передаче данных об отпечатке устройства: обфусцированные данные против данных в открытом виде.
⦁ Различие в объеме данных, собираемых для создания отпечатка: на основе JavaScript против данных, собранных только с использованием HTTP-заголовков и cookies.
Различие в использовании версии протокола 3DS
Мы обнаружили, что ACS, связанный с картой C2, добавляет слой бесконтактной авторизации поверх протокола 3DS 1.0. В отличие от 3DS 2.0, браузер собирает и отправляет сообщение AReq с идентификатором транзакции, следуя спецификации 3DS 1.0. ACS устанавливает и собирает данные отпечатка из браузера. Аналогично бесконтактной авторизации в 3DS 2.0, ACS повторяет сообщения для установки ID Cookie в случае, если это первая транзакция через 3DS 1.0 с этого устройства. Далее транзакция обрабатывается в соответствии со спецификацией 3DS 1.0. Решение ACS (не запрашивать данные) добавляется в сообщение ARes, которое затем передается продавцу через браузер. Сравнивая бесконтактную авторизацию в 3DS 1.0 и 3DS 2.0, можно сказать, что оба этих протокола захватывают статические данные отпечатка в формате Base-64 и используют HTTP-only ID Cookies для анализа рисков транзакции.
Различие в реализации отпечатка устройства
В двух случаях (C2 и C5) мы заметили, что для того, чтобы затруднить чтение и анализ JavaScript, применялись техники обфускации кода. Однако они, в свою очередь, имеют определенные общие ограничения, поскольку это метод кодирования (а не шифрования), и код должен сохранять свою функциональность при выполнении на системе. Тем не менее, JavaScript для создания отпечатков устройств в 3DS 2.0 все еще может выполняться для получения значений отпечатка устройства в формате Base-64.
Кроме того, техника обфускации кода давно используется авторами вредоносного ПО для скрытия своего кода. Поэтому, в открытом доступе существует множество учебных материалов и инструментов безопасности, предназначенных для деобфускации JavaScript. Самый надежный из нами обнаруженных, разработан компанией Intelligent Systems Lab, Zurich [18] и имеет открытый исходный код.
Различие в объеме собираемых данных устройства
Хотя таблица 2 показывает исчерпывающий список всех элементов данных, собираемых скриптами и HTTP-заголовками, объем данных, собираемых при каждой реализации JavaScript, значительно варьируется. Некоторые банки вообще не внедряют JavaScript для создания отпечатков устройства. Например, банк-эмитент карты C3 реализует бесконтактную авторизацию на основе 3DS 1.0 и полагается только на данные, полученные в сообщении AReq.
Напоследок отметим, что протокол 3DS 2.0 также определяет этап регистрации, в ходе которого банк собирает отпечатки устройства компьютера держателя карты и подписывает данные об отпечатках для создания ID Cookies. Затем, для создания ID Cookies, компьютер держателя карты "помечается" с помощью стандартного механизма cookie. Этот этап регистрации несовершенен, так как невозможно определить, является ли инициатор платежа ее законным пользователем.
3. Атака с подменой личности
В этом разделе мы разработаем реалистическую атаку с подменой личности, при которой злоумышленник использует полученные данные, описанные в предыдущем разделе, и постарается избежать запроса на предоставление данных для двухфакторной аутентификации. Сначала, в разделе 3.1, мы опишем модель атаки, а затем, в разделе 3.2 метод реализации подобной атаки, в особенности часть, касающуюся получения данных. На различных машинах, нами было проведено определенное количество экспериментов, чтобы продемонстрировать, что атака с подменой личности действительно может быть успешной, что и будет показано в разделе 3.3.
3.1 Модель атаки
Цель атаки заключается в том, чтобы использовать кредитную карту другого человека для совершения онлайн-покупки, несмотря на использование торговой точкой протокола 3DS 2.0. Мы предполагаем, что злоумышленник не может успешно пройти двухфакторную аутентификации. Следовательно, цель злоумышленника — избежать запроса и завершить транзакцию путем бесконтактной аутентификации. Атака считается успешной, если злоумышленник избегает прохождение проверки в ситуациях, когда на самом деле ACS должен был отреагировать иначе.
Для совершения успешной транзакции, злоумышленнику необходимо получить данные кредитной карты, cookies и данные отпечатка устройства, используемые для анализа рисков транзакции, как описано в предыдущем разделе. Не предполагается, что злоумышленник располагает правами доступа администратора на машине инициатора платежа или на каких-либо службах 3DS 2.0. Предполагается, что злоумышленник устанавливает вредоносное ПО или плагин, который собирает необходимые данные с машины инициатора платежа, включая выполнение JavaScript для создания отпечатка устройства (в следующем разделе обсуждается, что это вполне возможно). После отправки этих данных злоумышленник может подменить личность держателя карты, сгенерировав данные для аутентификации в 3DS 2.0, соответствующие данным инициатора платежа.
3.2 Осуществление атаки
Процесс атаки должна состоять из двух этапов:
⦁ Получение данных о карте и анализе рисков транзакции
⦁ Использование полученных данных
Получение данных о карте и анализе рисков транзакции
На этом этапе злоумышленнику необходимо получить данные кредитной карты и отпечатки устройства (включая cookies). Существует ряд причин, по которым это можно сделать только через атаку типа "человек в браузере" (Man in the Browser).
Проблема заключается в том, что cookie-файлы с идентификаторами (см. Раздел 2.3) защищены флагом HTTP-only, то есть они не могут быть прочитаны с других доменов или через JavaScript. Однако браузеры предоставляют доступ к таким HTTP-only cookie расширениям (включая вредоносные программы), так как расширения считаются "доверенными" после установки, в отличие от обычного JavaScript. Поэтому атаки типа межсайтового скриптинга (XSS) [5, 4, 33], при которых скрипт с веб-сайта, отличного от сайта продавца или сервера 3DS 2.0, пытается получить доступ к информации, такой как cookie, невозможны.
Самый простой способ получения необходимых данных — это использование плагина, который может отслеживать коммуникации в браузере, чтобы украсть cookies с флагом HTTP-only, записывать нажатия клавиш для кражи данных пользователя и выполнять скрипты JavaScript для создания отпечатков устройства. Более продвинутое вредоносное ПО имеет такие функции и находится в открытом доступе (например, ZeuS, SpyEye, Dridex и Tinba). Как только такое ПО установлено, оно может получать данные о транзакциях, связанные с покупкой, а также данные об анализе рисков транзакций и cookies с флагом HTTP-only. Например, такое ПО как SpyEye проникает в браузер, предлагая пользователю установить PDF-reader или плагин для Flash Player. После проникновения оно обновляется по мере необходимости, чтобы настроить поддельные сертификаты в хранилище браузера, записывать нажатия клавиш, перехватывать коммуникации браузера, фиксировать сессии браузера и даже делать скриншоты [31, 15].
Использование полученных данных
На этом этапе, задача состоит в том, чтобы подменить личность владельца карты в браузере злоумышленника. Последний копирует cookies в свой браузер и инициирует транзакцию, даже если продавец использует 3DS 2.0. Он также использует данные кредитной карты и отпечатки устройства. При оплате злоумышленник создает или воспроизводит правильные ответы в протоколе, показанном на рис. 2. Поскольку в данных отпечатков устройства нет случайных элементов, те же самые данные dfp.js и HTTP-заголовков, полученные с машины инициатора платежа, можно воспроизвести на машине злоумышленника с использованием Fiddler. Чтобы изменять данные, в Fiddler добавляются точки прерывания всякий раз, когда продавец и ACS подключаются к браузеру злоумышленника.
3.3 Демонстрация атаки
Демонстрация атаки нацелена на определение возможности подмены личности инициатора платежа с другого устройства. В этом эксперименте мы использовали данные, полученные с машины M1, используя установку, показанную на рис. 1. Мы случайным образом выбрали продавца с поддержкой оформления заказов через 3DS 2.0 и провели транзакции с использованием всех тестовых карт (C1-C5), пока M1 не стал доверенным для бесконтактной авторизации. Платежные сеансы, выполненные с M1, были записаны через прокси Fiddler и использовались на другой машине M2 с иной конфигурацией. Далее также показано, что на машине M3, настроенной идентично, генерируются такие же отпечатки. Стоит отметить, что M2 и M3 находились в разных сетях, то есть IP-адреса источников были разными.
Примененный нами подход к исследованию выглядит следующим образом: для всех пяти карт проводится один и тот же эксперимент. Во-первых, проверяется, что транзакции с машины M2 с иной конфигурацией действительно заканчиваются вызовом двухфакторной аутентификации, если введены только данные карты (и отпечаток инициатора не подделывается). Эта проверка была успешной во всех случаях, за исключением карты C1, где были одобрены транзакции на небольшие суммы, менее 10 фунтов стерлингов (мы вернемся к этому позже). Затем был проведен эксперимент, в ходе которого использовались данные об анализе рисков транзакции для подмены личности владельца карты, чтобы проверить, удастся ли провести «зеленую» покупку. Мы создали транзакции на товары стоимостью от 1 до 300 фунтов на онлайн-платформе с поддержкой 3DS 2.0.
Нам удалось успешно выполнить атаку для всех тестовых карт, и транзакции были одобрены без каких-либо запросов со стороны ACS. Примечательно, что только для тестовой карты C5, ACS банка выдал запрос на двухфакторную аутентификацию при проведении платежа выше 200 фунтов стерлингов (стандартный лимит бесконтактной авторизации).
Затем, был проведен второй эксперимент с использованием другой, но идентично настроенной машины M3 с тем же аппаратным и программным обеспечением, что и M1. Таким образом, мы хотели выяснить, генерируют ли разные машины с идентичной конфигурацией одинаковые данные отпечатков устройства. Это имитирует сценарий, при котором злоумышленник не смог получить данные отпечатков устройства, но получил ID Cookies. Во всех случаях транзакции были осуществлены успешно. Тщательный анализ данных, отправленных с M3 продавцу и ACS, показал, что данные об анализе рисков транзакции были практически идентичны для M1 и M3.
Заключение
Для покупателей важно понимать, как продавцы и банки реагируют в случае подобной атаки. Мы связались с последними, чтобы узнать, как они отреагируют, если мы сообщим о транзакциях, выполненных с машины злоумышленника. Банк-эмитент карты C3 попросил держателя карты указать несколько предыдущих транзакций, сделанных с машины жертвы, и не отметил транзакции, совершенные с машины злоумышленника, как мошеннические. Он также заблокировал и переиздал держателю карту. Однако в двух случаях (C4 и C5) банки-эмитенты заявили, что транзакции должно быть, были осуществлены с устройства держателя карты. Они утверждали, что держатель пытается совершить «дружественное мошенничество», и отказали в возмещении убытков. Это исследование показывает, что приводимые банками заключения не всегда являются верными.
4. Обратное проектирование анализов рисков транзакции: принятие решений
В разделе 2 рассмотрено, какие данные используются в подходе 3DS 2.0 к анализу рисков транзакций. А нами было показано, что с помощью этих данных можно выполнить атаку с подменой личности. Однако это все еще не дает полного понимания того, каким именно образом ACS анализирует риски. Во-первых, сервер может использовать дополнительные источники данных, например, IP-адрес или другую информацию о владельце карты, доступную банку-эмитенту. Во-вторых, он устанавливает определенные правила о том, когда следует запрашивать двухфакторную аутентификацию. Эти правила определяют, какие данные об отпечатках устройства следует учитывать, и устанавливают пороговые значения для транзакции (напр. лимит на сумму транзакции).
Таблица 1: Результаты проведенных экспериментов для карт С1 и С2.
Есть несколько интересных вопросов, благодаря которым проводится дальнейшее обратное проектирование подхода к анализу рисков. Во-первых, это позволяет узнать, какие варианты атаки с подменой личности могут быть успешными, и таким образом оценить безопасность и риски онлайн-платежей. Во-вторых, это может предложить методологию для оценки последствий анализа рисков транзакций для покупателей. TRA перекладывает ответственность на банк, но при этом, потребитель все равно подвергается возможным рискам в случае осуществления подобной атаки. Таким образом, можно утверждать, что должна быть осуществлена прозрачность в реализации анализа рисков транзакций в интересах общественности. Благодаря проведенному в этом разделе обратному проектированию мы можем наблюдать осуществление этой прозрачности.
По результатам проведенных в данном разделе экспериментов, ожидается получение ответов от ACS для транзакций в восьми разных сценариях.
Эти сценарии включают все комбинации следующих трех характеристик:
⦁ Отправка или не отправка данных устройства и ID Cookies.
⦁ Различные суммы транзакций.
⦁ Транзакции, осуществляемые из разных регионов.
На таблице 1 показаны результаты экспериментов с картами C1 и C2. Наша настройка была идентична описанной в разделе 3, с использованием данных, полученных с машины M1 на альтернативной машине M2. Платежи осуществлялись на двух веб-сайтах (W1 и W2), взаимодействующих через 3DS. W1 — это онлайн-магазин, находящийся в стране держателя карты, а W2 — зарубежный продавец.
Строки таблицы показывают различные сценарии. Например, сценарий S1 копирует данные устройства и ID Cookie для транзакции на небольшую сумму внутри региона. Что касается региона, эксперименты для C1 и C2 проводились из Великобритании и Германии. Галочка в графе «Регион» указывает, что попытки транзакций проводились на территории страны держателя карты. Разные банки по-своему анализируют риски. В частности, банк-эмитент карты C1 позволяет проводить больше транзакций через бесконтактную авторизацию, тогда как банк-эмитент C2 чаще требует подтверждения от инициатора платежа. Сравнивая транзакции T4 и T10 для карты C2, мы видим, что банк запрашивает подтверждение для каждой транзакции, если веб-мерчант находится в другой стране. Из таблицы 1 также видно, что карты, как правило, подвергаются более строгим проверкам, если транзакции осуществляются из других регионов. Например, при совершении транзакции из другой страны, данные устройства были изменены, и вероятность необходимости подтверждения и отказа в транзакции возрастает (в отличие от транзакций, инициированных из страны, где находится эмитент карты).
Рис. 3: Результаты анализа рисков для C1 на веб-сайтах W1 и W2.
Рис. 4: Результаты анализа рисков для C2 на веб-сайтах W1 и W2.
Рисунки выше представляют собой этапы транзакции в рамках 3DS 2.0, где «Оплата» обозначает начало платежа, а остальные состояния относятся к возможным исходам: «одобрено», «проверка/отклонение» или «блокировка». Обратите внимание, что для наших целей нет необходимости разделять «проверка» и «отклонение», так как оба означают, что транзакция не была проведена через бесконтактную аутентификацию. Дуги помечены сценариями, указанными во втором столбце Таблицы 1. CAC (Challenge Limit Counter) обозначает счётчик лимита запросов подтверждения, который отсчитывает от заданного лимита до нуля. В данном случае лимит равен 4, и при пятой попытке карта блокируется. Для злоумышленника Рисунки 3 и 4 могут служить картой-ориентиром на случай, если будет собрано больше данных, относящихся к картам, выпущенным банками C1 и C2.
5. Обсуждение безопасности систем платежей по картам
Проблема подтверждения личности держателей карт в системе онлайн-платежей усугубляется стремлением повысить уровень комфорта в процессе оформления заказа. Введение протокола 3DS 2.0 решает проблему баланса между безопасностью и удобством благодаря использованию анализа рисков транзакции. Очевидно, что индустрия активно поддерживает подходы, основанные на анализе рисков, поскольку, как показывают данные, около 75% банков-эмитентов в США внедрили риск-ориентированную аутентификацию [7]. Тем не менее, как было показано в данной работе, оставшимся брешами в обеспечении безопасности остаются:
⦁ надёжное хранение данных аутентификации устройства;
⦁ безопасная передача этих данных и http-only cookie с устройства клиента в сервис аутентификации;
Когда 3DS 2.0 будет использоваться повсеместно, и транзакции через бесконтактную авторизацию перестанут быть уязвимыми, то атака, описанная в этой статье, может стать объектом внимания для злоумышленников. Её основным эффектом будет возможность использовать украденные данные для проведения транзакции без аутентификации 3DS 2.0 в интернет-магазинах без каких-либо последствий для держателя карты, точно так же, как это происходило с системами, основанными только на авторизации, до внедрения 3D Secure. Этот метод атаки не требует синхронизации мошеннической покупки с действиями ничего не подозревающего клиента (как в случае с релейной атакой). Вредоносное ПО может быть легко создано для перехвата данных транзакции и их последующей передачи на сервер злоумышленника. На самом деле, существует ряд подобных расширений браузеров с открытым исходным кодом, которые доступны и установлены в тысячах браузеров, например, HTTPWatch [17] и LiveHTTPHeaders [11]. Другие разработки, такие как FraudFox [37], также вызывают серьёзные опасения. FraudFox нацелен на то, чтобы упростить и ускорить изменение отпечатка браузера, чтобы он соответствовал отпечатку жертвы, например, с помощью генераторов профилей.
Попытки усложнить выполнение атаки с помощью обфускации JavaScript, как это реализовано в некоторых системах, вряд ли окажутся эффективными. В Интернете существует множество инструментов и руководств, которые позволяют восстановить исходные данные, поэтому обфускация скриптов далеко не достаточная мера. Более полезным является подход к хранению cookie-файлов, наблюдаемый в рассматриваемых реализациях. Все обнаруженные нами cookie-файлы с идентификаторами имели атрибут secure, что означает, что они передаются только по защищённым соединениям (HTTPS). Во-вторых, они были помечены как http-only, что подразумевает, что JavaScript не имеет к ним доступа. Это предотвращает доступ к cookie-файлам с междоменных веб-сайтов, то есть защищает от атак типа межсайтового скриптинга (XSS). Тем не менее, хранение cookie-файлов в браузерах остаётся небезопасным, если на устройстве не используется надёжное хранилище.
С технологической точки зрения, очевидным решением для безопасной передачи данных могло бы быть использование методов с закрытым и открытым ключом для шифрования и подписания сообщений между инициатором платежа и сервером 3DS. Однако для того чтобы такое решение было принято, потребуется отдельная надёжная среда для хранения криптографических ключей и сертификатов. Стандарты платёжной индустрии [27, 28] требуют, чтобы платёжные данные, включая ключи и сертификаты, хранились в «модуле защиты от несанкционированного доступа», который определяется как набор аппаратного, программного обеспечения, прошивки или их комбинации, реализующий криптографическую логику или процесс (включая криптографические алгоритмы и генерацию ключей) и находящийся внутри криптографической границы. Современные компьютерные системы и их программное обеспечение пока недостаточно надёжны для обеспечения такой безопасности. Эта проблема уже поднималась, когда Google впервые представил Android Pay с концепцией эмуляции карты на хосте в Android KitKat 4.4 [14] в 2014 году. Модель безопасности хранения ключей в случае с концепцией эмуляции карты управлялась программным обеспечением, что создавало угрозу компрометации операционной системы мобильного устройства для кражи данных. Поэтому этот подход был признан неподходящим для размещения платёжных приложений стандарта EMV [1].
6. Смежные направления исследований
В этом разделе представлено сравнение протоколов оплаты по картам и технологий безопасности, которые они используют. Также рассматриваются зарегистрированные атаки на карточные платежи, которые становятся возможными при отсутствии определённых функций безопасности в протоколе. Полный разбор всех технологий и протоколов выходит за рамки данного обсуждения, однако нами предлагается краткое изложение ключевых аспектов.
Решения для физически присутствующих карт
Эта категория относится к платежам, когда карта физически присутствует. В случае карт с магнитной полосой функции обеспечения целостности данных и аутентификации карты (подтверждения её подлинности) не были реализованы непосредственно на самой карте. Данные, хранящиеся на магнитной полосе, являются статичными и представлены в открытом виде, что делало такие карты уязвимыми для атак, связанных с кражей идентификационных данных [23], подделкой личности держателя карты [24] и клонированием карт [6].
EMV расширил возможности смарт-карт, обеспечив безопасное, "неподделываемое" хранилище для криптографических закрытых ключей карты. В протоколе Chip and PIN, определённым EMV, используется инфраструктура открытых ключей RSA в трёх вариантах. Карта со статической аутентификацией данных (Static Data Authentication) имеет постоянную подпись, которая генерируется банком-эмитентом, подписывается с использованием его закрытого ключа и записывается на карту в процессе её производства. Однако статические подписи используются для одобрения каждой транзакции, что делает такие карты уязвимыми для атак с помощью копирования данных [6][25]. В то время как в картах с динамической аутентификацией данных (Dynamic Data Authentication) генерируется уникальная подпись RSA "вызов-ответ" для каждой транзакции, включая случайные. Комбинированная аутентификация данных улучшает динамическую, кодируя прикладную криптограмму в подписи, а не данные транзакции. Это делает динамический и, особенно, комбинированный методы аутентификации крайне устойчивыми к любым формам атак.
EMV contactless обеспечивает удобство для клиента, аутентифицируя карту вместо того, чтобы просить держателя одобрить транзакцию [9]. Fast DDA (fDDA) (динамический и CDA (fCDA) — это улучшенные версии DDA и CDA в протоколе Chip and PIN, исключающие методы аутентификации держателя из протокола. Оба варианта DDA и SDA обеспечивают защиту от известных атак на платёжную систему. Однако каждая транзакция с использованием DDA и SDA требует от держателя карты подтверждения своей личности, что негативно сказывается на удобстве использования. Эта проблема была решена с помощью улучшенных версий fDDA и fCDA в EMV contactless [8].
Решения для физически не присутствующих карт
Если карта не присутствует, то ситуация, как мы увидели в этой статье, становится очень сложной. Как обсуждалось во введении, осложнения, связанные с реализацией протокола 3DS 1.0, позволяли злоумышленникам обходить его функции безопасности и выполнять атаки связанные с кражей личных данных [23][16]. Программа аутентификации с чипом (Chip Authentication Program) и номера аутентификации транзакции (Transaction Authentication Number) [30][29] — это две технологии генерации токенов, которые используются потребителями для создания ответа на запрос из системы авторизации. Обычно это делается с помощью небольшого устройства, которое считывает данные с кредитной карты и/или использует ПИН-код для создания ответа на запрос. Эти технологии все чаще предоставляются банками, однако в большинстве случаев они ограничены платежами, выполняемыми через банковские транзакции.
В заключение, для разных целей были разработаны различные платежные протоколы. Удовлетворительные решения находят успешное сочетание удобства использования и безопасности, а также управляют рисками на случай, если что-то пойдет не так. Например, лимиты транзакций для бесконтактных карт и лимит для платежей через бесконтактную авторизацию 3DS 2.0 оба управляют рисками, ограничивая возможные потери для потребителей. Неудивительно, что разумные подходы требуют двухфакторной аутентификации путем ввода ПИН-кода, как в системе Chip and PIN, или через подтверждение личности держателя в 3DS 2.0, либо с использованием генераторов токенов, как в CAP и TAN. Однако эти методы не удовлетворяют требованиям удобства для продавцов, оставляя потребителей с системами, такими как 3DS 2.0, которые спроектированы таким образом, чтобы допускать менее безопасные платежи и, следовательно, неизбежно (и по замыслу) подвергать потребителей и банков-эмитентов риску мошенничества.
7. Заключение
В данной работе представлено первое практическое исследование реализаций протокола 3DS 2.0. В ходе обратного проектирования мы определили последовательности транзакций для бесконтактной авторизации. В большинстве рассмотренных способов, машина инициатора платежа идентифицируется с помощью JavaScript, за исключением реализации на основе 3DS 1.0. В наших экспериментах мы получили дополнительные сведения о процессе принятия решений службой авторизации, проводя эксперименты с различными суммами транзакций и регионами, из которых проводились платежи. Мы обнаружили, что банки-эмитенты различаются по степени готовности принимать риски: некоторые из них значительно более лояльно разрешают проводить транзакции без дополнительных проверок.
Нами была также продемонстрирована атака с подменой личности против 3DS 2.0, используя только данные, которые доступны благодаря обратному проектированию, описанному в этой статье. Этот способ атаки практически осуществим и использует тот факт, что информация об отпечатке устройства инициатора платежа может быть воссоздана с помощью вредоносного ПО или плагинов, если они установлены на устройстве. Этот эксплойт подчеркивает уязвимость платежей с использованием браузеров на основе кредитных карт по сравнению с более продвинутыми методами безопасности мобильных платежей.
Ключевой вопрос для регулятора заключается в том, было ли оправданным разрешить подход, основанный на оценке рисков, для обеспечения безопасности онлайн-платежей в результате переговоров по PSD II. Полноценный ответ на этот вопрос потребовал бы учета множества факторов, включая технологическую реализуемость и принятие, удобство использования, ответственность, а также уязвимости и угрозы. Кроме того, необходимо было бы более глубокое понимание специфики анализа рисков, проводимого банком. Тем не менее, подход к обратному проектированию, представленный в этой статье, предлагает интересный набор инструментов для изучения того, как этот самый анализ реализован, а также для оценки того, соответствуют ли полученные решения регулятора интересам клиентов.
Спойлер: Источники
1. Ahmad, Z., Francis, L., Ahmed, T., Lobodzinski, C., Audsin, D., Jiang, P.: Enhancing the security of mobile applications by using TEE and (U)SIM. In: 2013 IEEE 10th International Conference on Ubiquitous Intelligence and Computing and 2013 IEEE 10th International Conference on Autonomic and Trusted Computing. pp. 575–582 (Dec 2013). https://doi.org/10.1109/UIC-ATC.2013.76
2. Alexa: Alexa - Top Sites by Category: Business/E-Commerce (2018), https://goo.gl/V52tcs
3. Ali, M.A., Arief, B., Emms, M., van Moorsel, A.: Does the online card payment
landscape unwittingly facilitate fraud? IEEE Security and Privacy 15(2), 78–86 (2017)
4. AOWASP: Cross-site scripting (XSS) OWASP (2018), https://goo.gl/x54ner
5. Barth, A., Caballero, J., Song, D.: Secure content sniffing for web browsers, or how to stop papers from reviewing themselves. In: Security and Privacy, 2009 30th IEEE Symposium on. pp. 360–371. IEEE (2009)
6. van den Breekel, J., Ortiz-Yepes, D.A., Poll, E., de Ruiter, J.: EMV in a nutshell (2016)
7. CardinalCommerce: Use of consumer authentication in ecommerce, annual survey 2017: The fraud practice (2017), https://goo.gl/z2mByt
8. Emms, M., Arief, B., Freitas, L., Hannon, J., van Moorsel, A.: Harvesting high value foreign currency transactions from EMV contactless credit cards without the PIN. In: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. pp. 716–726. CCS ’14, ACM, New York, NY, USA (2014). https://doi.org/10.1145/2660267.2660312, http://doi.acm.org/10.1145/ 2660267.2660312
9. Emms, M., Arief, B., Little, N., van Moorsel, A.: Risks of offline verify PIN on contactless cards. In: Sadeghi, A.R. (ed.) Financial Cryptography and Data Security. pp. 313–321. Springer Berlin Heidelberg, Berlin, Heidelberg (2013)
10. EMVCo: 3D Secure 2.0 (2017), https://goo.gl/d1ksLf
11. E.solutions: Live HTTP Header (2018), https://www.esolutions.se/
12. Etaher, N., Weir, G.R., Alazab, M.: From ZeuS to ZitMo: Trends in banking malware. In: Trustcom/BigDataSE/ISPA, 2015 IEEE. vol. 1, pp. 1386–1391. IEEE (2015)
13. EU Council: Directive (EU) 2015/2366 (2015), https://goo.gl/psyvps
14. GoogleAndroid: Android pay (2014), https://www.android.com/pay/
15. Harshit Nayyar: Clash of the Titans: ZeuS v SpyEye. SANS Institute InfoSec Reading Room (2010), https://www.sans.org/reading-room/whitepapers/malicious/clash-titans-zeus-spyeye-33393
16. Herley, C., Van Oorschot, P.C., Patrick, A.S.: Passwords: If we’re so smart, why are we still using them? In: International Conference on Financial Cryptography and Data Security. pp. 230–237. Springer (2009)
17. HTTP Watch: HttpWatch 11: HTTP Sniffer for Chrome, IE, iPhone and iPad (2018), https://www.httpwatch.com/
18. Intelligent Systems Lab: JS NICE: Statistical renaming, Type inference and Deobfuscation (2018), http://jsnice.org/
19. Kim, D., Kwon, B.J., Dumitra¸s, T.: Certified malware: Measuring breaches of trust in the windows code-signing PKI. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. pp. 1435–1448. CCS’17, ACM, New York, NY, USA (2017). https://doi.org/10.1145/3133956.3133958, http://doi.acm.org/10.1145/3133956.3133958
20. King, R.: Verified by Visa: bad for security, worse for business - Richard’s Kingdom (2009), https://goo.gl/NgUUvn
21. MalShare: Malware Repository for Researchers (2018), https://malshare.com/
22. Mastercard: Merchant SecureCode implementation guide (2014), https://goo.gl/DyQ7Jb
23. Murdoch, S.J., Anderson, R.: Verified by Visa and MasterCard SecureCode: Or, how not to design authentication. In: Proceedings of the 14th International Conference on Financial Cryptography and Data Security. pp. 336–342. Springer Verlag (2010)
24. Murdoch, S.J., Anderson, R.: Security protocols and evidence: Where many payment systems fail. In: International Conference on Financial Cryptography and Data Security. pp. 21–32. Springer (2014)
25. Murdoch, S.J., Drimer, S., Anderson, R., Bond, M.: Chip and PIN is Broken. In: 2010 IEEE Symposium on Security and Privacy. pp. 433–446. IEEE (2010). https://doi.org/10.1109/SP.2010.33
26. PayPal: PayPal Pro - 3D secure developer guide (2018), https://goo.gl/7mPWWt
27. PCIDSS: Payment card industry (PCI) data security standard requirements and security assessment procedures (2016), https://goo.gl/PNSEq3
28. PCISCC: Payment card industry (PCI) hardware security module (HSM) security requirements (2009), https://goo.gl/JQKH3T
29. RedTeam Pentesting: Man-in-the-Middle Attacks against the chipTAN comfort Online Banking System. Tech. rep. (2009), https://www.redteam-pentesting.de/publications/2009-11-23-MitM-chipTAN-comfort_RedTeam-Pentesting_
EN.pdf
30. RedTeam Pentesting: New banking security system iTAN not as secure as claimed. Tech. rep. (2009), https://www.redteam-pentesting.de/e...security-system-itan-not-as-secure-as-claimed
31. Sood, A.K., Zeadally, S., Enbody, R.J.: An empirical study of HTTP-based financial botnets. IEEE Transactions on Dependable and Secure Computing 13(2), 236–251 (2016)
32. Telerik: Fiddler web debugging tool (2018), https://goo.gl/BURSaH
33. Ter Louw, M., Venkatakrishnan, V.: Blueprint: Robust prevention of cross-site scripting attacks for existing browsers. In: Security and Privacy, 2009 30th IEEE Symposium on. pp. 331–346. IEEE (2009)
34. Thomas, K., Li, F., Zand, A., Barrett, J., Ranieri, J., Invernizzi, L., Markov, Y., Comanescu, O., Eranti, V., Moscicki, A., Margolis, D., Paxson, V., Bursztein, E.: Data breaches, phishing, or malware?: Understanding the risks of stolen credentials. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. pp. 1421–1434. CCS ’17, ACM, New York, NY, USA (2017). https://doi.org/10.1145/3133956.3134067, http://doi.acm.org/10.1145/3133956.3134067
35. Visa Inc: 3D Secure (2017), https://goo.gl/TZSTEc
36. Visa Inc: Visa Developer Centre (2018), https://goo.gl/8dDqWv
37. WickyBay: FRAUDFOX VM, WickyBay Store (2017), https://goo.gl/aAZY1K
38. Zeltser, L.: (2018), https://zeltser.com/malware-sample-sources/
Рис. 5: Зашифрованные данные об отпечатке устройства, отправленные на Сервер аутентификации.
Рис. 6: Зашифрованные данные об отпечатке устройства, отправленные на Сервер аутентификации.
Приложение А: Данные, используемые для анализа рисков
В таблице 2 содержится исчерпывающий список атрибутов устройства для карт C1–C5, которые передаются из браузера инициатора платежа на ACS. Загрузка и выполнение файла dfp.js ACS в рамках процесса оформления заказа были схожими для всех тестовых карт. Колонка «Функции» указывает функции, реализованные в dfp.js, которые извлекают информацию из браузера (для удобства чтения, некоторые названия функций были упрощены). Подробности, извлекаемые каждой функцией, приведены в колонке «Описание функций». Колонка «Источник» указывает источник каждого атрибута (JavaScript или HTTP). Наконец, в правой колонке представлен пример выходного значения каждой функции.
На рисунках 5 и 6 показаны соответственно зашифрованные данные об отпечатке устройства и полный состав cookies.
Таблица 2: Данные, используемые для анализа рисков, которые были извлечены из файла dfp.js.