В статье разбираются популярные мифы и сценарии мошенничества с бесконтактными системами оплаты на примере настоящего POS-терминала, карт PayPass/payWave и телефонов с функцией Google Pay/Apple Pay.

Рассматриваемые темы:

Можно ли НА САМОМ ДЕЛЕ украсть деньги, прислонившись POS-терминалом к карману? — мы попытаемся полностью воспроизвести этот сценарий мошенничества от начала до конца, с использованием настоящего POS-терминала и платежных карт в реальных условиях.
В чем разница между физическими и виртуальными картами Apple Pay? — как происходит связывание физической карты и токена Apple Pay, и почему Apple Pay во много раз безопаснее обычной карты.
Используем аппаратный NFC-сниффер (ISO 14443A) — воспользуемся устройством HydraNFC для перехвата данных между POS-терминалом и картой. Рассмотрим, какие конфиденциальные данные можно извлечь из перехваченного трафика.
Разбираем протокол EMV — какими данными обменивается карта с POS-терминалом, используемый формат запросов, механизмы защиты от мошенничества и replay-атак.
Исследуем операции без карты (CNP, MO/TO) — в каких случаях на самом деле(!) можно украсть деньги с карты, имея только реквизиты, считанные бесконтактно, а в каких нельзя.

Внимание!

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

Материалы в статье представлены исключительно в ознакомительных целях. Все сцены демонстрации мошенничества инсценированы и выполнены с согласия участвующих в них лиц. Все списанные деньги с карт были возвращены их владельцам. Воровство денег с карт является уголовным преступлением и преследуется по закону.

Как это работает?

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

Этапы транзакции при оплате через POS-терминал

На иллюстрации выше изображена классическая схема оплаты через POS-терминал. Именно эта последовательность действий происходит, когда после оплаты на кассе вы ожидаете подтверждения на терминале.

Покупатель прикладывает/проводит/вставляет карту в POS-терминал;
POS-терминал по интернету передает данные в банк-эквайер;
Банк-эквайер через международную платежную систему (МПС) обращается в банк-эмитент и запрашивает, может ли конкретный держатель карты оплатить покупку;
Банк-эмитент подтверждает или отклоняет покупку, после чего печатается слип (второй чек).

Бывают исключения из этой схемы, например оффлайн транзакции, их мы рассмотрим далее. Также, если банк-эквайер и банк-эмитент являются одним и тем же банком, шаги 2 и 4 выполняются внутри одного банка.

Продавец (Merchant) — лицо или организация, предоставляющая товары или услуги

Банк-эквайер (Acquiring bank) — банк, который предоставляет продавцу услуги приема платежей через банковские карты. В этом банке, обычно, находится расчетный счет продавца, куда зачисляются списанные с карты деньги.

Банк-эмитент (Issuing bank) — банк, выпустивший карту. В нем находится счет владельца карты, у которого списываются деньги.

Международная платежная система (МПС) — международная система-посредник между банками по всему миру, позволяющая банкам производить расчеты между собой без заключения договора с каждым банком по отдельности. Все банки, подключенные к МПС, соглашаются работать по одним правилам, что значительно упрощает взаимодействие. Например, Visa, MasterCard, UnionPay, American Express, ~~МИР~~ (нет, МИР не работает заграницей).

Владелец карты (Cardholder) — человек, заключивший с банком-эмитентом договор обслуживания карты.

Чем отличается обычная карта от Apple Pay или Google Pay?

Процедура привязки банковской карты к системе Apple Pay или Google Pay из-за непонятности процесса часто порождает заблуждения даже у профессионалов в IT. Мне приходилось слышать много разных мифов об этой технологии.

Сценарий 1 — обычный POS-терминал

Мошенник, вооруженный POS-терминалом

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

Условия следующие:

У мошенника полностью рабочий обыкновенный POS-терминал, подключенный к банку-эквайеру, такой же, как в магазинах и у курьеров. Прошивка терминала не модифицирована. В нашем случае — Ingenico iWL250. Это портативный POS-терминал с GPRS модемом, который поддерживает бесконтактную оплату, работает от батарейки и полностью мобилен.
Мошенник не использует дополнительные технические средства, только POS-терминал
Списанные средства зачисляются на расчетный счет мошенника, по всем правилам банковских систем

Юридическое лицо

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

Предложения о продаже готовых компаний от мошенников (кликабельно)

Цена компании на черном рынке с расчетным счетом колеблется от 20 до 300 тысяч рублей. Мне удалось найти несколько предложений ООО с POS-терминалом от 200 тысяч рублей. Такие компании оформлены на подставных лиц, и покупатель получает весь пакет документов, вместе с «кеш-картой» — это банковская карта, привязанная к расчетному счету подставной компании. С такой картой мошенник может обналичивать деньги в банкомате.

Для простоты будем считать, что ООО + расчетный счет + эквайринг и POS-терминал обойдутся мошеннику в 100 000 рублей. На самом деле больше, но мы упростим жизнь нашему гипотетическому мошеннику, снизив себестоимость атаки. Ведь чем ниже себестоимость атаки, тем проще ее реализовать.

Идем воровать деньги

Итак, мошенник получил POS-терминал и готов отправиться в людное место, чтобы прислоняться к жертвам и воровать деньги из карманов. В нашем эксперименте все жертвы были предварительно проинструктированы о наших намерениях, и все попытки списания денег проводились с их согласия. В случаях, когда испытуемые не имели собственных бесконтактных банковских карт, им предлагалось положить в кошелек нашу карту. Предварительно у испытуемых выяснялось, где именно и как они хранят свои карты, поэтому мошенник заранее знал, где в сумке/кармане находится бесконтактная карта.

Видео: мошенник разбушевался в торговом центре

В случае успешного списания, транзакция отменялась через меню терминала, и деньги возвращались на счет испытуемых. За все время эксперимента мы попытались «украсть» деньги у 20 испытуемых в здании торгового центра и на улице. Результат испытаний описан далее.

Проблема: Лимит на транзакции без PIN-кода

Лимит на максимальную сумму операции без подтверждения ПИН-кодом может быть установлен как на самом POS-терминале (CVM Required Limit), так и на стороне банка. В России это ограничение равно 1000₽.

UPD В настройках карты, может быть установлен тип авторизации Cardholder verification methods (CVMs) в виде подписи на чеке. В таком случае, бесконтактная транзакция пройдет на любую сумму без ПИН-кода.

Наш мошенник принимает решение списывать по 999.99 рублей за раз. Если будет запрошена повторная попытка списания суммы ниже лимита в короткий временной промежуток, будет также запрошен ввод ПИН-кода и, в большинстве случаев, не получится несколько раз подряд списать по 999.99 рублей. Поэтому наиболее оптимальной стратегией будет не более одного списания с одной карты.

В России максимальная сумма списания без PIN-кода равна 1000 руб.

В действительности, множество списаний с суммой 999.99 рублей за короткий промежуток времени могут спровоцировать срабатывание антифрод-системы на стороне банка-экваера, поэтому такая стратегия не является оптимальной для мошенника. Так что, в реальной жизни ему бы пришлось выбирать более разнообразные суммы, тем самым снижая потенциальный доход.

Кстати, во многих статьях по данной теме на русском языке говорится, что можно вручную установить собственный лимит на бесконтактные операции без ПИН-кода. Мне не удалось найти такой опции в основных российских банках. Может, вы знаете о такой возможности? Речь именно о бесконтактных платежах, а не любых chip&pin-транзакциях.

Проблема: Несколько карт в кошельке

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

Конкретно мой терминал Igenico iWL250 при обнаружении в поле действия более одной карты с SAK, обозначающим поддержку протокола 14443-4, возвращает ошибку: «предъявите одну карту».

Но так поступают не все терминалы. Например, сбербанковские POS-терминалы VeriFone выбирают случайную карту из нескольких. Некоторые терминалы просто игнорируют все карты, если их более одной, не показывая сообщений об ошибке.

Попытка считать несколько карт в кошельке. POS-терминал возвращает ошибку.

Антиколлизии ISO 14443-3

Чтение одной конкретной карты из нескольких — непростая задача на физическом уровне. Для решения этой проблемы существует механизм антиколлизий. Он позволяет выбрать одну карту, если был получен ответ от нескольких карт сразу. Это самый первый этап установления связи с бесконтактной картой в протоколе ISO-14443A. На данном этапе считыватель не в состоянии выяснить, какая из представленных карт банковская. Единственный вариант — выбрать более-менее похожую на банковскую карту, на основании ответа SAK (Select Acknowledge).

Значение бит в ответе SAK

Так, например, используемая в московском общественном транспорте карта «Тройка» (стандарта Mifare) имеет значение SAK=0x08 (b00001000), в котором шестой бит равен нулю. В то время как у всех банковских карт в ответах SAK шестой бит равен 1, что означает поддержку протокола ISO 14443-4.

Поэтому все, что может сделать терминал при обнаружении нескольких карт одновременно — исключить карты, не поддерживающие ISO 14443-4, и выбрать одну из похожих на банковскую. Поддержка протокола ISO 14443-4, кстати, не гарантирует, что эта карта будет банковской, однако вероятнее всего, в кошельке обычного человека не будет карт другого типа, поддерживающих ISO 14443-4.

Блок-схема работы протокола антиколлизий

Из личного опыта: несмотря на наличие протокола антиколлизий, при наличии в кошельке хотя бы трех бесконтактных карт, считать успешно нужную карту КРАЙНЕ тяжело. Большинство попыток заканчивается ошибками чтения. Тем более сложно это сделать на бегу, прижимаясь к чужим карманам и сумкам.

Однако мы будем считать, что нашему мошеннику очень везёт, и это ограничение его не беспокоит.

Оффлайн vs Онлайн транзакции

В устрашающих сюжетах новостей рассказывают о мошенниках с POS-терминалами в вагонах метро, которые прямо в пути списывают у вас из карманов деньги. В этих сюжетах не упоминается, откуда у мошенника мобильный интернет в вагоне метро. Возможно, его терминал поддерживает оффлайн-транзакции?

Спецификации EMV допускают оффлайн-транзакции. В таком режиме списание происходит без онлайн-подтверждения со стороны банка-эмитента. Это работает, например, в общественном транспорте в Москве и Санкт-Петербурге. Чтобы не занимать очередь на входе в автобус, пока терминал выполнит онлайн-подтверждение, вас пропускают сразу, не проверяя, достаточно ли у вас денег на счету для оплаты проезда. В конце дня, когда на терминале появляется интернет, подписанные транзакции отправляются в банк-эмитент. Если окажется, что в этот момент у вас нет денег на оплату проезда, карта будет добавлена в стоп-лист на всех терминалах в городе. Долг можно погасить через личный кабинет по номеру карты. Подробнее об оплате проезда в автобуса Санкт-Петербурга.

Лично мне не удалось получить POS-терминал, поддерживающий такую функцию, поэтому в сценарии с обычным «гражданским» POS-терминалом мы не будем рассматривать возможность оффлайн-списаний. Это ничего не меняет, кроме того, что атакующему потребуется наличие интернета на терминале, поэтому атака, например, в метро, значительно усложняется.
Существуют модели терминалов, поддерживающие WiFi, и в теории наш мошенник мог бы использовать WiFi в метро, предварительно позаботившись о покупке доступа без рекламы для MAC-адреса своего POS-терминала, чтобы не нужно было выполнять аутентификацию через captive portal, так как на POS-терминале это сделать нельзя.

Подсчитываем прибыль

В нашем сценарии себестоимость атаки была 100 000 рублей. Это значит, что для того, чтобы хотя бы вернуть вложения, нашему герою нужно выполнить минимум 100 транзакций по 1 тысяче рублей. Представим, что он был достаточно проворным и весь день бегал по городу, прижимаясь ко всем подряд, так, что к концу для сделал 120 успешных списаний. Мы не будем учитывать комиссию эквайринга (в среднем 2%), комиссию на обналичивание (4-10%) и другие комиссии.

Может ли он успешно обналичить деньги, используя карту, привязанную к расчетному счету?

В реальности не все так просто. Зачисление денег на счет мошенника произойдет только через несколько дней! За это время, наш мошенник должен надеяться, что никто из ста двадцати жертв не оспорит транзакцию, что крайне маловероятно. Поэтому в реальности, счет мошенника будет заблокирован еще до зачисления на него денег.

Если человек заметил, что по его карте была проведена покупка, которую он не совершал, ему следует обратиться к банку-эмитенту и подать претензию. На рассмотрение спорных операций на территории России уходит до 30 дней, а по операциям, совершенным за рубежом — до 60 дней. За это время банк-эмитент направляет запрос банку-эквайеру, и если банк-эквайер подтверждает факт совершения сомнительных операций, то блокируется терминал и средства на расчетном счете владельца терминала.

Александр Падерин, управляющий директор центра информационной безопасности Уральского банка реконструкции и развития (УБРиР)

Вывод

Себестоимость атаки в нашем сценарии — 100 000р. В действительности, она будет в несколько раз выше, поэтому мошеннику потребуется намного больше усилий для того, чтобы получить прибыль.

В нашем сценарии мошенник всегда списывает по 999.99 рублей, что, вероятнее всего, повлечет за собой срабатывание системы антифрода на стороне банка-эквайера. В реальности мошеннику потребуется списывать меньшие суммы.

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

Из 20 испытуемых только у трех удалось списать деньги с карты, что составляет 15% успеха от всех попыток. Это были те искусственные случаи, когда в кармане находилась одна единственная карта. В случаях же с кошельком и несколькими картами, терминал возвращал ошибку. В сценарии с терминалом, который использует модифицированную прошивку и реализует механизм антиколлизий, процент успешных списаний, возможно, будет выше. Однако, даже в случае использования антиколлизий, в реальных условиях на бегу, считать одну карту из нескольких настолько сложно, что успешное списание в таких условиях можно считать везением. В реальности, доля успешных списаний будет едва ли выше 10% от числа попыток.

Итак, несмотря на то, что в теории такая атака возможна, на практике она оказывается невыгодна и крайне тяжело осуществима. Шанс получить хоть какую-либо прибыль настолько мал, что лишает смысла всю затею.

Сценарий 2 — злой POS-терминал

Допустим, наш мошенник работает на кассе в магазине или курьером с мобильным POS-терминалом. В таком случае, у него появляется возможность вылавливать данные карты, которых, в некотором случае, может быть достаточно для оплаты в интернете.

Для начала разберемся, как именно выглядит бесконтактная транзакция, и какими данными обменивается карта с POS-терминалом. Так как нам лень читать тысячи страниц документации EMV Contactless Specifications , мы просто перехватим обмен на физическом уровне с помощью сниффера HydraNFC.

Есть некоторая разница между EMV-спецификацией для MasterCard PayPass и Visa payWave. Это разница в формате подписи и некоторых данных. Но для нас это несущественно.

NFC-сниффер

HydraNFC — полностью опенсорсный автономный сниффер ISO-14443A, который сохраняет перехваченные APDU-команды на SD-карту. Антенна сниффера размещается между терминалом и картой, и пассивно захватывает всю передаваемую информацию.

→ Сайт о HydraBus и шилде HydraNFC
→ Исходники прошивки

Демонстрация перехвата обмена между POS-терминалом и телефоном с Apple Pay

Забегая вперед, нужно сказать, что на этом уровне оплата телефоном и обычной пластиковой картой не отличается. Для POS-терминала это обычная карта VISA. Однако, оплата телефоном намного безопаснее, чем физической картой, и дальше мы разберем, почему.

Разбор протокола EMV

Вот как выглядит записанный дамп при оплате шоколадки и бутылки воды общей стоимостью 142.98 рублей с помощью Apple Pay:

Сырые данные, полученные со сниффера (раскрыть спойлер)

Кассовый чек и слип от транзакции (кликабельно)

R (READER) — POS-терминал
T (TAG) — карта (в нашем случае телефон)

R>> 52 

R>> 52 

R>> 52 

R>> 52 

R>> 52 

R>> 52 

R>> 52 

T<< 04 00

R>> 93 20 

T<< 08 fe e4 ec fe 

R>> 93 70 08 fe e4 ec fe dd 6e 

T<< 20 fc 70 

R>> 50 00 57 cd 

R>> 26 

R>> 52 

T<< 04 00 

R>> 93 70 08 fe e4 ec fe dd 6e 

T<< 20 fc 70 

R>> e0 80 31 73 

T<< 05 78 80 70 02 a5 46 

R>> 02 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 00 e0 42 

T<< 02 6f 23 84 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 a5 11 bf 0c 0e 61 0c 4f 07 a0 00 00 00 03 10 10 87 01 01 90 00 4b b3 

R>> 03 00 a4 04 00 07 a0 00 00 00 03 10 10 00 bc 41 

T<< 03 6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00 1d 66 

R>> 02 80 a8 00 00 23 83 21 36 a0 40 00 00 00 00 01 42 98 00 00 00 00 00 00 06 43 00 00 00 00 00 06 43 18 09 18 00 e0 11 01 03 00 f9 14 

T<< 02 77 62 82 02 00 40 94 04 18 01 01 00 9f 36 02 02 06 9f 26 08 d6 f5 6b 8a be d7 8f 23 9f 10 20 1f 4a ff 32 a0 00 00 00 00 10 03 02 73 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9f 6c 02 00 80 57 13 48 00 99 72 50 51 17 56 d2 31 22 01 00 00 05 20 99 99 5f 9f 6e 04 23 88 00 00 9f 27 01 80 90 00 af c8 

R>> 03 00 b2 01 1c 00 c9 05 

T<< 03 70 37 5f 28 02 06 43 9f 07 02 c0 00 9f 19 06 04 00 10 03 02 73 5f 34 01 00 9f 24 1d 56 30 30 31 30 30 31 34 36 31 38 30 34 30 31 37 37 31 30 31 33 39 36 31 36 37 36 32 35 90 00 a7 7b

Разберем каждую строку строку из перехваченного дампа в отдельности.

R>> — данные, переданные POS-терминалом
T>> — данные, переданные картой (в нашем случае телефон с Apple Pay)

14443-A Select

В начале обмена терминал устанавливает соединение с картой на канальном уровне. Для тех, кто знаком с сетями и моделью OSI, будет удобно представить это в качестве уровня L2, а UID (Unique Identifier) карты как MAC-адрес узла.

В терминологии стандарта ISO-14443:
PCD (proximity coupling device) — название считывателя, в нашем случае это POS-терминал
PICC (proximity integrated circuit card) — карта, в нашем случае эту роль выполняет телефон

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

R>> 52 // WUPA (wake up)
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
T<< 04 00 // ATQA (Answer To Request type A) 
R>> 93 20 // Select cascade 1 (Anti Collision CL1 SEL)
T<< 08 fe e4 ec fe // UID (4 bytes) + BCC (Bit Count Check)
R>> 93 70 08 fe e4 ec fe dd 6e // SEL (select tag 0x9370) + UID + CRC16
T<< 20 fc 70  // SAK (Select Acknowledge 0x20) + CRC16 
R>> 50 00 57 cd // HALT (Disable communocaion 0x5000) + CRC16
R>> 26 // REQA
R>> 52 // WUPA
T<< 04 00 // ATQA
R>> 93 70 08 fe e4 ec fe dd 6e // SELECT
T<< 20 fc 70 // SAK
R>> e0 80 31 73 // RATS (Request Answer to Select 0xE080) + CRC16
T<< 05 78 80 70 02 a5 46 // ATS (Answer to select response)

Терминал постоянно передает команду 0x52 Wake-up (WUPA), и как только в поле действия появляется карта, она отвечает командой Answer To Request type A (ATQA), в нашем случае это 0x04 0x00. Ответ ATQA может различаться в зависимости от производителей чипа.

Получив ответ ATQA, терминал начинает процедуру выявления коллизий, чтобы определить, есть ли в поле действия более одной карты. Команда 0x93 0x20 Select cascade level 1 (SEL CL1) запрашивает у всех карт в поле действия сообщить первую часть своих идентификаторов UID.

Карта отвечает 0x08 0xFE 0xE4 0xEC 0xFE, первые четыре байта — UID виртуальной карты Apple Pay и контрольная сумма 0xFE Bit Count Check (BCC) в конце.

Получив идентификаторы карт, считыватель обращается к конкретной карте командой 0x93 0x70 (SELECT). За командой следует UID карты 0x08 0xfe 0xe4 0xec + 0xfe BCC + 0xdd 0x6e CRC16.

Карта отвечает 0x20 Select Acknowledge (SAK) + 0xfc 0x70 CRC16.

Если на этом шаге получено несколько ответов SAK, ридер может уменьшить длину UID в команде SELECT, пока не ответит единственная карта. Однако, как показано выше, некоторые POS-терминалы отказываются продолжать, если на этом этапе выявлены коллизии, то есть присутствие нескольких карт одновременно.

Длина UID может быть 4, 7 или 10 байт. У всех банковских карт, что я встречал, в том числе и в Apple Pay, UID был равен 4 байтам. Интересно, что Apple Pay генерирует разный UID на каждое считывание, в отличие от физических карт, где UID обычно постоянный. Уверен, что это сделано для того, чтобы айфоны не использовали в качестве примитивных карт доступа, так как системы СКУД на основе UID до сих пор очень популярны.

Ридер посылает команду 0x50 0x00 HALT + 0x57 0xcd CRC16. Это команда завершения связи.

Дальше процедура повторяется заново, ридер снова пробуждает карту (WUPA), но уже без проверки коллизий, сразу выполняется SELECT. Зачем так сделано — не знаю, возможно, это какой-то более надежный способ определения коллизий.

Во второй раз ридер уже посылает команду 0xE0 0x80 Request Answer to Select (RATS) + 0x31 0x73 CRC16.

Карта отвечает 0x05 0x78 0x80 0x70 0x02 Answer to select response (ATS) + 0xA5 0x46 CRC16.

Answer to select — ответ аналогичный Answer To Reset (ATR) для контактных карт. В нем содержится информация о максимальном размере кадра и параметрах канального уровня.

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

Запрос доступных приложений — SELECT PPSE

Официальное описание: EMV Contactless Specifications — PPSE and Application Management for Secure Element

Начало общения с EMV-картой всегда происходит с чтения PPSE (Payment System Environment). Терминал спрашивает у карты, какие платежные приложения на ней есть.

Чаще всего это одно приложение, как в нашем примере — VISA. Однако бывают карты с несколькими платежными приложениями, например, есть специальные отечественные карты МИР с двумя платежными приложениями внутри. Так как платежная система МИР не работает заграницей, в карту интегрируется второе платежное приложение, по сути вторая карта. Это может быть приложение платежной системы JCB или UnionPay. Такие карты называются кобейджинговыми.

APDU-команда SELECT PPSE

'00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00'
  00 A4 04 00 // команда select 
   0E // длина command data (14 байт)
    32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 // command data 2PAY.SYS.DDF01
    00 // завершающий маркер

Ответ на SELECT PPSE

'6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 03 10 10 87 01 01 90 00'

Для удобства проанализируем ответ с помощью онлайн-парсера формата TVL iso8583.info/lib/EMV/TLVs. Тот же ответ, обработанный парсером:

EMV SELECT PPSE VISA RESPONE parsed

Из всего этого нас интересует только идентификатор платежного приложения (AID). В данном случае, это значение A0000000031010, означающее Visa International.

AID помечается маркером 4F. Вторым битом после маркера следует длина данных, в нем содержащихся. Несмотря на то, что длина AID может варьироваться от 5 до 16 байт, в большинстве случаев она равна 7 байтам.

Большой список AID: eftlab.co.uk/knowledge-base/211-emv-aid-rid-pix

Некоторые популярные AID

A0000000031010 Visa International
A0000000032020 Visa International
A0000000041010 Mastercard International
A0000000043060 Mastercard International United States Maestro (Debit)

Application Priority Indicator — указывает приоритет платежных приложений. Например, в кобейджинговых картах МИР, имеющих внутри несколько платежных приложений, это поле указывает, какое из двух приложений приоритетнее. Так как у нас только одно приложение Visa International, оно указывает на него, и приоритет отсутствует.

Запуск платежного приложения — SELECT AID

'00 A4 04 00 07 A0 00 00 00 03 10 10'
  00 A4 04 00 // команда select 
   07 // длина command data (7 байт)
    A0 00 00 00 03 10 10 // AID Visa International

Выбрав нужное платежное приложение, терминал запускает его.

PDOL (Processing Options Data Object List)

'6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00'

Разберем ответ парсером

В ответ на запуск платежного приложения карта сообщает набор параметров, которые ожидает получить от терминала — PDOL (Processing Options Data Object List). Терминал обязан ответить в строгом соответствии с этой последовательностью.

PDOL у разных карт может различаться. Общее число параметров PDOL — несколько десятков. Полный список параметров PDOL можно посмотреть здесь.

Разберем PDOL внимательнее. Длина, указанная после маркера — строго ожидаемая длина ответа от терминала на данный запрос. Пустой ответ заполняется нулями до нужной длины.

Разбор запроса PDOL:

9F 38 18 // Маркер начала PDOL. Длина 18 (24 байта) 
 9F 66 (длина 04) // Terminal Transaction Qualifiers (TTQ). Набор поддерживаемых терминалом протоколов. 
  9F 02 (длина 06) // Сумма списания
   9F 03 (длина 06) // вторая сумма
   9F 1A (длина 02) // Код страны в формате ISO3166-1
   95 (длина 05) // Terminal Verification Results
    5F 2A (длина 02) // Код валюты, в которой работает терминал, в формате ISO4217
     9A (длина 03) // Дата в формате YYMMDD
      9C (длина 01) // Тип транзакции 
       9F 37 (длина 04) // Случайное число

До этого момента все передаваемые данные идентичны для любых транзакций по этой карте.

Запрос на списание — GET PROCESSING OPTIONS

'80A8000023832136A0400000000001429800000000000006430000000000064318091800E011010300'
 80 A8 00 00 // Команда GET PROCESSING OPTIONS (GPO)
  23 // длина всего запроса (35 байт)
   83 // маркер PDOL-ответ
    21 // длина PDOL-ответа (33 байта)
     36 A0 40 00 // Terminal Transaction Qualifiers (TTQ)
      00 00 00 01 42 98 // Сумма списания (142,98 рублей)
       00 00 00 00 00 00 // Вторая сумма 
        06 43 // Код страны экваера (643 - россия)
         00 00 00 00 00 // Terminal Verification Results (TVR)
          06 43 // Валюта (643 - russian ruble) 
           18 09 18 // дата (18 сентября 2018 года)
            00 // тип транзакции
             E0 11 01 03 // Случайное число

В этом ответе наглядно видно, как терминал, который находится в России, запрашивает списание с карты на сумму 142,98 рублей. Обращаем внимание на случайное число в конце (E0110103). Это параметр 9F37 Unpredictable Number. Это первое упоминание криптографии. В дальнейшем это число вместе с данными транзакции карта должна будет подписать криптографической подписью. Это дает терминалу контроль над актуальностью подписи от карты и защищает от replay атак.

Ответ карты на GET PROCESSING OPTIONS

'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'

В данном ответе содержатся специфичные для VISA поля данных, поэтому я использовал парсер c поддержкой VISA Contactless Payment Specification (VCSP).

Application Interchange Profile (AIP) — содержит информацию о параметрах платежного приложения. В нашем случае AIP равен 00 40. Рассмотрим значения данного параметра из EMV 4.3 Book 3.

В нашем случае установлен один бит во втором байте, который, если верить этой таблице, Reserved For Future Use (RFU). Что это значит, и какой смысл в это вкладывает Apple Pay, я не знаю.

В AIP содержится важная информация о поддерживаемых методах аутентификации (SDA,CDA,DDA) платежа. Почему в моем случае все эти флаги равны нулю — я не понимаю.

Application File Locator (AFL) — Содержит информацию о расположении записей (SFI range of records) в конкретном AID. На основании этого ответа терминал сформирует запрос READ RECORD.

Разберем ответ AFL подробнее:

Short File Identifier (SFI) равно 0x18. Этот параметр кодируется пятью битами вместо восьми. Соответственно значение 0x18 (b00011000) преобразовываем в b00000011, и получаем 0x3.
First record = 1
Last record = 1
Т.е. в «папке» №3 есть записи с 1 по 1, то есть одна запись.

Application Transaction Counter (ATC) — инкрементный счетчик транзакций, который увеличивается каждый раз на единицу при запросе GET PROCESSING OPTIONS. Под достижению значения 0xFFFF или 0x7FFF, платежное приложение безвозвратно заблокируется. Полагаю, что это сделано для защиты от брутфорса приватного ключа карты. В нашем случае видно, что данный айфон с Apple Pay использовался для оплаты уже 518 (0x206) раз.

Application Cryptogram (AC) — криптографическая подпись, которая вычисляется картой с использованием ее приватного ключа. Данная подпись передается вместе с остальными данными банку-эмитенту, и на ее основании проверяется подлинность транзакции. Так как приватный ключ карты невозможно (доступными средствами) извлечь из карты, это позволяет исключить возможность копирования карты.

Issuer Application Data (IAD) — Содержит проприетарные данные, специфичные для VISA. Я не осилил разбор этой структуры, помогите.

Card Transaction Qualifiers (CTQ) — специфичный для VISA cписок поддерживаемых картой спецификаций. Например, можно ли использовать эту бесконтактную карту для операций в банкомате или нет, и какие подтверждения при этом потребуются.

Track 2 Equivalent Data — Оппа! В этом поле содержится номер карты и expiration date, подробнее эта информация будет разобрана далее.

Form Facto Indicator (FFI) — специфичное для VISA поле. Описывает форм-фактор и характеристики платежного устройства. В нашем случае видно, что это мобильный телефон.

Cryptogram Information Data (CID) — Я не осилил разбор этой структуры, помогите.

Запрос READ DATA RECORD

'00 b2 01 1c 00'

Терминал посылает запрос на чтение записей, полученных из AFL:

В данном случае, начиная с байта 0x1C следует читать как два значения, где первые пять бит равны 0x18 (b000011), и составляют SFI, а последующие три бита равны 0x04 (d100), и составляют номер записи.

Ответ на READ RECORD

'70375F280206439F0702C0009F19060400100302735F3401009F241D5630303130303134363138303430313737313031333936313637363235'

Application Usage Control (AUC) — определяет, разрешено ли платить картой заграницей, и разрешенные виды операций.

9F19 — что-то непонятное, судя по всему — устаревший Dynamic Data Authentication Data Object List (DDOL)

EMV Tokenisation, Payment Account Reference (PAR) — специфичный для токенезированных (виртуальных) карт параметр. Я не осилил разбор этой структуры, помогите.

Что можно извлечь из перехваченой транзакции?

Мы разобрали один конкретный пример перехваченного трафика бесконтактной транзакции Apple Pay c привязанной картой VISA. Протокол MasterCard немного отличается, но в целом похож. Из разбора видно, что транзакция защищена криптоподписью, и протокол защищен от replay-атаки. Существует устаревший протокол бесконтактной оплаты в режиме Magnetic Stripe (MSD), который намного хуже защищен от replay-атак, но в данной статье я его разбирать не буду, потому что, насколько мне известно, он почти не поддерживается в СНГ, возможно я ошибаюсь.

Из перехваченных данных можно извлечь номер карты (PAN) и срок действия (expiration date)

Как видно, из перехваченного трафика можно извлечь полный номер карты и expiration date. Хоть CVV в этом дампе и нет, этих данных уже достаточно для оплаты в некоторых интернет-магазинах. В случае с обычной физической пластиковой картой, в перехваченных данных будет содержаться тот же PAN и срок действия, который выбит на самой карте!

Оплата в интернете без CVV (CNP, MO/TO)

В моей предыдущей статье «Используем Apple Pay и карту Тройка в качестве пропуска на работу» про СКУД на базе Apple Pay меня раскритиковали в комментариях, рассказывая, что имея только последние 10 цифр карты можно украсть деньги. В дампе выше указан не только полный номер моей карты, но также и expiration date. Этих данных вполне достаточно, чтобы платить в некоторых магазинах в интернете. Что ж, попробуем это сделать.

Форма добавления карты в Amazon не требует CVV

Будь это номер физической карты, деньги действительно можно было бы украсть, но данные токена Apple Pay можно использовать ТОЛЬКО для операций Client Present (CP), когда карта подписывает транзакцию криптографический подписью. Эти данные нельзя использовать для оплаты в интернете и других операций типа Card not present (CNP), то есть по телефону или имейлу. То-то же!

Всем желающим убедиться в этом, сообщаю, что реквизиты из перехваченного выше дампа Apple Pay на данный момент актуальны и привязаны к действующей карте, на которой есть деньги. На момент написания статьи это 5 тысяч рублей. Предлагаю попробовать их украсть :)

Почему Apple Pay безопаснее обычной карты

Apple Pay vs обычная бесконтактная карта

Apple Pay требует авторизацию (отпечаток или пароль) на каждую проведенную транзакцию. Обычная карта не позволяет управлять количеством подписанных транзакций при поднесении к POS-терминалу. В теории, «злой» терминал с модифицированной прошивкой может провести одну транзакцию, а пока клиент держит карту возле считывателя, запросить несколько подписаний, но не проводить их сразу, а провести позже, когда клиент уйдет. С Apple Pay такое невозможно, после проведения транзакции пользователь видит значок успешно выполненной операции и приложение закрывается, новый запрос потребует повторный ввод отпечатка пальца.
Не позволяет считывать данные до авторизации — когда телефон с Apple Pay попадает в поле действия считывателя (13,56 МГц), пользователю предлагается авторизоваться, и только после успешной авторизации телефон начинает обнаруживаться как бесконтактная карта. До этого момента считыватель не видит ничего. Именно поэтому данные с Apple Pay нельзя считать незаметно из кармана, в отличие от обычной карты.
Нельзя использовать перехваченные данные для оплаты в интернете — обычная карта может быть использована для операций типа Card not present (CNP), то есть для оплаты в интернете, по телефону и т.д. Данные из виртуальной карты Apple Pay нельзя использовать подобным образом.
Не раскрывает данные владельца — обычные бесконтактные карты могут передавать имя владельца (Cardholder name) и историю последних покупок. По номеру карты, в некоторых случаях, можно установить ФИО владельца. С Apple Pay ничего подобного сделать нельзя.

Вывод

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

При прочих равных, Apple Pay будет безопаснее обычной пластиковой карты. Для большей безопасности можно заблокировать CNP-операции (оплата в интернете) по основной бесконтактной карте, и завести вторую карту только для оплаты в интернете.

Выражаю благодарность:

Компании tehpos.ru за предоставленное оборудование.
Уральскому банку реконструкции и развития, и лично Александру Падерину (управляющему директору центра информационной безопасности) за консультации.
Магазину aj.ru за предоставленные айфоны для тестов.
Валерии Aquamine за иллюстрации для статьи.
Глебу JRun из Digital Security за технические консультации.
Александру AlexGre за консультации по протоколу EMV.
Хабраюзеру shape за отличный парсер EMV: iso8583.info

Kurgan-Telecom Ru | Информационные технологии

Navigation

User login

Languages

Recent blog posts

Active forum topics

Habr.com

Linux.org.ru

Как украсть деньги с бесконтактной карты и Apple Pay

Как это работает?

Чем отличается обычная карта от Apple Pay или Google Pay?

Популярные мифы об Apple Pay

Сценарий 1 — обычный POS-терминал

Юридическое лицо

Идем воровать деньги

Проблема: Лимит на транзакции без PIN-кода

Проблема: Несколько карт в кошельке

Антиколлизии ISO 14443-3

Оффлайн vs Онлайн транзакции

Подсчитываем прибыль

Вывод

Сценарий 2 — злой POS-терминал

NFC-сниффер

Разбор протокола EMV

14443-A Select

Запрос доступных приложений — SELECT PPSE

PDOL (Processing Options Data Object List)

Запрос на списание — GET PROCESSING OPTIONS

Ответ карты на GET PROCESSING OPTIONS

Запрос READ DATA RECORD

Ответ на READ RECORD

Что можно извлечь из перехваченой транзакции?

Оплата в интернете без CVV (CNP, MO/TO)

Почему Apple Pay безопаснее обычной карты

Вывод

Who's online