Задача платежной системы — списать нужную сумму в пользу продавца со счета верное число раз. Но атакующий может перехватить платежные данные пользователя во время покупки и позже «повторить» их еще раз, списывая сумму снова, без ведома пользователя. 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 — недостатком системы, в результате которого одна транзакция может быть проведена несколько раз, что приведет к неоднократному снятию денег.

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

Cтатьи из последних выпусков журнала можно покупать отдельно только через два месяца после публикации. Чтобы читать эту статью, необходимо купить подписку.

Подпишись на журнал «Хакер» по выгодной цене!

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

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

  1. dfwmlb

    14.12.2017 at 13:04

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

  2. Themistocles

    07.01.2018 at 14:07

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

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

Check Also

Десятка быстрых. Выбираем консольный софт для повседневных нужд

И вновь на страницах нашего журнала рубрика «Кто самый большой гик на планете». В этот раз…