The document presents a comprehensive overview of payment security vulnerabilities, detailing the history and evolution of payment systems, including methodologies to identify and exploit weaknesses in card and NFC payments. It covers key topics such as EMV standards, cryptographic attacks, and practical recommendations for finding vulnerabilities in payment systems. Additionally, it emphasizes the importance of responsible disclosure in the context of bug bounty programs in the payment industry.

1. Offensive Payment
Security
Finding vulnerabilities in payment systems
Timur Yunusov

2. About me
• Appsec background
• Deeply into payments since 2013 (XXE OOB attack)
• ATM hacking since 2016
• POS/Cards/Mobile Wallets fraud simulation since 2017
• 0days in Apple Pay, GPay, Samsung Pay, Visa, MC
• Bug bounty in payments since 2019
• Payment Village organizer since 2020

3. About the workshop
• History of payments
• Background
• Deep dive into card payments
• Finding vulnerabilities
• Practical recommendations

4. History of payments
• 1960s – wide adoption of cards and card imprinters
• 1968 – first ATM that works with cards

5. History of payments
• 1970s – magstripe

6. History of payments
• 1990s – EMV smartcard
• 2000s – NFC payments

7. History of payments
• 2008-2009 – Bitcoin
• 2011 – QR payments
• 2015 – Mobile Wallets trial (Android Pay)

8. History of payments
• 2011 – QR payments
• 2015 – Mobile Wallets trial (Android Pay)

10. A few strange examples
• Facebook/Instagram Pay
• Amazon, eBay
• Twitter/Signal crypto donations
• Opera DiFy wallet
• A lot of crypto cards

11. Payment Systems and bug bounty
• IT Giants – eBay, Facebook, Netflix
• Fintech – N26, Revolut, Wise, Monzo, Crypto.com, exchanges
• High-street banks – RBS, Citi, Chase

12. BB programs/Responsible disclosure
• N26 bank
• AMEX
• Bank of America
• Capital One
• Coinbase
• Crypto.com
• Square
• Ingenico
• Simple bank
• Wells Fargo bank

14. Card payments
Card not Present
Magstripe
EMV/NFC

15. Housekeeping
• Don’t violate the law
• Don’t do this for money

16. Finding vulnerabilities. Part I
EMV

17. EMV – Europay MasterCard Visa
• 1959 – first smart cards
• 1986 – first banking cards - Carte Bancaire (France)
• 1993 – EMV (Europay, Mastercard, Visa) 1.0, Java applet ->CAP
• 2003 – First trial in England
• 2005 – Cambridge University

18. EMV – Europay MasterCard Visa
• EMVCo standard – 7 books, hundreds of pages
• EMV card == smartcard with a Java app tackling magstripe issues:
Transaction authorisation – mandatory but might happen later
Card authentication – not
Cardholder verification – not

19. EMV – Europay MasterCard Visa
• EMVCo standard – 7 books, hundreds of pages
• EMV card == smartcard with a Java app tackling magstripe issues:
Transaction authorisation
Card authentication
Cardholder verification

20. EMV – Europay MasterCard Visa
• Introduced in 90s
• EMVCo standard – 7 books, hundreds of pages
• EMV card == smartcard with a Java app tackling magstripe issues:
• Card authentication
• Transaction authorisation
• Cardholder verification

21. EMV – Europay MasterCard Visa
• Introduced in 90s
• EMVCo standard – 7 books, hundreds of pages
• EMV card == smartcard with a Java app tackling magstripe issues:
• Card authentication
• Transaction authorisation
• Cardholder verification

22. EMV communication standards
• APDU – protocol for smart cards
• APDU-Request: CLA, INS, P1, P2, Data
• APDU-Response: TLV (Tag Length Value)
• EFTLab EMV Tools
• https://www.eftlab.co.uk/index.php/site-map/knowledge-base/145-
emv-nfc-tags
• https://github.com/binaryfoo/emv-bertlv

23. EMV communication standards

24. https://www.youtube.com/c/PaymentVillage

25. Hands on time

26. Transaction authorisation – cryptogram
• Transaction cryptogram - 3DES MAC (digital signature)
• Amount, Date, ATC, Cardholder Verification Results, etc
• ARQC, AAC, TC – Tag 9F26
• HSM

27. Transaction authorisation – cryptogram
Terminal:
• С->T: PDOL, Tag 9F38 (Amount, Terminal Country Code, Date, UN)
• T->C: Generate AC (00000001000826220319ABCDEFGH)
• C->T: 3DES(PDOL,ATC,IAD)=ARQC AD146FE1F419C3D1
HSM:
• Takes all the transaction data 00000001000826220319ABCDEFGH
• Extracts card’s key
• 3DES(PDOL,ATC,IAD)=ARQC AD146FE1F419C3D1

28. Card authentication
• RSA PKI
• SDA, DDA, CDA
• Not mandatory if POS is connected
• Mandatory in metro, planes, etc
• Other terminals have “0 floor limit”

29. Cardholder verification
• PIN
• Offline PIN (encrypted or plaintext) – checked on the card
• Online PIN (encrypted) – checked on the HSM during the card auth
• Signature
• NoCVM
• CDCVM/ On-Device CVM

30. Cardholder Verification Methods List – Tag 8E
java -jar emv-bertlv-0.1.8-shaded.jar constructed
8E160000000000000000420504054203440341031E031F02
• [4205] Encrypted PIN online, If purchase + cash, next
• [0405] Encrypted PIN by ICC, If purchase + cash, FAIL
• [4203] Encrypted PIN online, If terminal supports CVM, next
• [4403] Encrypted PIN by ICC, If terminal supports CVM, next
• [4103] Plain PIN by ICC, If terminal supports CVM, next
• [1E03] Signature, If terminal supports CVM, FAIL
• [1F02] No CVM required, If not (unattended cash, manual cash, purchase
+ cash), FAIL

31. Cardholder Verification Methods List – Tag 8E
• [4205]
• 4xxx – Transaction will not fail if not chosen
• 42xx – Encrypted PIN online
• xx05 – If purchase + cash
• [1E02]
• 1xxx – Transaction will be canceled if the verification method fails
• 1exx – Signature
• xx02 – If not unattended cash, manual cash, purchase + cash

32. >> 00A404000E315041592E5359532E4444463031 (SELECT/READ FILE)
<<
C06F1C840E315041592E5359532E4444463031A50A8801015F2D047275656E90
00
> File Control Information (FCI) Template (6F):
|
|-Dedicated File (DF) Name (84)
| 315041592E5359532E4444463031
| 1 P A Y . S Y S . D D F 0 1
|
> FCI Proprietary Template (A5):
|
|-Short File Identifier (SFI) (88)
| 01
|
|-Language Preference (5F2D)
| 7275656E - en

33. >> 00B2010C00 (READ RECORD)
<< B2701461124F07A00000000310105004566973618701019000
> Application Elementary File (AEF) Data Template (70):
|
> Application Template (61):
|
|-Application Identifier (AID) (4F)
| A0000000031010
|
|-Application Label (50)
| 56697361 - Visa
|
|-Application Priority Indicator (87)
| 01

34. >> 00B2020C00 (READ RECORD)
<< 6A83 (Checking error: record not found)
>> 80A80000028300 (GET PROCESSING OPTIONS)
<< C0771282023D00940C0802020010010300180101019000
> Response Message Template Format 2 (77):
|
|-Application Interchange Profile (82)
| 3D00
|
|-Application File Locator (AFL) (94)
| 080202001001030018010101

35. >> 00B2011C00
<< B27081865A08469395xxxxxx07605F3401008C1x
|-Primary Account Number (PAN) (5A) | 469395xxxxxx0760
|-PAN Sequence Number (5F34) | 00
|-Card Risk Management Data Object List 1 (CDOL1) (8C)
| 9F02069F03069F1A0295055F2A029A039C019F3704
|-Card Risk Management Data Object List 2 (CDOL2) (8D)
| 8A029F02069F03069F1A0295055F2A029A039C019F3704
|-Cardholder Verification Method (CVM) List (8E)
| 000000000000000002054203440341031E031F02
|-Issuer Action Code - Default (9F0D) | BC68B49800
|-Issuer Action Code - Denial (9F0E) | 0010080000
|-Issuer Action Code - Online (9F0F) | BC68B49800
|-Application Expiration Date (5F24) | 220930

36. >> 80AE80001D000000000100000000000000082604000080000826200603004DD9B23E (GENERATE AC)
<< C0771E9F2701809F360200189F2608E0C05563587FF4609F100706010A03A6A0009000
> Response Message Template Format 2 (77):
|
|-Cryptogram Information Data (9F27)
| 80
|
|-Application Transaction Counter (ATC) (9F36)
| 0018
|
|-Application Cryptogram (9F26)
| E0C05563587FF460
|
|-Issuer Application Data (9F10)
| 06010A03A6A000

37. PIN OK Attack
2005
2010
2011

38. Attacks
2011

40. Cardholder Verification Methods List
• PIN by ICC – first rule
• PIN by ICC – chosen by the POS
• Tampering the first rule during MiTM

41. Read CVM List
00B2011C00
Get PIN try counter
80CA9F1700
Verify PIN 1234
20008008241234FFFFFFFF
Wrong PIN, 2 attempts left
6c32
**8E16**4103**
9F17 01 03
PIN OK
9000
Generate AC

42. https://www.cl.cam.ac.uk/~osc22/docs/mphil_acs_osc22.pdf

43. PIN OK Attack
1. Ensure that the offline PIN is chosen (change the first rule in CVM List)
2. Change Wrong PIN (0x6c32) to PIN OK (0x9000)
3. CVR (Card Verification Results) is meant to protect against the attack
9F10 (issuer application data)
Derivation key index 00
Cryptogram version number 12
Card verification results
Byte 2 Bit 8 = 0, Byte 2 Bit 7 = 0 AAC Returned in Second GENERATE AC
Byte 2 Bit 6 = 1, Byte 2 Bit 5 = 0 ARQC Returned in GPO/first GENERATE AC
Byte 2 Bit 1 = 1 Offline PIN Verification Successful

44. Questions/ Hands on

45. Cryptogram replay attack
2015 https://murdoch.is/papers/ieeesp15beprepared.pdf

46. Generate AC

47. Application Cryptogram, ARQC
Generate AC Request T->C:
80 ae 80 00 41 000000000100 0826 211106 ecb451692
C->T:
772f 9f270180 9f36020001 9f2608aec095fb09512dbb
CLA INS P1 P2 Len Amount Currency Date UN
Response Tag Type - ARQC Cryptogram
ATC

48. Application Cryptogram, ARQC
Generate AC Request T->C:
80 ae 80 00 41 000000000100 0826 211106 ecb451692
C->T:
772f 9f270180 9f36020001 9f2608aec095fb09512dbb
CLA INS P1 P2 Len Amount Currency Date UN
Response Tag Type - ARQC Cryptogram
ATC

49. Cryptogram pre-play
UN ATC Amount ARQC
00AA00A1 0001 £1 aec095fb09512dbb
00AA00A2 0002 £1 152449f1c0831322
00AA00A3 0003 £1 2ba48c52c594d13d
00AA00A4 0004 £1 5fb0951231ddbb9f

50. Cryptogram pre-play
UN ATC Amount ARQC
AAAAAAAA 0001 £1 aec095fb09512dbb
AAAAAAAA 0002 £1 152449f1c0831322
AAAAAAAA 0003 £1 2ba48c52c594d13d
AAAAAAAA 0004 £1 5fb0951231ddbb9f

51. ATC Monitoring
Seq No ATC Decision
1 0100 Normal
2 0101 Normal
3 0105 Unusual, but reasonable
4 0FF1 Unusual, unreasonable
5 0010 Unusual, unreasonable

52. Cryptogram replay
UN ATC Amount ARQC
AAAAAAAA 0001 £1 aec095fb09512dbb
AAAAAAAA 0001 £1 aec095fb09512dbb
AAAAAAAA 0001 £1 aec095fb09512dbb
AAAAAAAA 0001 £1 aec095fb09512dbb

53. Equipment for tests
• Modified POS
• Malfunctioning POS
• Access to the transaction stream

54. Transaction stream fraud
demo

55. Questions/ Hands on

56. Cryptogram confusion attack
• Found in Samsung Pay in 2021 accidentally
• Later confirmed for many Visa cards

57. Cryptogram confusion attack
Get PIN try counter
80CA9F1700
Verify PIN 1234
20008008241234FFFFFFFF
Wrong PIN, 2 attempts left
6c32
9F17 01 03
Wrong PIN, 0 attempts left
6c30
Generate AC
Verify PIN 1234
20008008241234FFFFFFFF
?

58. PIN Try limit exceeded behaviour
• Disable NFC/EMV interface – optional
• Set bytes in CVR/IAD (Tag 9F10)
[Byte 3 Bit 7 = 1] Pin try limit exceeded
• Starts providing AAC cryptogram
• [Byte 1 Bit 6 = 0, Byte 1 Bit 5 = 0] AAC Returned in First Generate AC
• ARQC – Online authorisation
• TC – Offline validation
• AAC – Declined cryptogram for further analysis

59. AAC cryptogram algorithm

60. AAC cryptogram algorithm
>>
80AE80001D00000000010000000000000008260400008000082622031900
ABCDEFGH (GENERATE AC)
• <<
C0771E9F2701809F360200189F2608AD146FE1F419C3D19f100706000a
03804000
• С->T: PDOL, Tag 9F38 (Amount, Terminal Country Code, Date, UN)
• T->C: Generate AC (00000001000826220319ABCDEFGH)
• C->T: 3DES(PDOL,ATC,IAD)=AAC AD146FE1F419C3D1

61. AAC cryptogram algorithm
[9F10 (issuer application data)] 06000A03804000
[Derivation key index] 00
[Cryptogram version number] 0A
[Card verification results] 03804000
[Byte 2 Bit 8 = 1, Byte 2 Bit 7 = 0] Second GENERATE AC not requested
[Byte 2 Bit 6 = 0, Byte 2 Bit 5 = 0] AAC Returned in GPO/first
GENERATE AC
[Byte 3 Bit 7 = 1] Pin try limit exceeded
[Byte 4 Bits 8-5] Issuer Script Commands processed on last transaction = 0

62. Attack
• Exceed three offline PIN tries on the card
• Request an online ARQC cryptogram using Generate AC request
• Get an AAC cryptogram back (9f270100, 9f10xxxx)
• Change the Cryptogram Type field (9f270180)
• Transaction passes the Risk Management checks at the terminal
• Cryptogram passes HSM integrity checks
• Bank the CVR field bit indicating that the Cryptogram Type = AAC

63. Demo

64. Demo 2

65. Finding vulnerabilities. Part II
NFC

66. NFC evolution
• Contactless near-field antenna connected to the same smartcard
• Same payment steps
• Same security measures: authorisation, authentication, verification
• Same memory area, same encryption keys (RSA, 3DES)

67. NFC evolution for MC and Visa
• Visa NFC is less secure than Visa EMV
• MC NFC is more secure than MC EMV
• https://github.com/a66at/NFCMiTM

68. Hands on time

69. 1. Reading The PPSE
?
Proximity Payment
System
Environment

70. 2. Card responds with AID
“ ” Applicatio
n Identifier

71. 3. Terminal selects AID
Applicatio
n Identifier

72. 4. Card provides PDOL
Currency
Amount
UN
TTQ
Processing
Options Data
Object List

73. 5. Terminal sends requested data
Currency
Amount
UN
TTQ
“GENERATE AC”
MSD?
EMV
chip?
qVSDC?

74. 6. Card provides Application Cryptogr
ATC
Track2
Equiv
CTQ
Online
Pin?
Signature
?

75. 7. Terminal conducts risk analysis
Config
CTQ
TTQ
CVM?
Acquirer
“Limits”
Floor limit
No CDCVM
CDCVM
CVM

76. Currency
Amount
UN
TTQ
Acquire
r
ATC
Track2
Equiv
CTQ
CDCVM=1
CVM REQUIRED=0
1. Change TTQ “CVM Required”
value from 1 to 0
2. Change CTQ
“CDCVM Performed”
value
from 0 to 1

77. Practical recommendations/reflection
• How to find new vulnerabilities using the blackbox approach
• What are the most interesting bugs for bb programs?
• How to show the impact of your findings?

78. Setting up the lab
• How to find new vulnerabilities using the blackbox approach
• What are the most interesting bugs for bb programs?
• How to show the impact of your findings?
• What products could you use? Your own cards and
• Your own terminals
• Unattended terminals
• Publicly available products: MasterCard JS EMV core, Stripe
• SaaS solution

79. Bug bounty aspects
• BB platform triage team (for public programs)
• Security@ or responsible disclosure pages
• Personal connections for private programs (LI, Twitter)
• Support team?

80. Bug bounty aspects

81. Thank you!
@a66ot
www.paymentvillage.org

82. Finding vulnerabilities. Part III
Magstripe

83. PSD2 and magstripe
• Magstripe is prohibited in Europe
• Technical Fallback is prohibited in Europe
• Both issuer and acquirer should be from the EU
• https://leigh-annegalloway.com/presentation-materials/
• https://www.paymentvillage.org/archive/defcon-28grayhat/labs

84. Magstripe Transaction Authorisation
• No transaction authorisation – Magstripe data is static
• No card authentication – Magstripe data can be cloned
Track1:
B46939575xxxx0760^IUNUSOV/TIMUR^22092210000000000445000000
CVC/CVV = DES-MAC(PAN, EXPDATE, SERVICECODE)

85. Magstripe attacks
• Bruteforce CVC – need access to the Transaction Stream
• EMV/NFC Track2 equivalent also has CVV/CVC
• Read data from EMV/NFC and write it to magstripe

86. Finding vulnerabilities. Part VI
Online

87. Scope
Where What How
Online payments
Add/Send/Convert
Merchant accounts
Payment devices
Card details
Cardholder details
Personal information
Making payments
Money withdrawal
Security features
Authentication bypass
Authorisation bypass
One Time Codes
Logic bypass

88. A few examples
• Enrolling card to Apple Pay without additional OTP
• Getting card requisites: PAN, Expiry Date, CVV
• Sending money (various options)

89. Protection mechanisms
• OTP
• PIN
• Cryptograms
• Client-side verification (iOS)

90. One Time Password Top 3 Issues
• OTP Bruteforce
• OTP limit bypass <- Lack of source/destination control
• OTP Integrity <- Race Condition

91. OTP Bruteforce
• 4 digit OTP code is requested
• 3 attempts for correct OTP entry
• Reset and start over again

92. OTP Bruteforce - attack
• Request 3 OTP and save them (1212, 2323, 3434)
• Repeat in cycles:
• Request OTP
• Enter one of each pre-recorded OTP
• Start again
• 1,000 OTP requests, 3,000 attempts give 60% chance to guess the OTP
• otp1.php demo

93. OTP Limit Bypass
• Can try 1,000 users
• Can try OTPs for the same user from 1,000 Ips
• otp2.php demo

94. OTP Integrity
• OTP checks the transaction integrity
• One OTP – one action/event
• One OTP could be used for more than 1 action
• otp3.php demo