Лекция
Привет, Вы узнаете о том , что такое 3-d secure, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое 3-d secure, 3d secure , настоятельно рекомендую прочитать все из категории Вредоносное ПО и защита информации.
3-d secure является протоколом, который используется как дополнительный уровень безопасности для онлайн-кредитных и дебетовых карт, двухфакторной аутентификации пользователя, но не гарантирует безопасности денежных средств на карте. Технология была разработана для платежной системы Visa с целью улучшения безопасности интернет-платежей в рамках услуги Verified by Visa (VbV). Услуги, основанные на данном протоколе, также были приняты платежными системами Mastercard под названием Mastercard SecureCode (MCC) и JCB International как J/Secure, AmEx как SafeKey, Мир (НСПК) как Мир Accept. American Express добавили 3-D Secure 8 ноября 2010 года как American Express Safe Key на некоторых рынках и продолжает запускать его на дополнительных рынках. Платежная система «Мир» запустила свой сервис в 2016 г.
Анализ протокола научными кругами показал, что он помогает в решении многих вопросов безопасности, которые влияют на потребителя, в том числе на площадь для фишинга и переложение ответственности в случае мошеннических платежей.
3-D Secure добавляет еще один шаг аутентификации для онлайн-платежей, позволяющий торговым точкам и банкам дополнительно убедиться, что платеж совершает именно держатель карты, чтобы защититься от мошеннических операций.
3-D Secure code не следует путать с кодом CVV2 или CVC2, который напечатан на карте с обратной стороны.
3-D Secure не является абсолютной защитой денег на карте при CNP-операциях (card not present), например, одноразовый код может быть перехвачен компьютерными вирусами. Также технологию 3-D Secure поддерживают не все банки, поэтому многие товары и услуги можно оплатить картой безо всякого кода подтверждения, что ограничивает эффективность данной технологии на переходном периоде .
Для держателя карты банка, поддерживающего 3d secure , в процессе оплаты онлайн к ранее необходимой информации добавляется дополнительный запрос на подтверждение использования карты. От держателя требуется ввести код подтверждения, предоставляемый банком для каждой операции чаще всего в sms-сообщении, отправленном на привязанный к карте номер сотового телефона. Возможны и другие варианты получения кода подтверждения платежа, такие как карты с микропроцессорами.
Ряд банков использует обычную систему постоянных паролей, то есть пользователь задает пароль один раз (при регистрации) и при совершении каждого интернет-платежа вводит именно его. Данный способ является менее надежным, нежели одноразовый код подтверждения.
Следует отметить, что EMVCo анонсировала новую версию протокола 3-D Secure 2.0. , в котором существенно меняется процедура верификации. Планируется, что код будет запрашиваться только в 5 % случаев, а прочие транзакции будут проверяться на основе встроенной системы рисков. Предполагается, что это увеличит активность клиентов в интернете, которые бросают покупки по причине сложностей с оплатой.
Держателю карты необходимо учитывать, что 3-D Secure может проводить платежи в интернете без подтверждения при помощи дополнительного шага аутентификации по СМС или логину и паролю, что порождает очень серьезные проблемы с безопасностью денежных средств на банковской карте клиента.
Если интернет-магазин не поддерживает технологию 3-D Secure (на сайте интернет-магазина не размещены логотипы Verified by Visa и Mastercard® SecureCode™), для осуществления покупки по банковской карте будет необходимо выбрать покупку и оформить платеж, введя реквизиты карты, которые запрашивает интернет-магазин. При этом Ваш платеж не будет защищен технологией.
Следовательно, это означает, что платеж в таком интернет-магазине пройдет без подтверждения по СМС или логину и паролю, а только лишь по введенным реквизитам карты, указанным на самой карте (тип, номер и срок карты, имя держателя и трехзначный CVV2, который напечатан на карте с обратной стороны).
Таким образом, клиенту банка важно понимать, что если на его карте разрешены платежи через интернет и даже если на карте включена дополнительная защита 3-D Secure, то, несмотря на это, абсолютно любой человек, кто имел возможность увидеть и запомнить реквизиты, напечатанные на самой банковской карте, может совершать платежи этой картой в интернет-магазинах, не поддерживающих 3-D Secure, и эти платежи будут проходить без подтверждения по СМС или логину и паролю. В ряде банков можно отдельно управлять лимитами транзакций, проводимых без 3-D Secure. Другим способом может быть управление общими лимитами с помощью приложений банк-клиент, в частности на телефонах.
Следует отметить, что проведение операции без дополнительного шага аутентификации (при наличии поддержки 3-D Secure) свидетельствует о том, что по такой операции возможен «Перенос ответственности» (Liability Shift), то есть банк-эмитент может оспорить операции и вернуть деньги держателю карты (при его своевременном обращении).
Основная концепция протокола — добавить к процессу финансовой авторизации онлайн-проверку подлинности. Эта проверка подлинности основана на принципе трех доменов (отсюда 3-D в названии) :
В обычных (не защищенных 3-D Secure) транзакциях ответственность за операции по украденным картам несет «мерчант» — торгово-сервисное предприятие, на сайте которого была произведена покупка товара/услуги по ворованной карте, при условии, что он не поддерживает эту технологию.
В случае использования 3-D Secure происходит так называемый «Перенос ответственности» (Liability Shift), когда ответственность переносится на банк-эмитент, выпустивший карту, или на самого клиента.
3D Secure обеспечивает новый уровень безопасности путем предоставления дополнительной информации.
Еще одним важным моментом является «перенос ответственности». Об этом говорит сайт https://intellect.icu . Это означает, что в случае мошенничества вся ответственность ложится на банк-эмитент. Этот момент является очень важным для продавца (мерчанта), т.к. до появления 3D Secure урегулированием спорных вопросов приходилось заниматься мерчанту.
Также не стоит забывать о двух важных психологических аспектах: повышении доверия к онлайн-платежам и увеличении конверсии.
Конверсия может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.
v1.0 - 2001 г -…
v2.0 - 2014 г - Устарело
v2.1 - 2017 г
v2.2 - 2018 г
В настоящее время большинство платежных сервисов используют версию 1.0.2 при проведении онлайн CNP-платежей, запрашивающих OTP-код.
Версия 1.0.2 была создана в 2001 году и в ней есть некоторые проблемы.
На данный момент актуальной версией является v2.2, и EMV планирует, что к концу 2020-го года она будет использоваться везде.
Это основная схема, необходимая для понимания всего процесса платежа с использованием механизма 3DS.
На этом рисунке мы видим все три домена, используемые в протоколе, а также последовательность сообщений между всеми участниками платежной операции.
Главное, что необходимо понять, — это то, что при использовании своей карты (виртуальной или реальной) для онлайн-оплаты, вы сталкиваетесь именно с протоколом 3DS. Поэтому сейчас мы проиллюстрируем все этапы совершения онлайн-платежа.
1 — Покупатель уже добавил все необходимые ему товары в корзину и нажал кнопку "Оплатить". В этот момент он попадает на страницу MPI-сервиса, где вводит данные своей карты.
После нажатия кнопки оплаты продавец (MPI) инициализирует старт платежного потока и, согласно протоколу, отправляет CRReq-запрос (Card Range Request). Данный запрос необходим, чтобы найти банк-эмитент вашей карты и получить CRR из домена взаимодействия. Этот запрос нас мало интересует.
После этого MPI отправляет VeReq (Verification Request). Этот запрос отправляется банку-эмитенту для проверки того, что 3DS для данной карты включен и карту можно использовать для оплаты.
VeRes (Verification Response) содержит дополнительную информацию для следующего этапа платежа.
Клиенты не могут видеть эти два типа сообщений.
2 — MPI создает PaReq (Payment Request) — запрос на оплату. Этот запрос отправляется через редирект в браузере клиента.
Итогом отправки PaReq становится отображение запроса на ввод OTP-кода.
3 — Клиент вводит OTP-код и возвращается на сайт продавца. Опять же в процессе этого через редирект от банка-эмитента к MPI передается PaRes (Payment Response), который содержит информацию о статусе проверки.
CRReq/CRRes для нас не очень важны. А вот VeReq/VeRes рассмотреть нужно.
В VeReq самым важным параметром является идентификатор сообщения, информация о продавце и PAN карты.
VeRes возвращает message id, который необходим, чтобы сопоставить запрос с этим ответом. А status enrolled показывает, что карта поддерживается.
Однако наиболее важным параметром в данном сообщении является URL-адрес. Этот параметр указывает, где находится ACS сервер эквайера и куда нужно отправить PaReq.
Браузер клиента, совершающего оплату, может произвести достаточно много редиректов по различным компонентам, участвующим в совершении платежа. Так, в России есть некоторое количество запросов, обрабатывающихся на стороне Национальной Системы Платежных Карт. Но сегодня нас интересует только традиционный этап, описанный в спецификации протокола. А именно этап передачи PaReq.
Платежный запрос, содержащий PaReq (метод POST), имеет три параметра:
1) MD — данные продавца. Он нужен MPI, чтобы сопоставить PaReq и PaRes одной транзакции;
2) PaReq — параметр этого платежного запроса. Он содержит всю важную информацию о платеже;
3) TermUrl — URL-адрес, на который клиент будет возвращен в конце процесса аутентификации 3D Secure.
Параметры TermURL и MD всегда отражаются в ответе на данный запрос. Поэтому могут встречаться имплементации ACS, уязвимые к атакам типа reflected XSS. В процессе аудита различных систем такие сервера были найдены.
Важный момент №1: ACS сервера обрабатывают все входящие PaReq!
Что входит в параметр PaReq?
Вы можете получить его значение, раскодировав PaReq. Это сделать достаточно легко, потому что PaReq — это Xml-> zlib-> base64-> urlencode. Для упрощения работы с этими запросами был написан плагин для burp.
Теперь мы видим, что из себя на самом деле представляет PaReq, а именно сообщение формата xml. Это сообщение содержит информацию о сумме платежа (purchAmount, amount и currency), некоторую информацию о продавце и MessageId (из VeReq).
При отправке правильно сформированного PaReq (в большинстве случаев вам не нужен полный набор запросов на оплату — требуется отправить лишь PaReq, содержащий параметры правильного типа и длины), мы получим PaRes — ответ на платеж, подобный следующему:
Первая мысль, которая может прийти в голову веб-исследователю, который видит XML-запрос — это попробовать выполнить XXE. И это правильный путь!
Но для начала посмотрим на то, что случится, если отправить некорректно сформированный PaReq. Мы получим ошибку! Вот несколько примеров таких ошибок:
Ошибка может помочь получить дополнительную информацию о версии ACS. Некоторые из них могут также оказаться полезными для получения данных из XXE.
Рассмотрим следующий пример:
acqBIN, merID, xid, date, purchAmount и currency отражаются в PaRes. Однако во всех реализациях ACS, которые мы нашли, удалось использовать только merID. Остальные параметры проверяются на соответствие типам данных.
Еще один интересный параметр (и наиболее полезный для атаки) — это URL. Этот параметр не отражается, но и не проверяется. Поэтому его можно использовать для эксплуатации XXE.
Вернемся к нашему примеру. В одной из реализаций ACS мы обнаружили, что можем читать короткие файлы, а также получать ответ в PaRes error через параметр merID. Таким образом, используя PaReq из примера выше, мы получали следующий ответ:
Тем не менее в большинстве случаев оставалось только использовать параметр URL для получения DNS или HTTP-запроса к нашему сервису. Другой вектор — это выполнить DOS через XXE-атаку "billion laughs" (проверялось на тестовом сервере).
В ходе нашего исследования мы обнаружили несколько распространенных URL-адресов:
/acs/pareq/___uid___
/acspage/cap?RID=14&VAA=B
/way4acs/pa?id=____id____
/PaReqVISA.jsp
/PaReqMC.jsp
/mdpayacs/pareq
/acs/auth/start.do
И распространенные имена поддоменов:
acs
3ds
3ds
secure
cap
payments
ecm
3dsauth
testacs
card
Впрочем, иногда вы можете найти и другие интересные пути.
Если вы хотите найти что-то новое, используйте proxy interceptor и записывайте процесс совершения платежей для интересующей вас платежной системы.
Как мы писали ранее, в 3DS v1.0 есть некоторые проблемы.
Основная проблема в том, что покупатель может использовать множество разных типов устройств. Планшет, мобильный телефон, умные часы, умный чайник и т.д. Но сайт ACS не всегда разработан для взаимодействия со всеми типами устройств.
Для этого в 3DS 2.0 предусмотрели 3DS SDK.
Другая проблема состоит в том, что новый тип защиты требует дополнительного взаимодействия с клиентом. И этот момент влияет на конверсию. Решением проблемы конверсии стала возможность использования механизма управления рисками, который позволяет не заставлять пользователя вводить дополнительные секретные данные, если банк обладает достаточным количеством информации, подтверждающей личность клиента.
Следующий важный момент заключается в том, что технологии аутентификации развиваются. Соответственно, 3DS могла бы использовать не только OTP. Поэтому v2 задумывалась с возможностью расширения поддержки различных механизмов аутентификации.
Интересный факт про v1.0. Люди некоторых стран не доверяли этому протоколу, потому что видели редирект и думали, что это мошенничество!
Этот психологический момент послужил причиной изменения спецификации второй версии протокола для сокрытия момента перенаправления.
Начало потока платежей аналогично предыдущей версии. Клиент должен указать данные своей карты.
Первый и самый важный момент — это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.
Если вы посмотрите на схему потока платежей, вы увидите, что она похожа на предыдущую, но во 2-й версии больше этапов. Это происходит за счет добавления дополнительных аутентификационных запросов и механизма Risck Engine, который может совершать как один дополнительный запрос (при платеже через браузер), так и множество (используется 3DS SDK).
Условно, 2-ю версию можно разделить на два блока. Красный, где пользователь непосредственно влияет на передаваемую информацию, и желтый, где система сама собирает и передает информацию о пользователе.
AReq (base64url) расскажет все о вас и об устройстве, с которого совершена покупка.
Если вы задумаетесь о том, какой информацией о вас располагают рекламные агентства, то данные AReq вас не удивят. Но если вам кажется, что это плохо, рассмотрите следующий момент: банки знают все о ваших покупках и о вас. С этой точки зрения, некоторая дополнительная информация не так уж и плоха)
Это сообщение необходимо для работы системы управления рисками и упрощения покупок.
Если этой информации оказалось недостаточно, Risk Engine сперва попытается получить дополнительную информацию, и именно в этот момент клиент может получить OTP-запрос.
CReq (base64url json) — challenge request — сообщение, отправляемое браузером пользователя, в случае если ARes вернет сообщение о необходимости провести Challenge Flow.
{
"ThreeDSServerTransID": "11111-d2d2-4067-bcb1-111690b26e",
"AcsTransID": "1111111-9478-44a6-b1f2-11111c6b340",
"MessageType": "CReq",
"MessageVersion": "2.1.0",
"SdkTransID": "111111-a66c-4907-ac3c-111111e8c0067",
"SdkCounterStoA": "001"
}
Если платежный процесс использует 3D Secure SDK, это сообщение будет зашифровано (JWE).
В CReq вы можете увидеть следующие поля:
К сожалению, нам пока не удалось провести достаточно подробное исследование 2-й версии протокола 3DS, поэтому сложно сказать, какие уязвимости встречаются чаще. Вы можете стать первым, кто опубликует исследование на данную тему.
На что смотреть в v1
На что смотреть в v2
Тем, кто подумывает обратить свой взгляд на платежные системы, я бы посоветовал остановиться еще и на сервисах, предоставляющих 3DS как SaaS. Там может оказаться еще достаточно много вещей, которые помогут вам понять, как устроен мир онлайн-платежей.
Данная статья про 3-d secure подтверждают значимость применения современных методик для изучения данных проблем. Надеюсь, что теперь ты понял что такое 3-d secure, 3d secure и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Вредоносное ПО и защита информации
Комментарии
Оставить комментарий
Информационная безопасность, Вредоносное ПО и защита информации
Термины: Информационная безопасность, Вредоносное ПО и защита информации