Comprimising or affecting card readers, billing systems, or POS terminals using a malicious card

Question

Our company got a new card printer for employee IDs. It was a bit expensive and we had to undergo a background as it allowed us to print both mag strips and EMV chips. I don't understand enough about EMV chips but I found it would be very easy to duplicate my debit card's mag strip and make a fully working clone. As well as making it store whatever I wanted it to store. Which got me thinking about what are the risks of blindly accepting card data. Obviously a programmer should sanitize all input but what if there was an oversight. And someone finds an exploit in a processing/billing system to run their card and having it execute code embedded in the card. Much like how certain PHP scripts started getting compromised when they attempted processing an image's exif data or any other scenario of failure to sanitize input. I imagine it would be difficult with mag strips since there are limitations on what characters you could use and the length depending on the track. Like I mentioned I am unsure of the inner workings of EMV chips but maybe they would have more possibilities.

So I have a couple of questions I have been curious about. Is it possible to compromise or disrupt a system through a malicious card and has it been done before? Has this scenario already been explored and certain procedures are taken to prevent this by POS/Vending vendors?

Answer 1

What I know about the POS products I resell/support, when taking a credit card for a payment there are set # of characters it's looking for.

In a general sense it's looking for something like this:

• 16 digits for Visa/Mastercard/Discover
• 15 for Amex (will just use a Visa/MC/Discover for example)
• 4 digits for expiration
• 3 digits security code

So the system wants the data in this format

[Card number][Expiration][Security Code]

There is other information in the stripe, but just trying to illustrate a simple example.

Also, not mentioning chipped cards, just in reference to old magnetic strip only cards, for my example.

So let's say my POS system is expecting 23 digits (16+4+3) and I make a fake card with a card printer. I have one right next to me on my desk. However, I mess up in my order of information.

Instead of [Card number][Expiration][Security Code]

I do

[Security Code] [Card number] [Expiration]

The system would still take the information I've given, but most likely will come back with an "invalid card number" like message.

So redo my fake card with the right order of information. Go to a store and try the card and it works fine.

Decide to include my payload at the end of the card. My thought that one of two things would happen:

1. The card would go through normally, the system took it's 24 digits it was looking for submitted to the credit card company for authorization.

2. The POS would not accept the card as, the amount of digits on the magnetic stripes didn't match the standard set.

On #2 I have seen happen in the wild. A chain of stores my company supports is next to a large university. The University gives out ID cards, but they are also a credit card for the students to use. They can use the card to buy stuff, and to get services (check out books and such) at the University.

Magnetic Stripe Cards have up to 3 tracks of information. Two tracks are used for a credit card transaction. One track can be used, but the merchant pays an extra fee as it wasn't a "track 1 & track 2" transaction.

After frequent calls from the store owners with the problem of "XXXX university cards don't work, unless we manually enter them", I went to the university and they let me see a card and swipe it to see how the information was being put on the magnetic stripe. They were thrown back a little bit by my request, but they understood the problem and I did my test in front of them after an IT staff from the university watched me.

They were putting student ID information on Track 3 of the cards. So the POS system I support was reading track 1, track 2, and track 3 and not accepting the card because it had too much information.

To fix the problem, the MSR (Magnetic-stripe-readers) at the stores we had to program to not read Track 3 information.

That was my experience with one POS product. There are hundreds of POS products out there, and I would assume it would be standard practice to only accept "X" number of digits.

If this were a possibility, I would think the "weak" point would be the payment gateway that sends the card information to the bank for approval.

Point of Sale Computer---->Payment Gateway---->Bank of card-owner

The payment gateway sets the syntax of how they want to the data to come to them.

They might like a different way than my example of

[Card number][Expiration][Security Code]

So if we thought of exploiting it, I guess similar to a SQL injection attack, the payment gateway would be where to look. PG's are pretty hardened systems so I'd imagine they wouldn't tolerate anything that's NOT in their syntax.

Answer 2

The hack is in theory possible. The issue you will run into is that you are dealing with a lot of unknowns. You do not know how the card data is read or verified. You also don't know what sanitation of the data is being performed. When a malicious card is read into a system, which is properly sanitizing data, you may pass your entire malicious payload to the payment processor. It wouldn't be hard for them to figure out what was going on and follow-up with the store to file a police report. Validation can also be quickly verified by the store by using the Luhn Algorithm. This is essentially a quick way to verify that the numbers are legitimate.

If you happen to get lucky and successfully compromise a POS terminal, you will need to offload the data. The Target and Home Depot breaches resulted in the accumulation of tens of millions of card numbers. There isn't really an easy way to offload the data. Do you somehow load the numbers back onto the credit card tracks? Or you could have the POS device try to upload the file to a third party website, however, PCI-DSS requirements dictate strict firewalling rules. This makes it extremely unlikely that the POS system has internet access. In the case of the above hacks, the attackers needed to use a jumpbox to flip between network segments.

Criminals are very good business men and this adds an undue level of risk versus reward. It's much safer to try to breach POS segments remotely. They have more control over the tools available and an incredibly effective way to mask their origin.