[Idea/Question] RFID Programming and Interaction with Payment Systems

[zenith]

I've always been interested in payment and POS systems, but I haven't delved into the area at all as it's technically beyond my understanding. In any case, it's been a slow Monday at work and I started thinking about it more...

When you insert your chip into a payment terminal, obviously there is an exchange in data; the system recognizes that a chip has been put in, and knows who's card it is so that it can match the PIN and verify the cardholder. What I'm curious about is the type of data that could be transferred, i.e., could an RF chip be programmed to transmit malicious code to the terminal? What kind of safeguards could the terminal have in place to prevent this?

From what I've looked up, I understand that the RF chips can only store ~2kb of data. Assuming the language you're working in is 1 byte/character, you could probably get 50 lines worth of code stored on a chip.

Even if the payment processing itself couldn't be tampered with, it would be cool just to be able to print something to the screen (like a nyan cat animation or a false message saying that the payment is successful).

I'm not looking for any specific answers, just thought it could be an interesting theoretical dialogue.

[0E 800]

Sounds interesting.

Found this:
http://www.ulm.ccc.de/ChaosSeminar/2015/01_RFID_Malware

Unfortunately I do not understand german. If someone could do a write up of the Video it would be greatly appreciated ...

I also notice that most my search results are from 2006.

Pretty sure with most cases, the RFID just contains a unique ID maybe salted. You would need malware already installed on the server. Hack the server, change the id to point to your malware so when the next time they wave their RFID tag, instead of it clocking the person in, it runs your malware.

[straycat]

oe800 is right if I remember correctly the usual targets in an attack like that would be hidden in memory that way it's actions are harder to trace. Most POS machines run off of an rdp server and that's the ticket in I believe. So attacks are most likely not going to target the card readers themselves but the rdp server or the machine that actually runs the batch and sends off all the numbers at the end of the day. I don't know shit bout chip and pin tho so I could be way off with this.

[blindfuzzy]

I've always been interested in payment and POS systems, but I haven't delved into the area at all as it's technically beyond my understanding. In any case, it's been a slow Monday at work and I started thinking about it more...

When you insert your chip into a payment terminal, obviously there is an exchange in data; the system recognizes that a chip has been put in, and knows who's card it is so that it can match the PIN and verify the cardholder. What I'm curious about is the type of data that could be transferred, i.e., could an RF chip be programmed to transmit malicious code to the terminal? What kind of safeguards could the terminal have in place to prevent this?

From what I've looked up, I understand that the RF chips can only store ~2kb of data. Assuming the language you're working in is 1 byte/character, you could probably get 50 lines worth of code stored on a chip.

Even if the payment processing itself couldn't be tampered with, it would be cool just to be able to print something to the screen (like a nyan cat animation or a false message saying that the payment is successful).

I'm not looking for any specific answers, just thought it could be an interesting theoretical dialogue.

Take a look at this: https://www.dhs.gov/xlibrary/assets/foia/US-VISIT_RFIDattachE.pdf

[th31nitiate]

The chip on the card is like a data store. They are different types of chips with different functionality. The reader would also have have different capabilities depending on when it was made. User inserts the card, the chip is decrypted via an algorithm using your pin as the decryption key. Inside the chip is information relating to what bank account + access key for that account. After this point an encrypted connection is established with bank systems. Then information is exchanged between pos terminal and bank. Pos terminal request's from bank authorization. if there is enough money and security checks passed then authorization of the transaction is granted.

When it comes to exploiting this an attacker can do several things. The most interesting I have seen was taking advantage of the way in which the programmer had written chip the reader on a POS terminal. There was a vulnerability that could be exploited in the reader to allow arbitrary code execution on the device.

• To take advantage of this you would  craft a special shell code and place that on the chip on the card as data.
• You would then try to make a purchase it would decline but the payload will execute malware on the device.
• The malware will to and start catch pin and relevant card information.
• You would them leave the store and say im going to get my other card i will be back l8a.
• Wait till closing time and let the malware collect customer data through out the day.
• Near closing time go back to the same pos and say you want to try again.

When you try this time with a different card and payload, with instructions telling the malware to clean up and put all collected data on the card. It will decline once more but then just pay with cash and you leave store with lots on chip+pin info to go clone on to other cards and exploit different pos in a different way.

Again this attack is only vulnerable on one type of Verizon type pos system, for other pos you would need to hope same programming errors exist and also the payload will need to be crafted differently.

p.s the terminal im referring to is:

[Greasabilly]

You got me interested in the idea.  I started looking around and found this website  http://www.rfidvirus.org/. It has some pretty informative  material and if you scroll to the bottom of the site, it has some pretty useful details on how RFID works and how to write viruses and worms for RFID.