This vulnerability is similar to the last MST flaw that I presented this summer. Without any fixing update yet: http://www.zdnet.com/article/all-talk-little-action-samsung-shows-how-not-to-do-security/

I was thinking about this method since April, but I could not find a way to achieve it until now. Samsung Pay basically implements the cryptogram and counters internally to protect its transactions; this process by itself is a flaw because the system needs a constant Internet connection to update the cryptogram and consequently its tokens.

I noticed that the system generated two tokens in each transaction, those tokens are in the device with a provisioned status; which means that they are valuable to make transactions even without Internet connection. One token is for MST and the another for NFC. For example, if the transaction id of the MST token is 151, the NFC’s will be 152. Always NFC will be +1 in that part of the token. Also, the service code for NFC will be 201.

Because the system processes the cryptogram internally, when the users try to make a payment, the system “generated” the tokens, but leaves the NFC connection naked. I meant, it is just sent the token by itself nothing more, no cryptogram, no counters, nothing.

MST: ;4097900000533726^21041011144000151305?
NFC: ;4097900000533726^21042011144000152281?

The only security between those two is the service code number.

This is a vague explanation of the process in a NFC transaction at Samsung Pay: the user makes a transaction, the Visa Token Service Provider(VTSP) detects that; if it is a NFC token, makes a request, the phone answers, hey it’s me, so the VTSP accepts the transaction; it sends a signal back to the phone to update the cryptogram.

It seems like the HCE framework is interacting without a secure element. The NFC instead of use card emulation with secure element, it feels like it implements host-based card emulation.

If an attacker clones the emv tags and tries to make a transaction, but Samsung Pay is online, the system will tell the VTSP, “I am not making that transaction.” and it will decline it.

So I thought if the attacker could jam or put the victim’s phone offline, the system will generate the provisioned tokens; the attacker can intercept the emv tags and use another device to transmit the track 2; the VTSP will request info, the phone will not answer but the transaction will go through.

I am assuming that this happened because the VTSP has a valid token which was validated with a fingerprinting or pin protection, so if the phone does not answer a ping, the VTSP could take that as a small issue which will not affect the transaction process, so it is going to validated the transaction and make it through.

Transaction log:

ATS:
00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
6F 6D 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 5B BF 0C 58 61 2C 4F 07 A0 00 00 00 98 08 40 50 10 55 53 20 43 6F 6D 6D 6F 6E 50 72 65 70 61 69 64 87 01 02 9F 2A 01 03 42 03 40 59 55 5F 55 02 55 53 61 28 4F 07 A0 00 00 00 03 10 10 50 0C 56 69 73 61 20 50 72 65 70 61 69 64 87 01 01 9F 2A 01 03 42 03 40 59 55 5F 55 02 55 53 90 00
00 A4 04 00 07 A0 00 00 00 03 10 10 00
6F 3F 84 07 A0 00 00 00 03 10 10 A5 34 50 0C 56 69 73 61 20 50 72 65 70 61 69 64 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 10 08 40 08 40 90 00
80 A8 00 00 23 83 21 F6 20 C0 00 00 00 00 00 00 01 00 00 00 00 00 00 08 40 00 00 00 00 00 08 40 16 10 11 00 77 37 75 E7 00
77 66 9F 26 08 35 56 96 3E DB 9E D7 8A 94 04 08 03 03 00 82 02 00 40 9F 36 02 00 50 9F 6C 02 01 80 9F 6E 04 23 8C 00 00 9F 10 20 1F 43 01 00 20 00 00 00 00 00 00 00 00 06 68 17 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 57 13 XX XX D2 21 12 01 68 17 01 00 80 44 3F 5F 34 01 00 9F 27 01 80 90 00
80 CA 9F 17 00
69 85
80 CA 9F 36 00
69 85
00 A4 04 00 07 A0 00 00 00 98 08 40 00
6F 43 84 07 A0 00 00 00 98 08 40 A5 38 50 10 55 53 20 43 6F 6D 6D 6F 6E 50 72 65 70 61 69 64 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 10 08 40 08 40 90 00
80 A8 00 00 23 83 21 F6 20 C0 00 00 00 00 00 00 01 00 00 00 00 00 00 08 40 00 00 00 00 00 08 40 16 10 11 00 57 FB FF A7 00
69 85
80 A8 00 00 02 83 00 00
69 85
00 B2 01 0C 00
69 85

This slideshow requires JavaScript.

Proof of Concept: