Содержание статьи
- Теория
- Практика
- Фейковые данные и Race Condition
- Бесплатные поездки
- Реальная атака
- Кто уязвим?
- Как защититься?
Задача платежной системы — списать нужную сумму в пользу продавца со счета верное число раз. Но атакующий может перехватить платежные данные пользователя во время покупки и позже «повторить» их еще раз, списывая сумму снова, без ведома пользователя. Apple Pay использует ряд методов противодействия таким атакам, но некоторые недостатки ее реализации потенциально оставляют лазейки для злоупотреблений и мошенничества.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
В 2016 году самым популярным вопросом ко мне как эксперту по безопасности банковских систем был вопрос о безопасности бесконтактных платежей. Сначала вопросы касались PayPass, payWave, затем ― Apple Pay, Samsung Pay, Android Pay. Увы, готовых ответов на них у меня не было, и мне самому приходилось «спрашивать интернет». Самые популярные на тот момент статьи описывали Apple Pay как «самую защищенную технологию», в том числе и на устройствах с джейлбрейком.

И единственная проблема была связана с карточным мошенничеством — когда уже украденные карты использовались мошенниками в 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).

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

![]() |
![]() |
| Описание формата платежного токена |
![]()
WWW
Полный референс по shape’у платежного токена от Apple
Практика
Фейковые данные и Race Condition
Внимательное изучение платежного процесса на разных сайтах и приложениях, использующих Apple Pay (полный список), выявило, что:
- адрес доставки и платежный адрес никак не проверяются на целостность;
- при подделке суммы с помощью атаки типа man in the middle при вызове Payment Sheet часть платежных шлюзов снимает сумму, отправляемую самим магазином (актуальную стоимость услуг), а часть ― сумму, отображенную и подписанную клиентом (хранящуюся в cryptogram);
- один платеж можно повторить несколько раз, воспользовавшись Race Condition — недостатком системы, в результате которого одна транзакция может быть проведена несколько раз, что приведет к неоднократному снятию денег.
Продолжение статьи доступно только подписчикам
Cтатьи из последних выпусков журнала можно покупать отдельно только через два месяца после публикации. Чтобы читать эту статью, необходимо купить подписку.
Подпишись на журнал «Хакер» по выгодной цене!
Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке
1 год5190 р. Экономия 1400 рублей! |
1 месяц600 р. 25-30 статей в месяц |
Уже подписан?

