Man
Professional
- Messages
- 2,965
- Reaction score
- 488
- Points
- 83
В начале этого года мы обнаружили множество различных уязвимостей, которые позволяют совершать платежи на заблокированных телефонах Apple и Samsung с активированным режимом транспорта. Подробнее об этом можно прочитать в нашей белой книге: https://www.paymentvillage.org/resources
К сожалению, из-за сложности, большого количества контента и существенных различий в сценариях атак я ничего не показал о Google Pay во время презентации и различных интервью. Вместо этого я всегда ссылался на whitepaper, и сегодня мой дорогой друг Квентин Тейлор и я планируем осветить эту часть.
Фон
Фундаментальное различие между кошельками Apple/Samsung и Google заключается в том, что Google Pay позволял совершать платежи на заблокированных телефонах везде, задолго до того, как были введены транспортные режимы. В 2019 году мы показали, как уязвимости в Visa PayWave могут использоваться для совершения платежей на заблокированных телефонах Android сверх лимитов «Tap and Go» (сейчас 100 фунтов стерлингов в Великобритании). Вот почему, когда я обнаружил новые выводы в Apple и Samsung, я решил рассмотреть случай MasterCard/Google Pay в качестве последней части этого исследования.
Приложив немного усилий, я сделал функциональный клон кошелька Google Pay для ограниченного количества транзакций. Это означает, что если у хакера есть временный доступ к заблокированному телефону, он может собрать достаточно информации, чтобы позже расплачиваться в супермаркетах, используя ранее собранные данные. Это атака «клонирования транзакций» вместо «клонирования карт» — когда хакеры ограничены количеством возможных платежей, которые они могут совершить.
Для этой атаки я использовал старую технику, которую Майкл Роланд нашел в 2013 году - https://www.usenix.org/sites/default/files/conference/protected-files/roland_sec13_slides.pdf. Он использовал слабый устаревший режим PayPass M/STRIPE карт MasterCard. Позвольте мне кратко перечислить проблемы этого режима, которые он обнаружил:
1. В криптограмме нет AIP, цены, даты и других важных полей. Некоторые из этих полей представлены в запросе Generate AC, но они не влияют на код аутентификации CVC3. 2. Низкая энтропия UN. Поскольку режим M/STRIPE генерирует уникальный эквивалент Track2 для каждой транзакции, он имеет ограниченный алфавит (только цифры) и ограниченное пространство для CVC3 и UN. Самая популярная длина UN — 3 или 4 цифры. Это равно 999 или 9999 возможным значениям, которые необходимо записать для успешного клонирования всех потенциальных выходов для следующих транзакций. 3. Для защиты от низкой энтропии банки должны проверять значения ATC и предотвращать транзакции с этим счетчиком, находящимся в неправильном порядке. Вместо последовательных ATC для каждой последующей транзакции ATC внезапно подпрыгивает или опускается, указывая на потенциально скомпрометированную карту/кошелек.
С момента первоначальной презентации банки и MasterCard пытались сбалансировать потенциальные риски мошенничества и ложные срабатывания, которые неизбежно приводят к недовольству клиентов, которые не могут заплатить за свои товары. Вот почему не так много банков в настоящее время используют ATC out of order как индикатор мошенничества. Другие банки повышают порог для разрыва ATC, например, разница более чем в 50 или 100 между каждым последующим значением ATC считается признаком потенциального мошенничества, но банки не заботятся о том, что скачки ниже.
Результаты, влияющие на Google Pay
Удивительно, но MasterCard tokenisation service (MDES) не реализует свои рекомендации самостоятельно. Кроме того, Google требует включить слабый режим M/STRIPE для каждого зарегистрированного мобильного кошелька MasterCard. Каковы мои выводы относительно M/STRIPE Google Pay:
1. Низкая энтропия, как и для физических карт. 50% протестированных карт имели максимальное значение UN 999, еще половина карт – 9999.
2. Обход флага требования CVM. В обычных транзакциях M/CHIP поле CVMResults влияет на решение заблокированного телефона завершить транзакцию или отклонить ее. И хотя поле CVMResults не является частью криптограмм для большинства карт и кошельков, никакие данные не могут быть подделаны. Спасибо обязательному CDA за это еще раз! Но режим CDA M/STRIPE не работает, так как M/STRIPE был специально создан для терминалов, которые не поддерживают современную криптографию.
3. ATC не в порядке. ATC из кошелька выглядит как случайные два байта, а не последовательные вообще. Позже от одного бренда кошелька я узнал, что это называется CryptoATC, и оно было создано специально для токенизации MasterCard. MDES декодирует значения CryptoATC во время детокенизации в традиционные последовательные значения ATC.
Чтобы проверить отсутствие контроля "ATC out of order", я предположил, что каждая транзакция все еще имеет свой исходный итеративный ATC. После этого я воспроизвел предварительно записанные транзакции, где предполагаемые значения имели значительный разрыв (более 50) между каждой транзакцией.
Сценарий атаки
Теперь, как работает атака: если телефон заблокирован, вы ограничены в количестве транзакций, которые вы можете сделать, и каждая транзакция имеет ограниченную сумму. Это очень похоже на то, что сейчас происходит с бесконтактными картами в Европе из-за PSD2 и Strong Customer Authentication. Допустим, у нас есть только пять попыток, как это было в Великобритании на момент моих заявлений в Android Security Team.
(Первые пять транзакций выглядели так)
(Но после пяти транзакций телефон прекратит платежи, если его не разблокировать)
Если максимальная энтропия равна 999, терминал выдаст одно из 999 случайных чисел, и мы должны были получить ответ кошелька для этого случайного числа, которое было записано.
Для воспроизведения предварительно воспроизведенных транзакций я взял знаменитый SwipeYours APK от Дмитрия Холодова и добавил свои предварительно записанные значения CVC3 вместе с другими статическими полями:
Предположим, мы используем формулу испытания Бернулли для хакера, который сделает 20 попыток оплаты в магазине. В этом случае вероятность получения одного из пяти заранее записанных значений для представленного случайного числа составит 10%. Для 50 попыток - 22%. Этого более чем достаточно, если сервис токенизации не проверяет промежутки между каждым ATC или владелец телефона нечасто пользуется кошельком.
Ответственное раскрытие информации.
Google был проинформирован в январе 2021 года. Вскоре после этого они добавили дополнительный переключатель для отключения платежей на заблокированном телефоне. Поскольку команда безопасности Android так и не связалась с нами, единственным способом отслеживать их исправление было следить за изменениями на этой странице: https://web.archive.org/web/20211010141017/https://support.google.com/pay/answer/7644132
Однако все остальные выводы были проигнорированы. Однако на моих глазах ограничения ужесточались, и этот режим постепенно сходил на нет. Google постепенно сокращал количество разрешенных транзакций на заблокированном телефоне по всему миру (по крайней мере, в режиме M/STRIPE). Теперь максимум, который мне удалось найти, — три. В Великобритании он установлен на 0. В других регионах, например, в США, ограничения могут быть менее строгими.
Исход
Токенизация не так идеальна, как могла бы: банк-эмитент, который приходит в Google и говорит: «Мы хотим кошелек GPay для наших карт», просто не может настроить свою конфигурацию безопасности, установить различные лимиты, максимальную энтропию, отключить устаревшие режимы. И во время авторизации кошелька они по умолчанию не получают никаких дополнительных данных EMV для процесса принятия решений.
И снова CDA доказала свою практичность и эффективность против любого подделки данных. Это эффективный инструмент не только для офлайн-терминалов.
Последние обновления
В свете последних заявлений относительно «отмены поддержки режимов Mag-Stripe» как для Visa, так и для MasterCard:
https://www.emvco.com/specifications/book-c-3-kernel-3-specification/
https://support.nmi.com/hc/en-gb/articles/360032918892-US-Canada-Mandate-Magstripe-MSD-Contactless
https://news.phillips66solutions.co...transactions-at-the-dispenser-to-be-disabled/
Меня много раз спрашивали, мертв ли этот режим и невозможна ли атака Pre-Play, изобретенная Роландом и др., больше. Что ж, у меня плохие новости: она все еще работает. Хотя ни одна из четырех проверенных мной карт MasterCard не была уязвима, GPay/MasterCard поддерживает и одобряет транзакции Mag Stripe. Эти транзакции авторизуются не эмитентом, а самой MasterCard на MDES (хост токенизации). Так что это ситуация «делай то, что я говорю, а не то, что я делаю».
Следовательно, последнее заявление исследователей ETH Zurich также не является точным https://ethz.ch/content/dam/ethz/sp.../publications/pub2023/mastercard-usenix23.pdf (стр. 12) Для тех, кто хочет больше подробностей - выпустите кошелек GPay MasterCard и проверьте атаку самостоятельно. Некоторые логи недавней транзакции:
Источник
К сожалению, из-за сложности, большого количества контента и существенных различий в сценариях атак я ничего не показал о Google Pay во время презентации и различных интервью. Вместо этого я всегда ссылался на whitepaper, и сегодня мой дорогой друг Квентин Тейлор и я планируем осветить эту часть.
Фон
Фундаментальное различие между кошельками Apple/Samsung и Google заключается в том, что Google Pay позволял совершать платежи на заблокированных телефонах везде, задолго до того, как были введены транспортные режимы. В 2019 году мы показали, как уязвимости в Visa PayWave могут использоваться для совершения платежей на заблокированных телефонах Android сверх лимитов «Tap and Go» (сейчас 100 фунтов стерлингов в Великобритании). Вот почему, когда я обнаружил новые выводы в Apple и Samsung, я решил рассмотреть случай MasterCard/Google Pay в качестве последней части этого исследования.
Приложив немного усилий, я сделал функциональный клон кошелька Google Pay для ограниченного количества транзакций. Это означает, что если у хакера есть временный доступ к заблокированному телефону, он может собрать достаточно информации, чтобы позже расплачиваться в супермаркетах, используя ранее собранные данные. Это атака «клонирования транзакций» вместо «клонирования карт» — когда хакеры ограничены количеством возможных платежей, которые они могут совершить.
Для этой атаки я использовал старую технику, которую Майкл Роланд нашел в 2013 году - https://www.usenix.org/sites/default/files/conference/protected-files/roland_sec13_slides.pdf. Он использовал слабый устаревший режим PayPass M/STRIPE карт MasterCard. Позвольте мне кратко перечислить проблемы этого режима, которые он обнаружил:
1. В криптограмме нет AIP, цены, даты и других важных полей. Некоторые из этих полей представлены в запросе Generate AC, но они не влияют на код аутентификации CVC3. 2. Низкая энтропия UN. Поскольку режим M/STRIPE генерирует уникальный эквивалент Track2 для каждой транзакции, он имеет ограниченный алфавит (только цифры) и ограниченное пространство для CVC3 и UN. Самая популярная длина UN — 3 или 4 цифры. Это равно 999 или 9999 возможным значениям, которые необходимо записать для успешного клонирования всех потенциальных выходов для следующих транзакций. 3. Для защиты от низкой энтропии банки должны проверять значения ATC и предотвращать транзакции с этим счетчиком, находящимся в неправильном порядке. Вместо последовательных ATC для каждой последующей транзакции ATC внезапно подпрыгивает или опускается, указывая на потенциально скомпрометированную карту/кошелек.
С момента первоначальной презентации банки и MasterCard пытались сбалансировать потенциальные риски мошенничества и ложные срабатывания, которые неизбежно приводят к недовольству клиентов, которые не могут заплатить за свои товары. Вот почему не так много банков в настоящее время используют ATC out of order как индикатор мошенничества. Другие банки повышают порог для разрыва ATC, например, разница более чем в 50 или 100 между каждым последующим значением ATC считается признаком потенциального мошенничества, но банки не заботятся о том, что скачки ниже.
Результаты, влияющие на Google Pay
Удивительно, но MasterCard tokenisation service (MDES) не реализует свои рекомендации самостоятельно. Кроме того, Google требует включить слабый режим M/STRIPE для каждого зарегистрированного мобильного кошелька MasterCard. Каковы мои выводы относительно M/STRIPE Google Pay:
1. Низкая энтропия, как и для физических карт. 50% протестированных карт имели максимальное значение UN 999, еще половина карт – 9999.
2. Обход флага требования CVM. В обычных транзакциях M/CHIP поле CVMResults влияет на решение заблокированного телефона завершить транзакцию или отклонить ее. И хотя поле CVMResults не является частью криптограмм для большинства карт и кошельков, никакие данные не могут быть подделаны. Спасибо обязательному CDA за это еще раз! Но режим CDA M/STRIPE не работает, так как M/STRIPE был специально создан для терминалов, которые не поддерживают современную криптографию.
3. ATC не в порядке. ATC из кошелька выглядит как случайные два байта, а не последовательные вообще. Позже от одного бренда кошелька я узнал, что это называется CryptoATC, и оно было создано специально для токенизации MasterCard. MDES декодирует значения CryptoATC во время детокенизации в традиционные последовательные значения ATC.
Чтобы проверить отсутствие контроля "ATC out of order", я предположил, что каждая транзакция все еще имеет свой исходный итеративный ATC. После этого я воспроизвел предварительно записанные транзакции, где предполагаемые значения имели значительный разрыв (более 50) между каждой транзакцией.
Сценарий атаки
Теперь, как работает атака: если телефон заблокирован, вы ограничены в количестве транзакций, которые вы можете сделать, и каждая транзакция имеет ограниченную сумму. Это очень похоже на то, что сейчас происходит с бесконтактными картами в Европе из-за PSD2 и Strong Customer Authentication. Допустим, у нас есть только пять попыток, как это было в Великобритании на момент моих заявлений в Android Security Team.
(Первые пять транзакций выглядели так)
(Но после пяти транзакций телефон прекратит платежи, если его не разблокировать)
Если максимальная энтропия равна 999, терминал выдаст одно из 999 случайных чисел, и мы должны были получить ответ кошелька для этого случайного числа, которое было записано.
Для воспроизведения предварительно воспроизведенных транзакций я взял знаменитый SwipeYours APK от Дмитрия Холодова и добавил свои предварительно записанные значения CVC3 вместе с другими статическими полями:
Предположим, мы используем формулу испытания Бернулли для хакера, который сделает 20 попыток оплаты в магазине. В этом случае вероятность получения одного из пяти заранее записанных значений для представленного случайного числа составит 10%. Для 50 попыток - 22%. Этого более чем достаточно, если сервис токенизации не проверяет промежутки между каждым ATC или владелец телефона нечасто пользуется кошельком.
Ответственное раскрытие информации.
Google был проинформирован в январе 2021 года. Вскоре после этого они добавили дополнительный переключатель для отключения платежей на заблокированном телефоне. Поскольку команда безопасности Android так и не связалась с нами, единственным способом отслеживать их исправление было следить за изменениями на этой странице: https://web.archive.org/web/20211010141017/https://support.google.com/pay/answer/7644132
Однако все остальные выводы были проигнорированы. Однако на моих глазах ограничения ужесточались, и этот режим постепенно сходил на нет. Google постепенно сокращал количество разрешенных транзакций на заблокированном телефоне по всему миру (по крайней мере, в режиме M/STRIPE). Теперь максимум, который мне удалось найти, — три. В Великобритании он установлен на 0. В других регионах, например, в США, ограничения могут быть менее строгими.
Исход
Токенизация не так идеальна, как могла бы: банк-эмитент, который приходит в Google и говорит: «Мы хотим кошелек GPay для наших карт», просто не может настроить свою конфигурацию безопасности, установить различные лимиты, максимальную энтропию, отключить устаревшие режимы. И во время авторизации кошелька они по умолчанию не получают никаких дополнительных данных EMV для процесса принятия решений.
И снова CDA доказала свою практичность и эффективность против любого подделки данных. Это эффективный инструмент не только для офлайн-терминалов.
Последние обновления
В свете последних заявлений относительно «отмены поддержки режимов Mag-Stripe» как для Visa, так и для MasterCard:
https://www.emvco.com/specifications/book-c-3-kernel-3-specification/
https://support.nmi.com/hc/en-gb/articles/360032918892-US-Canada-Mandate-Magstripe-MSD-Contactless
https://news.phillips66solutions.co...transactions-at-the-dispenser-to-be-disabled/
Меня много раз спрашивали, мертв ли этот режим и невозможна ли атака Pre-Play, изобретенная Роландом и др., больше. Что ж, у меня плохие новости: она все еще работает. Хотя ни одна из четырех проверенных мной карт MasterCard не была уязвима, GPay/MasterCard поддерживает и одобряет транзакции Mag Stripe. Эти транзакции авторизуются не эмитентом, а самой MasterCard на MDES (хост токенизации). Так что это ситуация «делай то, что я говорю, а не то, что я делаю».
Следовательно, последнее заявление исследователей ETH Zurich также не является точным https://ethz.ch/content/dam/ethz/sp.../publications/pub2023/mastercard-usenix23.pdf (стр. 12) Для тех, кто хочет больше подробностей - выпустите кошелек GPay MasterCard и проверьте атаку самостоятельно. Некоторые логи недавней транзакции:
Code:
>> 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 00
<< 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 04 10 10 87 01 01 90 00
>> 00 a4 04 00 07 a0 00 00 00 04 10 10 00
<< 6f 44 84 07 a0 00 00 00 04 10 10 a5 39 50 10 44 45 42 49 54 20 4d 41 53 54 45 52 43 41 52 44 87 01 01 5f 2d 02 65 6e 9f 38 0f 9f 1d 08 9f 1a 02 9f 35 01 9f 7e 01 9f 4e 20 bf 0c 0a 9f 6e 07 08 26 00 00 32 31 00 90 00
>> 80 a8 00 00 2e 83 2c 2c b8 00 00 00 00 00 00 08 26 22 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<< 77 0e 82 02 1b 80 94 08 08 01 01 00 10 01 05 01 90 00 // replaced to 770A820200009404080101009000
>> 00 b2 01 0c 00
<<70 81 89 9f 6c 02 00 01 9f 62 06 00 00 00 00 00 f0 9f 63 06 00 00 00 00 0f 0e 56 29 42 35 31 36 37 36 34 39 37 36 33 32 36 33 31 35 31 5e 20 2f 5e 32 36 30 37 32 30 31 30 30 30 30 30 30 30 30 30 30 30 30 30 9f 64 01 04 9f 65 02 00 f0 9f 66 02 0f 0e 9f 6b 13 51 67 64 97 63 26 31 51 d2 60 72 01 00 00 00 00 00 00 0f 9f 67 01 04 9f 69 1c 9f 6a 04 9f 7e 01 9f 02 06 5f 2a 02 9f 1a 02 9c 01 9a 03 9f 15 02 9f 35 01 9f 33 03 90 00
>> 80 2a 8e 80 19 00 00 06 78 01 00 00 00 00 01 00 08 26 08 26 00 23 06 02 00 01 22 00 00 08 00
<< 77 15 9f 61 02 09 1b 9f 60 02 09 1b 9f 36 02 00 63 df 4b 03 00 10 00 90 00Источник
Last edited:
