My HSA debit card, issued last year, still doesn’t have a chip.
I remember using Google Wallet years before Apple pay existed. When Apple Pay was announced so many cashiers thought they didn't support tap to pay credit card transactions despite me using it at those locations for years. What was really annoying was a lot of vendors turned off the feature while they "investigated" supporting Apple Pay, and didn't turn it back on for another year or so after they slapped the Apple Pay logo on the exact same terminals.
Nobody cared until Apple did it.
It's curious you're seeing so many stripe fallback incidents. Is this a USA issue?
Heck a lot of the terminals here can't swipe a card at all
If I travel to the USA I'll be unable to use these old vending machines and parking meters.
In Europe it's changed 15-20 years ago, when EMV-capable terminals became required, and acceptance of magnetic stripe cards got phased out soon after.
Since Apple Pay became a thing a decade ago, we don't even get US tourists confused by inability to swipe their cards anymore.
And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.
... such as this one: https://www.paxtechnology.com/a77
Banks don’t have wide open protocols where anyone can submit a credit card transaction and have it go to arbitrary accounts.
Remember that credit card companies eat the cost of the fraudulent charges. They’re not going to make it easy for those to occur.
I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.
That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend.
In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know:
a) Where your terminals are deployed
b) Your real details
c) The terminal's ID and the terminal's serial that maps to that specific merchant ID.
So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24.
Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have:
1. Their bank account number 2. Their physical address 3. The company registration number 4. Verified ID copies of the owner, directors, managers, etc. 5. Their money (from their transactions).
So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree.
3.
Probably not worth the small amounts you could make before caught
If someone altered the terminal to charge more (a hypothetical suggestion above), they could recoup that money from the merchant’s account because they have an agreement in place.
You can’t run arbitrary transactions to arbitrary accounts (the other proposed attack above) because there isn’t an agreement in place.
Not supposed to be possible on a certified terminal. The certification tests this particular case (the transaction is a hash of the keys, amount and a few other things. The display of the swipe/tap/insert screen and the pin-entry are under control of the certified kernel, so the userspacve application has no control of the amount that is displayed).
> And maybe even send the money to a different account.
Not from the card reader.
That's happened at least several times already.
I believe breached PoS terminals were what happened in the big Target hack.
The problem is that PoS terminals are not EMV terminals. EMV terminals have been through a certification process, and the hardware part of that certification ensures that the vendor only runs signed-binaries.
Honestly, even if you could write and sideload (or even replace) the applications on the EMV terminal, I do not see a way to get them to a) run, and then b) send money elsewhere.
Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it.
And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.