Читай также
О принципах, на которых строится безопасность банковских платежных систем, ты можешь узнать из моих предыдущих статей:
Предыстория
Если проследить эволюцию стандарта 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.
Если платеж делается в обычном терминале, сумма будет отличаться от 0.00 и код терминала окажется не из категории «Транспорт». В этом случае телефон вернет такой ответ:
<-
9f2701 00 — тип криптограммы (AAC, криптограмма отказа)
9f3602 000e — счетчик ATC, следующее значение от предыдущего
9f101a 02158000002200000000000000000000000A — CVR (тип криптограммы — AAC)
9f2608 02d8b8f76b5c29fc — AAC Cryptogram
Тут уже что‑то интересное. Напомню, что криптограмма — это 3DES HMAC от некоторых полей, представленных терминалом в запросе Generate
, и значений в самой карте, например ATC. Моя первая догадка: а что, если ключи и алгоритм калькуляции криптограммы AAC точно такие же, как и для ARQC? Ведь счетчик транзакций увеличивается каждый раз на 1, даже при возврате AAC-криптограммы. Если мы поменяем поле 9f27
на 0x80
, криптограмма будет принята терминалом и отправлена на токенизационный хост MasterCard для авторизации. И если этот хост не проверяет значения флагов в поле CVR, где все еще видно, что тип криптограммы другой, транзакция будет одобрена.
Звучит как план, но у меня была проблема: модификация любых полей во время общения терминала и кошелька будет замечена при офлайн‑аутентификации CDA. Тут мне на помощь пришла техника, совсем недавно найденная «швейцарскими учеными» (с). Они обнаружили, что обязательную офлайн‑аутентификацию можно обойти, притворившись картой Visa, и использовали эту технику для обхода ПИН‑кода.
Первый план атаки созрел:
- Берем устройство man in the middle для модификации данных между телефоном и терминалом.
- Проводим атаку Card Brand Mixup — карта MasterCard притворяется картой Visa (как это делать — читай в исследовании Card Brand Mixup Attack, PDF).
- На последнем шаге применяем атаку Cryptogram Confusion: когда кошелек возвращает криптограмму типа
0x00
(AAC), мы меняем значение поля9f27
на0x80
(ARQC). Я был приятно удивлен тем, что в конце концов атака Cryptogram Confusion прошла и транзакция была одобрена. Вот видеозапись этой атаки.
Можно ли как‑то совершать платежи по картам Visa и другим, например American Express, если телефон заблокирован? Не обнаружив никакого другого способа получения криптограммы, кроме запроса авторизации на сумму 0.00, я решил воспользоваться атакой Transaction Stream Manipulation. В ходе этой атаки данные подменяются не между терминалом и картой или кошельком, а между терминалом и банком‑эквайером, в запросе ISO8583 Authorisation Request. В этом случае у злоумышленника больше возможностей для манипуляции полями. Например, поле «сумма» фигурирует в этом запросе дважды: в первый раз в поле [
— там, где собраны все поля EMV, а во второй раз — в поле [
, где указывается реально списываемая сумма.
В таком случае атака на другие карты, в том числе Visa, выглядит следующим образом:
- Запрашиваем криптограмму на 0.00 так же, как ее запрашивает терминал в метро.
- Создаем запрос ISO8583, где указываем корректные поля (сумма — 0.00, криптограмма и так далее), но в поле [04] указываем ту сумму, которую хотим списать с карты.
Хотя кошелек с картой Visa передал информацию о том, что телефон не был разблокирован, эта транзакция была одобрена Visa Tokenisation Service.
Атакуем Apple Pay
Когда‑то корпорация Apple объявляла, что производимые ею телефоны научились поддерживать платежи с заблокированным экраном, на несколько месяцев раньше своих конкурентов. Однако мне долгое время не удавалось проверить их безопасность. Основная загвоздка была в том, что телефон не активировал поле NFC с помощью обычных терминалов и бесконтактных ридеров. Я упорно гуглил, как работает Apple VAS (Value Additional Services) и пытался пользоваться помощью коллег для реверса бинарей Apple Pay (их названия я позаимствовал из презентации Питера Филлмора). Когда я проводил операции в метро, Proxmark3 не записал никаких дополнительных данных, что привело меня в растерянность.
Когда я закончил тесты с Samsung Pay, я все еще не знал, что делать с Apple Pay, и был в отчаянии. Единственным терминалом, которым я мог пользоваться на тот момент, был терминал у турникета метро. Я решил: если я смогу записать криптограмму транзакции в метрополитене, но сама транзакция не пройдет, то я приду домой и попробую вставить криптограмму в Transaction Stream, как это делалось с вариантом Samsung + Visa. После нескольких попыток мне удалось повторить атаку второго типа по отношению к связке Apple + Visa.
Тогда же один умный инженер дал мне совет не использовать Proxmark3, а взять что‑то более надежное, например HydraNFC. Последовав этому совету, я быстро увидел в трафике «нечто» — 15 байт, которые отсылались до первых команд. Тогда мне было трудно поверить, что всего 15 байт разблокируют NFC в iPhone, так как я много читал в патентах про PKI, используемые Apple в VAS. Но это действительно оказалось именно так: всего 15 байт, и телефон позволял читать данные по NFC даже с разряженных устройств.
Посмотрим, как выглядит генерация криптограммы картой MasterCard, заданной как транспортная карта в Apple Pay:
->
80ae900041 — заголовок Generate AC (обязательна офлайн-аутентификация CDA)
000000000000000000000000 — сумма равна 0.00
4111 — код MCC из категории «Транспорт»
082600200000000826210307006359313725000000000000000000003f0002 — остальные поля
В отличие от Samsung, Apple вернет онлайн‑криптограмму, даже если сумма не будет равна 0.00 (сотрудники Apple заявили, что используют или собираются использовать эту функцию, так что «это не баг»).
Однако при подмене кода MCC транзакция будет отклонена из‑за CDA. После июня 2021 года MasterCard закрыла возможность Card Brand Mixup Attack, поэтому оплатить в произвольном терминале этой картой не удастся. Но я все еще мог проводить атаки с использованием Transaction Stream Manipulation.
А что же с картами Visa? Ими можно расплачиваться в любом супермаркете мира по заблокированному iPhone, для этого нужно лишь подменить несколько байтов при обмене между терминалом и телефоном. Да ты и сам об этом уже, скорее всего, читал: исследователи из университетов Бирмингема и Суррея обнаружили эту уязвимость независимо от меня примерно в это же время. Эта уязвимость до сих пор существует, несмотря на то что для ее устранения Visa нужно добавить всего лишь одно маленькое условие в своем токенизационном сервисе.
Атакуем Google Pay
Мы уже показывали в 2019 году, как можно совершать платежи на заблокированном кошельке Google Pay по картам Visa выше лимитов NoCVM: для этого нужно лишь поменять бит в поле TTQ, указывающий, что требуется верификация плательщика. Обойти ограничения по картам MasterCard в прошлый раз не удалось, поэтому я решил попробовать еще. Вместо модификации Transaction Stream я воспользовался старой атакой, описанной Майклом Роландом (Michael Roland) в 2013 году, — Pre-play and Downgrade (в предыдущей статье я по ошибке написал, что атаку разработал Питер Филлмор в 2014 году, но это не так).
Для меня оставалось загадкой, почему режим M-STRIPE до сих пор работает в кошельках Google Pay для всех карт MasterCard. Я решил исследовать его чуть поглубже — посмотреть на максимальную энтропию, защиту от скачков ATC и другие механизмы защиты.
Выяснилось следующее.
- Максимальная энтропия по картам — 1000 или 10 000. Других настроек я не встретил. Напомню, что карта или кошелек с энтропией 1000 клонируется полностью за 1000 запросов, на это уходит около минуты. Далее злоумышленнику не нужен оригинальный телефон — он может совершать покупки с использованием той информации, которая была клонирована. Количество транзакций зависит от других внедренных мер безопасности.
- Ограничения NoCVM на заблокированном телефоне обходятся также подменой 1 бита в запросе от терминала, что позволяет совершать платежи выше 3000 рублей. У некоторых терминалов, однако, есть отдельная конфигурация, указывающая максимальную сумму платежа в легаси‑режиме M-STRIPE.
- Если в обычной карте счетчик ATC идет последовательно: 0001, 0002 и так далее, то для мобильного кошелька система MasterCard внедрила так называемый CryptoATC. При перехвате команд они выглядят как случайные значения из 2 байт
A56D
,F1A1
и так далее. В процессе детокенизации МПС превращает эти значения в последовательные. Однако даже при скачках в 30–50–100 значений счетчика мои транзакции не были заблокированы.
Из‑за новых требований PSD2 в Европе Android ограничивал количество транзакций на заблокированном телефоне до пяти (сейчас это значение — три или ноль, зависит от страны). Это заставило меня задуматься: если MasterCard и Google не проверяют скачки ATC, записав только пять транзакций, какова вероятность воспроизвести одну из них успешно?
Воспользуемся формулой Бернулли, отлично нарисованной Аркадием Литвиненко специально для таких случаев.
При энтропии 1000, если совершить 50 попыток оплаты в супермаркете, вероятность получить случайное число из пяти записанных составит 14%. Для 100 попыток — 26%. А при наличии доступа к Transaction Stream каждая из этих записанных транзакций может быть монетизирована, ведь злоумышленник в состоянии создать запрос на авторизацию, где сам выставит и случайное число, и значения CVC3/ATC.
Более того, в случае доступа к Transaction Stream и при отсутствии защиты от перебора пар ATC/CVC3, если у злоумышленника есть только токен (16 цифр виртуальной карты и expiry date), ему потребуется максимум 65 535 попыток, чтобы создать и успешно авторизовать мошенническую транзакцию.
Если все, что нужно сделать мошенникам в данном случае, — быть настойчивыми, «тапая» в супермаркете 50–100 раз, каждый раз ожидая успеха, или посылать запросы на авторизацию на серверы токенизации MasterCard MDES, то успех, увы, им гарантирован.
Итоги
Я обнаружил несколько способов атаковать украденные мобильные кошельки, если на устройстве возможна оплата без разблокировки телефона. Также я нашел новую интересную атаку на протокол EMV — Cryptogram Confusion. С помощью нее можно атаковать не только мобильные кошельки, но и чиповые/бесконтактные карты.
Мне удалось совершить платеж по клонированным транзакциям кошелька Google Pay c привязанной MasterCard даже при ограничении в пять попыток.
Когда же дело дошло до общения с мобильными вендорами и МПС, итоги оказались неутешительными:
- Обо всех недостатках Google была оповещена в феврале. Они сообщили, что в курсе проблем и планируют закрыть возможность платежей на заблокированном экране. Это реализовано созданием отдельной опции в настройках NFC после февраля 2021 года. Также во всех регионах разработчики уменьшили число транзакций на заблокированном телефоне. Остальные уязвимости были проигнорированы.
- Apple, Samsung, MasterCard были оповещены весной 2021 года, и завертелось… Apple заявила, что 15 байт для активации NFC — достаточная защита для пользователей. Все мобильные вендоры подняли лапки кверху и, сказав, что не имеют права менять код кошельков, попросили разрешения поделиться находками с МПС. После того как разрешения были даны, мою страницу в LinkedIn много раз посещали уважаемые люди из всех МПС, но никто никогда со мной так и не связался.
Летом этого года MasterCard не только закрыла лазейку для Card Brand Mixup Attack от швейцарских исследователей, но и устранила лазейку для Cryptogram Confusion. Я обнаружил это случайно только в октябре, при подготовке к выступлению. Помимо этого, во многих регионах поле MCC было добавлено в криптограмму, что делает подмену MCC невозможной даже во время Transaction Stream Manipulation. Поменялся метод представления ATC/AAC на заблокированных телефонах Samsung, что и навело меня на мысли о патче. Версию патча я смог выпытать у Samsung (апдейт MPBP 1.2.2, May 27, 2021).
Visa не сильно переживает из‑за все еще существующей возможности совершать платежи на украденных и разряженных телефонах Apple и еще меньше — из‑за манипуляций транзакционным потоком. Они верят в машинное обучение, риск‑ориентированную модель и, скорее всего, заняты развитием бизнеса или другими интересными возможностями, а не безопасностью своих клиентов.
Атаки, которые возможны до сих пор:
- Транспортная карта Visa + Apple Pay — безлимитные платежи на заблокированном, разряженном или украденном устройстве. Также до сих пор возможны платежи по кошелькам Visa + Google Pay, тут с 2019 года ничего не изменилось.
- MasterCard + Google Pay — возможно клонирование транзакций, когда украденной информации будет достаточно для совершения определенного числа платежей.
- Остальные вариации карта + кошелек — атаки возможны только при манипуляции Transaction Stream.
Для того чтобы по‑настоящему защититься от злоупотребления платежами на заблокированном телефоне, самое оптимальное решение — сверять категорию мерчанта и сумму со значениями CVR:
- пользователь совершил платеж на 100 долларов, телефон был разблокирован, мерчант — супермаркет, нет проблем;
- авторизация на 0.00 или списание на большую сумму, телефон не разблокирован, мерчант — транспорт, тоже нет проблем;
- авторизация на 0.00, списание на большую сумму, телефон не разблокирован, мерчант — супермаркет, это уже подозрительно, и такие транзакции нужно отклонять.
Что делать банкам‑эмитентам? Я несколько раз слышал о том, что во время токенизированных транзакций банк может запросить дополнительную информацию от МПС для принятия решений, в частности поля EMV, которые в обычном случае не покидают токенизатор. Насколько сложно это делать и сколько это стоит (все сервисы МПС предоставляют по подписке), я не берусь комментировать.
Что делать клиентам? Давай представим такую картину: ты владелец мобильного кошелька, потерял свой телефон и не заблокировал карту по умолчанию или транспортную карту (я знаю, что в России транспортные карты не используются, но мы же фантазируем). Спустя какое‑то время злоумышленники воспользовались одной из указанных выше техник и сняли с твоего счета 1000 долларов. Что происходит дальше?
- Ты звонишь в банк, просишь заблокировать карту и начать разбирательства.
- Спустя какое‑то время банк‑эмитент сообщает, что у него нет никаких сведений о мошенническом характере совершенных транзакций. С их стороны все выглядит безобидно. Возможно, ты разгласил свой ПИН‑код?
- Попытки общаться с мобильными вендорами (Apple, Samsung, Google) ни к чему не приводят — они будут утверждать, что платежи возможны только у ограниченных категорий мерчантов и в лимитированных суммах. Возможно, ты разгласил свой ПИН‑код?
Что в таком случае остается делать клиентам? Отказаться от использования самых ненадежных продуктов.
За последний год я смог подтвердить свои догадки — разработчики мобильных кошельков уютно устроились, создав «самые безопасные формы платежей», отобрав у банков‑эмитентов возможности для принятия решений во время эмиссии кошелька и авторизации транзакций. При этом они же разводят руками в случае мошенничества или даже возможности мошенничества, перенося ответственность на МПС.
www
Презентацию и whitepaper, которые я использовал при подготовке этой статьи, можно скачать тут.