Главная » Хабрахабр » Как украсть деньги с бесконтактной карты и Apple Pay

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

Как украсть деньги с бесконтактной карты из кармана? Насколько безопасен PayPass и Apple Pay?

В статье разбираются популярные мифы и сценарии мошенничества с бесконтактными системами оплаты на примере настоящего 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-терминал.

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

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

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

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

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

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

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

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

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

  • Карта копируется в телефон
    Это не так, в микропроцессорной карте содержится защищенная область памяти с криптографической информацией, которая после выпуска карты не может быть извлечена. Из-за этого чипованную карту нельзя скопировать, никак, вообще. Справедливости ради нужно сказать, что подобные атаки возможны, но стоимость их превышает суммарное количество денег, которые потратят за всю жизнь большинство читателей этой статьи.
  • Телефон каждый раз подключается к интернету во время оплаты
    Google Pay/Apple Pay не подключаются к интернету во время оплаты через POS-терминал. Вся нужная информация хранится локально в телефоне.
  • На каждую оплату генерируется новый номер карты (PAN)
    Так может показаться, если читать пресс-релизы Apple о технологии Apple Pay. Но это ошибочное трактование понятия токена. На самом деле, реквизиты виртуальной карты остаются неизменными достаточно долго, вы можете это проверить по последним цифрам номера карты в слипе (банковском чеке) при оплате покупок.
  • При оплате через Apple Pay/Google Pay взымается дополнительная комиссия
    Это не так, вы заплатите ровно столько, сколько указано на ценнике, и согласно условиям вашего договора с банком-эмитентом, чью карту вы привязали.
  • Деньги могут списаться два раза
    Этот миф касается не только Google Pay/Apple Pay, но и обычных банковских карт. Полагаю, что он появился из-за систем оплаты общественного транспорта, в которых терминал списывает деньги с проездного билета каждый раз при поднесении, так что можно списать средства два или более раз, если неаккуратно поднести карту. В случае с POS-терминалами этого риска не существует, так как терминал прекращает обмен с картой, как только получил нужны данные.


                       Связывание физической карты с «токеном» в телефоне

Процедура связывания физической карты и телефона с Apple Pay не описана публично, поэтому разберем процесс на основе известных данных: Системы, подобные Apple Pay, работают на основе EMV Payment Tokenisation Specification.

  1. Поставщик (Google, Apple, Samsung) получает информацию о карте;
  2. Через МПС поставщик запрашивает, поддерживает ли данная карта (данный банк-эмитент) работу с EMV Tokenisation;
  3. На стороне МПС генерируется виртуальная карта (токен), который загружается в защищенное хранилище в телефоне. Мне неизвестно, где именно генерируется приватный ключ от виртуальной карты, передается ли он по интернету или генерируется локально на телефоне, в данном случае это не имеет значения.
  4. В телефоне появляется сгенерированная виртуальная карта-токен, операции по которой банк-эмитент интерпретирует как операции по первой физической карте. В случае блокировки физической карты, токен тоже блокируется.

Your browser does not support HTML5 video.

 Apple Pay позволяет считать реквизиты виртуальной карты. PAN номер и expire date отличаются от привязанной карты российского Альфа-Банка. По BIN виртуальной карты (480099) определяется MBNA AMERICA BANK.

Виртуальная карта-токен содержит все атрибуты обычной карты: PAN-номер, срок действия и прочее. При оплате телефоном, POS-терминал видит обычную карту VISA или MasterCard, и общается с ней точно так же, как и с физической картой. При этом номер виртуальной карты и срок действия отличаются от привязанной оригинальной карты.

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

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

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

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

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

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

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


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

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

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

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

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

Your browser does not support HTML5 video.

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

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

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

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

POS-терминал с суммой 999.99

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

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

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

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

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

Распухший от карт кошелек

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

Your browser does not support HTML5 video.

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

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

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

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

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

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

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

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

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

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

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

В таком режиме списание происходит без онлайн-подтверждения со стороны банка-эмитента. Спецификации EMV допускают оффлайн-транзакции. Чтобы не занимать очередь на входе в автобус, пока терминал выполнит онлайн-подтверждение, вас пропускают сразу, не проверяя, достаточно ли у вас денег на счету для оплаты проезда. Это работает, например, в общественном транспорте в Москве и Санкт-Петербурге. Если окажется, что в этот момент у вас нет денег на оплату проезда, карта будет добавлена в стоп-лист на всех терминалах в городе. В конце дня, когда на терминале появляется интернет, подписанные транзакции отправляются в банк-эмитент. Подробнее об оплате проезда в автобуса Санкт-Петербурга: www.avtobus.spb.ru/for-passengers/oplata-bez-kontakta/ Долг можно погасить через личный кабинет по номеру карты.

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

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

NFC-сниффер

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

Сайт о HydraBus и шилде HydraNFC: hydrabus.com
Исходники прошивки: github.com/hydrabus/hydrafw

Your browser does not support HTML5 video.

          Демонстрация перехвата обмена между 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)

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

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

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

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

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

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

Терминал спрашивает у карты, какие платежные приложения на ней есть.
Чаще всего это одно приложение, как в нашем примере — VISA. Начало общения с EMV-картой всегда происходит с чтения PPSE (Payment System Environment). Так как платежная система МИР не работает заграницей, в карту интегрируется второе платежное приложение, по сути вторая карта. Однако бывают карты с несколькими платежными приложениями, например, есть специальные отечественные карты МИР с двумя платежными приложениями внутри. Такие карты называются кобейджинговыми. Это может быть приложение платежной системы 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

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

Вторым битом после маркера следует длина данных, в нем содержащихся. 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 можно посмотреть здесь: eftlab.co.uk/index.php/site-map/knowledge-base/145-emv-nfc-tags.

Длина, указанная после маркера — строго ожидаемая длина ответа от терминала на данный запрос. Разберем 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 // Случайное число

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

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

'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'

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

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

Что это значит, и какой смысл в это вкладывает Apple Pay, я не знаю.
В AIP содержится важная информация о поддерживаемых методах аутентификации (SDA,CDA,DDA) платежа.
В нашем случае установлен один бит во втором байте, который, если верить этой таблице, Reserved For Future Use (RFU). Почему в моем случае все эти флаги равны нулю — я не понимаю.

На основании этого ответа терминал сформирует запрос READ RECORD.
Разберем ответ AFL подробнее:
Short File Identifier (SFI) равно 0x18. Application File Locator (AFL) — Содержит информацию о расположении записей (SFI range of records) в конкретном AID. Соответственно значение 0x18 (b00011000) преобразовываем в b00000011, и получаем 0x3.
First record = 1
Last record = 1
Т.е. Этот параметр кодируется пятью битами вместо восьми. в «папке» №3 есть записи с 1 по 1, то есть одна запись.

Под достижению значения 0xFFFF или 0x7FFF, платежное приложение безвозвратно заблокируется. Application Transaction Counter (ATC) — инкрементный счетчик транзакций, который увеличивается каждый раз на единицу при запросе GET PROCESSING OPTIONS. В нашем случае видно, что данный айфон с 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)

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

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

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


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

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

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

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



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

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

Вывод


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

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


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

Компании tehpos.ru за предоставленное оборудование.

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

Магазину aj.ru за предоставленные айфоны для тестов.

Валерии Aquamine за иллюстрации для статьи.

Глебу JRun из Digital Security за технические консультации,

Александру AlexGre за консультации по протоколу EMV.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Ugears: скакуны, парусники и прочие королевские развлечения

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

[Перевод] Руководство по JavaScript, часть 3: переменные, типы данных, выражения, объекты

Сегодня, в третьей части перевода руководства по JavaScript, мы поговорим о разных способах объявления переменных, о типах данных, о выражениях и об особенностях работы с объектами. → Часть 1: первая программа, особенности языка, стандарты→ Часть 2: стиль кода и структура ...