Близкие контакты. Взлом Google Pay, Samsung Pay и Apple Pay

Содержание статьи

Предыстория
Токенизация
Атакуем Samsung Pay
Атакуем Apple Pay
Атакуем Google Pay
Итоги

Электронные кошельки Google Pay, Samsung Pay и Apple Pay считаются наиболее современными платежными инструментами. Однако они тоже подвержены уязвимостям, поскольку все еще зависят от технологий, созданных тридцать лет назад. В сегодняшней статье я расскажу о методах взлома популярных электронных кошельков, а также раскрою детали новой атаки на кошельки и карты EMV/NFC — Cryptogram Confusion.

Читай также

О принципах, на которых строится безопасность банковских платежных систем, ты можешь узнать из моих предыдущих статей:

Близкие контакты. Атакуем бесконтактные карты
Близкие контакты. Как работают атаки на чиповые карты
Близкие контакты. Как хакеры крадут деньги с банковских карт
Близкие контакты. Разбираемся, как работают системы безопасности кредитных карт

Предыстория

Если проследить эволюцию стандарта EMV, то вначале были чиповые смарт‑карты. Затем эти карты оснастили антенной и превратили в бесконтактные карты, унаследовавшие почти все функции от EMV. Но карточным брендам этого было мало, и в 2011 году уже существовавший тогда Google Wallet оснастили функцией бесконтактной оплаты с помощью NFC.

Google использовала подход Host-Card Emulator (HCE), когда конечное устройство не содержит в себе все приватные и симметричные ключи шифрования по аналогии со смарт‑картой, а время от времени загружает одноразовые ключи (Single-Use Key, SUK) для каждой следующей операции. Придерживаясь этого подхода до сих пор, телефоны с Google Pay не позволяют совершать больше двадцати операций без подключения к интернету. В 2012 году Samsung и Apple представили свои кошельки с использованием технологии Secure Element. Работают они по аналогии со смарт‑картами, где физически и логически защищенный чип гарантирует защиту от перехвата, чтения, перезаписи секретных ключей, на основе которых создаются 3DES-криптограммы EMV и подписываются данные с помощью асимметричного RSA.

В прошлом Славомир Ясек показывал пример успешного переноса Google Pay с одного устройства на другое. При этом сохранялась возможность получать ключи SUK с серверов Google не на оригинальное устройство. Питер Филлмор (Peter Fillmor) также детально рассматривал устройство Apple Pay. Я в 2017 году демонстрировал на конференции Black Hat USA реплей атаки на онлайн‑криптограммы Apple Pay.

Два года назад я начал исследовать безопасность мобильных кошельков при оплате с помощью NFC. На тот момент Google Pay был единственным кошельком, позволяющим платить устройством с заблокированным экраном. Я очень быстро смог применить атаку, которую использовал для бесконтактных карт Visa, чтобы обойти лимиты NoCVM или Tap & Go (в России они составляют 3000 рублей). Для этого было необходимо лишь активировать экран на заблокированном телефоне. Если телефон все еще у владельца в кармане, это можно сделать, отправив команду по Bluetooth или Android Beam. Несмотря на заявления экспертов, что «форматы и протоколы работы бесконтактных карт разных международных систем принципиально не различаются», я категорически с этим не согласен, ведь применить такую же атаку против MasterCard мне не удалось.

В конце 2019 года Samsung и Apple представили поддержку «транспортных схем» в крупных мегаполисах: Нью‑Йорке, Токио, Лондоне. Во многих транспортных системах оплата зависит от дальности поездки, при этом финальная сумма платежа высчитывается исходя из точки входа в метро и точки выхода. Поэтому снимать стандартную сумму при первом «тапе» карты или кошелька некорректно. Далее, несмотря на стабильное подключение турникетов к интернету, они не запрашивают авторизацию транзакций онлайн, потому что соединение занимает долгое время. Вместо этого используется асинхронная авторизация. А чтобы противодействовать мошенничеству, применяется офлайн‑аутентификация по современному стандарту CDA, описанному еще в спецификациях EMV. Я уже рассказывал о принципе работы CDA в статье «Близкие контакты. Разбираемся, как работают системы безопасности кредитных карт».

Наконец, последняя проблема электронных кошельков — это необходимость разблокировать телефон Apple или Samsung каждый раз, когда ты подходишь к турникету метро. Крайне неудобно, не правда ли? Именно поэтому и Samsung, и Apple сделали возможность платить на транспорте без разблокировки телефона.

Токенизация

Мобильные кошельки существуют благодаря технологии токенизации: карта добавляется в мобильный кошелек, данные отсылаются международной платежной системе, которая после подтверждения всех реквизитов создает «виртуальную карту». Она может работать только по NFC, причем только на том устройстве, на котором карта была добавлена. Но это в теории.

Технология токенизации

Преимущество мобильного кошелька состоит в том, что использование токенов ограничено. В случае компрометации токена злоумышленники не могут использовать украденные данные виртуальной карты, чтобы создать клон магнитной полосы или платить такой картой в интернете. Именно поэтому банки, карточные бренды и крупные производители мобильных кошельков (Apple, Google, Samsung, Huawei и прочие) в один голос утверждают, что безопасность мобильных кошельков находится на высоте.

Начиная с момента замещения карты токеном банки‑эмитенты перестают играть существенную роль в авторизации транзакций и риск‑менеджменте. Да, они получают информацию о местоположении и типе мерчанта, сумме, дате транзакции. Однако все криптографические функции и анализ полей EMV переносятся на токенизатор (Visa VTS или MasterCard MDES). Код, который исполняется в мобильном кошельке, также написан, аудирован и сертифицирован одной из МПС. Apple или Samsung вроде и ни при чем — они выступают фасадом, но всю работу за них делают МПС. А банку‑эмитенту становится труднее судить о мошеннических операциях из‑за недостатка данных.

Поэтому операции с использованием мобильных кошельков, в отличие от банковских карт, почти никогда случайно не блокируются системами антифрода. Именно в этом и кроется одна из основных проблем: ответственные за процесс платежа скрыты внутри самого этого процесса, а сущности снаружи (банк‑эмитент, мерчант, мобильный кошелек) имеют ограниченные возможности для принятия решений.

Схема платежа при помощи электронного кошелька

Атакуем Samsung Pay

Samsung пошел по простому пути: при активации транспортной карты NFC всегда работает на телефоне, и все проверки, предназначенные для того, чтобы отличить платежный терминал в супермаркете от терминала в метро, совершаются на этапе фазы платежей EMV/NFC.

Быстро добавив карту Visa и установив ее как транспортную в телефоне, я вооружился Proxmark3 и отправился в метро, чтобы записать данные о транзакции и сравнить запросы от терминала в метрополитене с запросами от обычного платежного терминала.

Главная команда в данном случае — запрос терминала на генерацию криптограммы (Generate AC) и ответ кошелька:

-> 80a80000438341 — заголовок Generate AC 23004000 — поле Terminal Transaction Qualifier (обязательна офлайн-аутентификация CDA) 54664c20426f6e6420537472656574 (TfL Bond Street) — Merchant Name and Location 9f4bxxxxxxx — данные для офлайн-аутентификации 000000000000000000000000 0826 0000000000 0826 200331 00 4bee1439000 — сумма 0.00, валюта, дата транзакции и другие поля <- 9f2701 80 — тип криптограммы (онлайн-криптограмма, ARQC) 9f3602 000e — счетчик операций, ATC 9f1020 1f4363 00200000000000000000002172000 — поле CVR — Card Verification Results (среди прочего указывает совершенный способ верификации, тип представленной криптограммы, ARQC) 9f2608 a83f66d03cc20d45 — онлайн-криптограмма

Для платежных терминалов, авторизующих платежи онлайн, бесконтактные карты Visa не требуют офлайн‑аутентификации. Но в данном случае она обязательна. Также телефон проверяет сумму: если она не равна 0.00, то транзакция не пройдет. Но телефон не смотрит на имя мерчанта или категорию продавца (MCC — Merchant Category Code).

Если платеж происходит в обычном терминале, офлайн‑аутентификация не будет затребована и сумма будет отличной от 0.00. В этом случае телефон вернет следующий ответ:

<- 6985 (Conditions of use not satisfied)

Я решил не отчаиваться и добавил карту MasterCard, снова вернулся в метро и провел те же операции:

-> 80ae900041 — заголовок Generate AC (обязательна офлайн-аутентификация CDA) 000000000000000000000000 — сумма равна 0.00 4111 — код MCC из категории «Транспорт» 082600200000000826210307006359313725000000000000000000003f0002 — остальные поля <- 9f2701 80 — тип криптограммы (онлайн-криптограмма, ARQC) 9f3602 000f – счетчик операций, ATC 9f4bxxxxxxx — данные для офлайн-аутентификации, содержащие 9f101a 02158000002200000000000000000000000A — поле CVR (тип криптограммы — ARQC) 9f2608 02d8b8f76b5c29fc — онлайн-криптограмма

Для карт MasterCard офлайн‑аутентификация по бесконтактным картам обязательна практически в каждой стране и поддерживается каждой бесконтактной картой. Если она не будет успешна, терминал обязан прервать такую транзакцию. Поэтому телефон проверяет два поля: сумму и код MCC.

Источник: xakep.ru