Hacker News Reader

Comment by noodlesUK | Hacker News Reader

How do these skimmers work with chip&pin? I understand how magstripe skimmers work, but my understanding is that chip&pin is an active challenge response protocol. I’d love to hear more.

View on HN

Even with EMV transactions, they are apparently able to get the card # which is transmitted in clear text by the chip. And the PIN from the keyboard overlay for debit transactions. Later they can clone the card # onto a fake mag stripe card and use the fake card for card-present purchases.

They probably cannot make card-not-present (online) purchases since I don't think they can get the CVV.

https://krebsonsecurity.com/2021/02/checkout-skimmers-powere...

https://security.stackexchange.com/questions/151081/shimmers...

> In addition to the track-two data on the magnetic stripe, EMV cards generally have identical data encoded on the chip, which is read as part of the normal EMV transaction process. If an EMV reader is compromised to the extent that the conversation between the card and the terminal is intercepted, then the attacker may be able to recover both the track-two data and the PIN, allowing construction of a magnetic stripe card, which, while not usable in a Chip and PIN terminal, can be used, for example, in terminal devices that permit fallback to magstripe processing for foreign customers without chip cards, and defective cards.

https://en.wikipedia.org/wiki/EMV#Opportunities_to_harvest_P...

They might not need CVV, if the transaction looks “good” otherwise:

> A payment can still be successful even if the CVC or postal code check fails. This is because card issuers take many signals into account when making a decision about whether to approve or decline a payment. In some cases, a card issuer may still approve a payment they consider legitimate, even if the CVC or postal code verification check fails.

source: https://stripe.com/docs/radar/rules#built-in-rules

:-(

I recently went through the opposite of this. A purchase at denon.com was declined, got a "please verify" email from my issuer which I approved and re-did the purchase. My issuer authorized the payment the second time, but then it got held up by NoFraud who sent me their own "please verify" email which I did. I had used an iCloud Hide My Email address for the purchase so a day later I get another email from NoFraud:

> Thank you for confirming your recent order. We are the fraud solution for the merchants website. We flagged the order for additional review before we notify the merchant to process it. To complete the verification for approval, we require an alternate email address for the cardholder. Please respond with an alternate email address.

At that point I tracked down NoFraud's phone # and called them to finally get the transaction approved.

> I had used an iCloud Hide My Email address for the purchase so a day later I get another email from NoFraud

I got hit by a merchant using "NoFraud" as well. After making an order from the merchant's site, using Apple Pay on the web (which is, allegedly, rather hard to fake), I received an email saying my order was canceled as it "appears that a merchant-specific email address was used" and to "please resubmit the order using your personal contact details".

They were right, because I always use [merchantname]@subdomain.mydomain.com. Whatever it was couldn't have been that important because I didn't bother redoing it if they're going to be that picky.

(I can't find the purchase confirmation and subsequent email in my email, probably because I deleted it out of annoyance, so I'm not naming who I think I remember it being just in case I'm wrong)

as if Email is some sort of durable identifier in the first place.

This is the thing that got me. Where the heck is NoFraud getting its training data[1] and why is an email address even considered relevant to the safety of the transaction? The item was shipping to my home address which matches my CC billing address.

[1] "NoFraud’s multi-layered solution analyzes thousands of data points fusing machine learning."

EMV doesn’t transmit the full card number in the clear. I don’t know how they’d get it. IIRC the track data is sanitized, but maybe it wasn’t always. I’m not even sure all cards give it in a modern EMV transaction.

The old mag stripe emulation mode of contactless did, but that’s legacy and many places won’t accept it and cards won’t do it.

However the good old “break the slot or chip reader so they have to use mag stripe and scan the card things the old fashioned way” technique still works great.

Googling "EMV sniffer" returns a bunch of sketchy sites that claim they get the card number from the chip, not the mag stripe. That's also what seems to be implied by the submitted link. Here's another post claiming the card # is readable from the chip:

https://security.stackexchange.com/questions/161493/what-inf...

I believe it’s at least stored on the EMV chip: if you tap a credit card to a flipper zero you’re able to read the full card number and expiration date, and contactless is just over-the-air EMV as I understand it.

Oh yeah, it must be in there. If you were to etch down to the chip with acid I’m sure you could see it.

Contactless has two forms. The old one is mag-stripe emulation. It would literally just respond with the information from the mag-stripes. It was exactly as secure as mag-stripe. Probably worse because you didn’t need to physically move the card over a read head.

That’s no longer supported in many (most?) modern cards. I know ApplePay refuses to do it. I think card brands have said to stop using it but I’m not positive.

The other mode (absolutely dominant in contactless) works through encrypted EMV tags the same as you get when using a physical slot. The order of things is a little different but it’s just as secure.

Some skimmers have a camera to capture an image of the card's CVV as well as another copy of the name/number/date.

Here I was thinking that my near-illegibly worn-away CVV was a reason to get a replacement card... but instead it's a surprise security bonus! :p

Actually, I spoke too soon... the signature-strip has been worn away too and now that I really look at it, I can make out the word "Void" underneath.

Good thing that the back of my phone has neither of those.

Seems like a good idea to wrap the card in something opaque.

The US still has a heavy reliance on magstripe, even though we rolled out EMV, and many cards still have it, and you can just take a stripe dump regardless.

The actual user of the stolen card dump will cause the terminal to allow a magstripe fallback (typically with a bad chip on a fake card that won't read) -- "aw jeez my stupid chip isn't reading" is still every much a valid excuse to a cashier to go to magstripe.

I think there are also just lots of POS systems in the US that aren't on EMV yet. Major retailers are on EMV but random old rural businesses probably aren't.

Some big chains still haven't switched.

I was in a major home improvement store a few weeks ago, and it was swipe-only. Either Home Depot or Lowe's.

Lowe's. Lord help the poor souls who maintain that system; it looks like the kind of thing that's just chock full of COBOL.

wal-mart has emv, but no radio-based payment

Plus lots of cards without EMV at all, usually gift cards or until recently EBT.

Makes me think about intentionally corrupting the magstripe on my cards. I wonder if that’d cause any issues.

I can’t remember having to fall back from the chip to a swipe in ages, and I have a couple of cards, so I could keep one as a backup with a working stripe just in case (long ago I found myself far from home and low on gas, with no cash, a dead cell phone and a “suspicious transaction” blocked credit card, and I’d rather not repeat that experience).

It's only an issue with EMV Fallback, which you'd probably not need if you have a backup card that is good. Basically if the chip or near-field antenna on your card fail, the fallback is to collect a magnetic stripe read. Properly-configured readers don't need the stripe read to complete a transaction.

Properly configured merchants don't even need the payment terminal to complete a transaction. They should be able to key the card number if all else fails. I say corrupt your magstrip if it makes you feel better.

> How do these skimmers work with chip&pin?

My understanding is: They don’t. If you stick to contactless payments, you’re not at risk.

The image shows the skimmer gadget sitting on top of the pin pad and the bottom card insertion slot (the one that takes a chip). On these card readers the magstripe reader is on the right hand side iirc. I’m wondering what you can do having connected to the EMV contacts and recorded the PIN. I suppose you could make a transaction, but it would have to presumably happen at the same time as the legit transaction (which would then immediately get flagged as fraudulent)

Not much. The chip doesn't transmit any credit card numbers. What's really happening in an EMV transaction is the amount due is transmitted along with some identifying information from the host to the card reader. The reader then authenticates with the chip card using asymmetric cryptography. Once this authentication is done, the reader sends an amount due and the chip card checks its authorization rules, and responds with some encrypted data that represents the transaction amount and that depends on a private key embedded in the card. You could replay the transaction at the exact same time as it is happening, but you'd have to use the same amount due. And there are other identifiers for EG the terminal that you'd have to know. If you're curious, EMVco makes the specification available online in documents titled Book 1, Book 2, Book 3, and so on: https://www.emvco.com/specifications/

You'll want an RFID blocking wallet or sleeve to supplement this plan. Thieves will use an RFID skimmer and just wave it near your pocket to grab the info off the card when it responds.

Has anyone ever shown a practical attack for EMV contactless?

I know the old mag stripe emulation was vulnerable, but EMV contactless shouldn’t hand out the card number and uses cryptographic signatures. You’d have to capture and play back a transaction (not randomly scan a card) and there are time stamps and transaction counters that would be wrong and the terminal ID wouldn’t match.

Reply on news.ycombinator.com