Задача платежной системы — списать нужную сумму в пользу продавца со счета верное число раз. Но атакующий может перехватить платежные данные пользователя во время покупки и позже «повторить» их еще раз, списывая сумму снова, без ведома пользователя. Apple Pay использует ряд методов противодействия таким атакам, но некоторые недостатки ее реализации потенциально оставляют лазейки для злоупотреблений и мошенничества.

WARNING

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

В 2016 году самым популярным вопросом ко мне как эксперту по безопасности банковских систем был вопрос о безопасности бесконтактных платежей. Сначала вопросы касались PayPass, payWave, затем — Apple Pay, Samsung Pay, Android Pay. Увы, готовых ответов на них у меня не было, и мне самому приходилось «спрашивать интернет». Самые популярные на тот момент статьи описывали Apple Pay как «самую защищенную технологию», в том числе и на устройствах с джейлбрейком.

Джейлбрейкнутые устройства не считаются security flaw
Джейлбрейкнутые устройства не считаются security flaw

И единственная проблема была связана с карточным мошенничеством — когда уже украденные карты использовались мошенниками в Apple Pay для совершения платежей.

При перехвате данных карт компрометация все же возможна
При перехвате данных карт компрометация все же возможна

«Как же так? Ведь сам постулат о хорошей защищенности Apple Pay даже на устройствах, подвергшихся джейлбрейку, по сути абсурден: киберпреступник всегда может перехватить номер карты в момент ее добавления на устройство (и в этом, кстати, я оказался практически прав). Это явно тема для исследования», — подумал я. Почти одновременно с этим вышло исследование Сальвадора Мендозы об атаках на токены Samsung Pay, что и подвигло меня сконцентрироваться на Apple Pay.

INFO

Кстати, между Apple Pay и Samsung Pay есть существенная разница: Samsung Pay не дает пользователям работать на взломанных (рутованных) устройствах, что несколько ограничивает возможности атакующего.

В итоге исследования в области безопасности приложений (web-, mobile- и других) привели меня и к изучению Apple Pay JS, а вот результат оказался несколько неожиданным.

 

Теория

Возможность использовать Apple Pay на веб-сайтах и в приложениях появилась в iOS 10. С точки зрения пользователя, все работает почти точно так же, как и при оплате в магазинах: при нажатии кнопки «Оплатить с Apple Pay» появляется Payment Sheet — шторка с данными о том, что и как пользователь оплачивает, куда товар доставлять (если это применимо, как в случае с интернет-магазинами), Billing address и так далее. Пользователю остается лишь подтвердить операцию с помощью отпечатка пальца (Touch ID) или PIN-кода (после нескольких неверных вводов Touch ID).

Payment Sheet хорошо известен пользователям iOS
Payment Sheet хорошо известен пользователям iOS

Далее данные шифруются/подписываются с помощью криптоключей покупателя на Secure Element телефона и криптоключей магазина (мерчанта) на серверах Apple.

INFO

Secure Element — микропроцессор, схожий с тем, что используется в пластиковых картах, отвечает за безопасное хранение и выполнение платежных операций.

Далее на сервер мерчанта или сразу на Payment Gateway посылается криптограмма (cryptogram) — зашифрованная информация о сумме, виртуальной карте Apple Pay (токен), идентификатор платежа, а также onlinePaymentCryptogram — аналог подписи с помощью 3-D Secure. Так как эти данные — аналог представления кода 3-D Secure, то и совершить платеж по ним можно только один раз. Ну и кроме того, Apple заботится о противодействии атакам повтора (Replay Attack).


Описание формата платежного токена

Описание формата платежного токена

Описание формата платежного токена
 

Практика

 

Фейковые данные и Race Condition

Внимательное изучение платежного процесса на разных сайтах и приложениях, использующих Apple Pay (полный список), выявило, что:

  • адрес доставки и платежный адрес никак не проверяются на целостность;
  • при подделке суммы с помощью атаки типа man in the middle при вызове Payment Sheet часть платежных шлюзов снимает сумму, отправляемую самим магазином (актуальную стоимость услуг), а часть — сумму, отображенную и подписанную клиентом (хранящуюся в cryptogram);
  • один платеж можно повторить несколько раз, воспользовавшись Race Condition — недостатком системы, в результате которого одна транзакция может быть проведена несколько раз, что приведет к неоднократному снятию денег.

Продолжение доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все материалы на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи один материал

Заинтересовала информация, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для материалов, опубликованных более двух месяцев назад.


2 комментария

  1. dfwmlb

    14.12.2017 at 13:04

    Интересно, спасибо! Хотелось бы побольше статей по ИБ в финансовой сфере

  2. Themistocles

    07.01.2018 at 14:07

    VPN же решит проблему?

Оставить мнение

Check Also

ОС максимальной секретности. Выбираем дистрибутив для обхода блокировок и защиты от слежки

Возможно, ты уже пользовался дистрибутивом Tails или даже запускаешь его ежедневно. Но это…