The most interesting transaction would be a very large refund. I’ve seen organised crime groups target restaurants in the past to issue themselves £1k+ refunds. They pretend to pay for meal, and while they have the EMV terminal in their hand, they cancel the original transaction, put the device into management mode (using default passwords) and issue themselves a nice large refund.
It’s a complete pain in the arse for the banks receiving these refunds to catch and deal with properly. It’s surprisingly hard to return the money to the restaurant.
Of course it is still possible to skim the card number off of magnetic strip and sell it in the darknet. However, the static card number is becoming less and less of a relevant thing now a days as more sites/processors are migrating to dynamic auth such as Apple Pay etc.,
A good overview + detail : https://www.youtube.com/watch?v=Zv1DjtBwADg
And in this case the server can have a large antenna and not require physical contact.
So in essence, orders of magnitude worse than the magnetic strip.
Sniffing the NFC traffic gives the attacker nothing useful, just as skimming an EMV contact transaction gives the attacker nothing useful.
>The contactless EMV chip transaction path leverages the cryptographic functions normally associated with a contact EMV chip transaction and uses the same authorization and settlement fields as a contact chip transaction. [0] [1]
[0]: https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC...
[1]: See EMV specifications, “Book 2 – Security and Key Management,” Version 4.3, November, 2011, http://www.emvco.com/specifications.aspx?id=223.
Just ask for it yourself. That's what I meant with encryption not meaning jack if you are one of the participants.
to my knowledge, nobody has ever successfully demonstrated an exploit of this nature.
It is trivially employed.
That was a bit disconcerting.
A rogue terminal can decide to authorize the transaction with a “signature” (there are legitimate uses for this)
Or even with no PIN at all (there are also legitimate uses for this)
It’s also possible to do either of these 2 things and then report back that the transaction what authorized with a PIN
Most cards aren't like this.
With my UK issued AmEx & Visa cards (both Charge/Credit), at certain places terminal didn't even ask me for a PIN, and the transaction just went through as "Chip & Signature"
Which is kinda pointless since if you are paying and receiving service at the counter - you aren't really receiving a service to tip for.
Its crazy, but kinda reasonable
Checking which corresponds to what card is the hard step because you need access to an acquirer to my knowledge, and you'll lose that access quiet quickly if you attempt too many incorrect combinations.
EMV (the card standard used by all modern chip/contactless cards) supports PINs between 4-12 digits in length.
I’d change mine too except I use the PIN so infrequently (99% contactless now days) I’m worried I’d forget the new one!
Not clear how you would match the pin either without having some personal info on the user which you don't have.
In short, for the kiosk this is a anonymous transaction that was confirmed paid.
The most you could do is ask for more details in the kiosk app which would be clunky and very suspicious.
If you want to get creative with attacks you can, but sometimes comparing a creative attack to a "boring" attack can help frame the conversation.
I've written kiosk apps that landed across the US and while there was a ton of hand wringing about security, and in an informal setting I brought up a simple question:
If you reverse engineer the update process to have it show a penis, or you just carve a penis into the public display with a pocket knife, what's the difference and which is more likely to happen?
Also, vandalism is about the least interesting reason to hack kiosks. It can get you into an otherwise inaccessible network, which often contains all sorts of internal services with loose or no authentication (POS software often uses default creds because "it's on an internal netwok anyways"). Hacked kiosks are also often used as proxy servers for illegal activity and bots in DDoS botnets.
The update process can be backed on the kiosk side, hacking the remote side of the update process is a completely different story.
I mean in some cases that was a simple signed package hosted on an S3 bucket... how are you going to leverage that to vandalize a network of devices?
And the kiosks are never on an interesting network (if they were there's dozens of ethernet ports scattered about the place you can use to get access anyways)
Hacked kiosks being used as proxy servers when you need physical access to hack is also a very uninteresting problem. Why risk tying your physical self to a bot for nefarious usage when there are a million and one other "IoT" devices you can pwn instead?
Almost certainly not on EMV certified card acquirers, unless there is a bug in the firmware. These things are so locked down that, even as an authorised developer for the payment terminal, we had no access to the hardware, no way to view the cards encrypted payload, etc.
You just committed a felony to provide $10.000 in free food.
Might as well get a day job and make that contribution annually and skip federal prison.
If this part is correct, it seems like an attacker could compromise the reader itself.
Even if it was real firmware (I doubt it), it’s likely the firmware for the POS device interface. I don’t believe that firmware has any control over the actual payment processing bits of hardware, just the software intermediary.
Since that intermediary only has access to EMV tags (which anyone in the payment path has) there is no point. The secret encryption stuff that secures passwords is not controlled from any layer an attacker could touch, outside of documented configuration parameters.
Maybe they witnessed it, but that would be a bigger deal than some shitty windows box being popped. Certainly, that would not pass compliance.
Those card readers also typically have photodiodes in them and numerous tamper switches pressed to the case to wipe their internal memory if tampered. Just to be clear I'm not talking about EPROM - they have actual photodiodes inside along with physical switches and a coin battery that will wipe the ROM if tampered.
It's common to have the tamper switches trigger if you drop the terminal. They'll need to be re-flashed from scratch when that happens. eg. https://stackoverflow.com/questions/33872627/how-to-fix-tamp...
Anyway the TLDR is that the Card Reader part of any POS system is reasonably secure.
In that case the risk of accepting malicious updates from insecure touch screen would be much less.
You may be thinking of tokenization, which is a feature of some services such as Apple/Google Pay. This is where a “fake” account number—really a number that is scoped to eg a specific device or a specific merchant—is sent with the transaction. That then gets resolved to the real number somewhere down the processing pipeline closer to the card issuer. The benefit being if someone snoops this tokenized account number they won’t be able to use it thanks to the tight scoping.
The terminals really don't trust the POS systems.
You could reprogram a terminal in a bar in a few seconds on a Friday night. Wait for the weekends takings to clear into your merchant account, and then take off with the money. The way that it falls down though, is that you need a merchant account, and there’s a lot of KYC and due diligence to get through if you want to set one of those up (there are a lot of merchant initiated scams, and your bank doesn’t want to be on the hook for them).
That's the difficult part - since the acquiring bank is fully financially responsible if you do so (they'll compensate everyone else involved for the fraud chargebacks, no matter if they can recover it from you), they generally take quite stringent steps to fight merchant-initiated scams, and the simplest step is simply freezing the money for some time; 30 days is not uncommon but I have even seen 90 days if the merchant's profile is risky or if the incoming payment volume suddenly increases significantly - the bank is effectively treating any payments to the merchant as a line of credit or letter of guarantee until it's clear that those payments won't be fraudulent or charged back. So a merchant can quite realistically do some shenanigans with a reprogrammed terminal, but they won't be permitted to take off with a large amount of money from the merchant account until a sufficient amount of time will have passed for the first chargebacks or complaints of fraud to show up.
I think the main reason this never happens is because there’s a lot of easier and more profitable scams you can operate as a fraud-oriented merchant.
They started accepting signups a couple weeks before school started, and on the second day it was running, after several hundred signups (of ~$200 each iirc), apparently some security people from the bank showed up at the orientation office at the school basically just to confirm it was legit. (I don't remember if they suspended the account first or not)
I had built a few online store sites using merchant accounts by then, but nothing that went from zero to that volume so quickly; it was fascinating to see that check in action.
I wonder what volume it would take to trigger such scrutiny today, and what it would look like..
But in this hypothetical would there be chargebacks? People went to a bar. They consumed, and paid for it. As far as the costumers know it went all good.
The one who is harmed would be the pub. And presumably they would complain and soon.
I don’t doubt that the whole scheme would come to light quick, i’m just questioning the exact mechanism.
During that procedure the terminal unique ID is sent, and depending on your environment, if you have a stable outgoing IP the connection might be filtered on that as well (assuming you do that on site, not at a POS provider). Jumping through a bunch of hoops you might still be able to hook a POS on another merchant account, but once the issue is detected there would be enough info to reverse the transactions (doing that after capture could cost fees, but it’s still better than nothing).
Looking at the delays between the transactions being cleared and the money appearing in your bank account, even with the best timing you might not see a penny of all of that.
To be able to pull this off:
1. You need to register yourself as a merchant at an acquirer bank. Either directly or through intermediaries such as Stripe/Square etc.,
2. Go through reasonably stringent KYB (Know Your Business) process.
3. Do a few legitimate transactions so that everyone in the payment processing chain (acquiring bank, payment gateway etc., issuing bank, network (Visa/MasterCard)) begins to trust you.
4. Reconfigure the kiosk to use the above merchant account.
5. Pull out money from the acquiring bank before enough customers raise a charge-back and your your account is marked as fraudulent by someone/everyone in the payment processing chain.
These fly-by-night merchants are indeed created; especially at marketplaces such as EBay, Amazon. But to do it at a physical kiosk such as McDonalds' seems like a low ROI to me.
They have dedicated servers, so I'd expect McDonald's and other big chains to have them, too, which means that you couldn't send payments no anyone outside the mother company.
Yes they do. In fact, you can read the CC number from the chip without even knowing the PIN.
But yes I think this is more a "hey there is so much insecure tech out there - here is another example" as opposed to "we are all dead and our bank accounts emptied"
In some solutions, the readers are in fact hooked up directly to the POS system. However, the card terminal does not see unencrypted payment data. The POS is acting as a network bridge or switch, while getting limited information over network from the terminal.
In fact, I'm not sure that's even something that's allowed in large scale installations today.
That’s why everyone has/is moving off mag-stripe (depending on country) and to EMV. With EMV and EMV contactless the terminal never gets the full card number, among many other significant security improvements.
The terminal encrypts it before sending it over the wire
The EMV spec doesn’t include encryption of any data sent to the terminal from the card.
The transaction cryptogram is signed, however.
> However, the card terminal does not see unencrypted payment data.
The card terminal does see unencrypted payment data. Hard to see your comment as ambiguous?
> If someone installs malware on here - just insert a usb stick or use the recovery mode - then tada we have the next generation of atm skimming.
Which is just not how these payment devices work- they are entirely separate, they are sent a request to make a transaction, that transaction (and also likely the transaction request itself) occur entirely in a secure connection between someone like Verifone, and the device itself.
The PC has has no way to get those card details, only request a transaction and confirm a payment status as successful or failed.