[HN Gopher] MagSpoof: Wireless Magstrip Spoofer
___________________________________________________________________
MagSpoof: Wireless Magstrip Spoofer
Author : r3trohack3r
Score : 85 points
Date : 2022-12-03 19:35 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| petesergeant wrote:
| Samy is _still_ my hero
| skrowl wrote:
| Is this basically the same thing that Samsung smartphones used to
| do that allowed you to pay at swipe-only terminals?
| arjvik wrote:
| > as well as learn about and create your own devices similar to
| other existing, commercial technologies such as Samsung MST and
| Coin
|
| Yup
| notme1234 wrote:
| This is less useful nowdays, since magstrip are deprecated (at
| least in most developed countries).
| ford wrote:
| I long for the day I can carry my phone or watch without needing
| keys or wallet. The fact that most adults carry at least 3 things
| (keys/phone/wallet) at all times in 2022 is crazy.
| Beta-7 wrote:
| That day is closer than you may think. I sometimes only have my
| phone with me as i can pay using only it (something like
| Google/Apple pay, but through my bank's app) and can unlock my
| front door thanks to Home Assistant. Both of those (should, I
| don't have one) work with a smart watch.
| saaaaaam wrote:
| I've been able to do this for about five years over here in the
| U.K. - and very regularly do.
| gkoberger wrote:
| Agreed completely, but keys/IDs work 100% of the time. Even if
| virtual versions work 99% of the time, that's still not enough.
| espenwa wrote:
| Can't help you with the keys or ID (yet), but I exclusively use
| the stored cards on my Apple Watch for payment. It is so
| reliable (in Norway) that I haven't brought my wallet on normal
| days in 2+ years.
|
| Even on vacation in Northern Europe (Belgium, Netherlands,
| France, Germany) and on a business trip to the US
| (California+Texas) this year, I very rarely had to use the
| physical cards. NFC just works. Everywhere.
|
| I still bring the cards on important occasions or when going
| further than a normal drive, though - a testament to the fact
| that the day you're longing for is not _quite_ here yet.
| throwawaaarrgh wrote:
| I agree it would be convenient. But consider the new dangers:
| 1) pickpocketing would suddenly be 3x as profitable and 3x as
| easy, 2) lose one thing and you've lost everything, 3) if one
| thing stops working, everything stops working, 4) venues where
| you have to give up your phone means carrying extra cash in....
| a wallet, 5) cybercriminals can now steal much more from you
| without ever getting near you, 6) I imagine there will never be
| a universal standard for these things so changing vendor will
| be quite difficult.
| cowsup wrote:
| I can theoretically leave my home with just my smartphone. I
| can use it to pay fare at the local train station, get
| directions to restaurants, read the news, pay for food and
| coffee, and even lock / unlock my apartment.
|
| I do still bring my wallet and keys, because I'd hate to run
| into a scenario where my phone does get lost, stolen, or
| damaged, leaving me stranded without a way to get home. But
| the concept is definitely there, and for someone less
| paranoid than I, it's definitely possible to live a life of
| convenience.
| [deleted]
| nati0n wrote:
| Incredible application of technology, interesting read about the
| internals of credit card payment information storage.
| Loggie wrote:
| Although you can disable the bits in the service code pertaining
| to the cards ICC capabilities, in theory there's a good chance
| that the track2 equivalent data on the chip is different from the
| track2 data on the magstrip. That would make it easy for the
| issuer to determine that the track2 has been modified and reject
| the transaction and/or flag the account for fraudulent activity.
| Scoundreller wrote:
| Yeah, whenever I try to swipe my card, it instantly tells me to
| use Chip and PIN. I think it's just to provide rapid localized
| responses, but who knows if some banks are misconfigured and
| overly trusted the magstripe data to block magstripe
| transactions.
| ComputerGuru wrote:
| But that's what's covered in the article. The "block
| transaction and require chip and PIN" flag is stored on the
| magtrack itself.
| lxgr wrote:
| The bank/processor also knows it and is able to reject any
| modifications. Whether they do is a matter of their
| security posture.
| NavinF wrote:
| Aww I misread the title. Was hoping this would unlock full speed
| wireless charging without Apple's magsafe charger.
| stevehawk wrote:
| I'm pretty sure my Samsung watch from 2014 did this?
| gambiting wrote:
| The american reliance on magstrips is crazy. Over here(Poland) I
| don't think I've seen a magstrip-compatible terminal for years,
| they just don't have the swipe part anymore, it's been removed
| from terminals and cash registers ages ago.
| grishka wrote:
| In Russia no one swipes their cards, and swiping doesn't work
| if you try, but the terminals do have the swipe part and the
| cards do still come with magstripes. There's a separate
| magstripe reader, usually built into the cashier's monitor, at
| places that use magstripe cards for loyalty and gift cards.
| atonse wrote:
| The US market has been historically different for other
| reasons.
|
| The big one is liability. In the US the cardholder is rarely
| liable for fraud charges. Which is why the minutiae of credit
| card security mechanisms just kind of doesn't matter to us.
|
| But from my understanding, in Europe and places like India, the
| cardholder is usually liable. Which also explains why
| cardholders seem to be a lot more anxious about these things in
| those countries and don't really understand how Americans don't
| care too much, say, that a waiter can walk off with your credit
| card at a restaurant.
|
| Not claiming one system is better than the other... actually
| no, maybe I'm biased but I'm happy that the US system places
| liability on businesses rather than consumers. Which is why
| most US customers don't care about these things and freely use
| their cards for everything.
| seszett wrote:
| > in Europe and places like India, the cardholder is usually
| liable
|
| I suppose it depends on what you mean by "usually" but no, in
| the EU generally you just go to the police station which has
| a form for declaring credit card fraud and the bank often
| reimburses you before receiving it. Your replacement card is
| free on this situation. It is up to the bank to get their
| money back if they want to bother.
|
| I don't know of a situation where you wouldn't get reimbursed
| by your bank.
| cbm-vic-20 wrote:
| American here- most retail terminals here support NFC and chip-
| I haven't used magstrip in a retail environment for years- even
| mom-and-pop shops support NFC. Most gas stations accept chip,
| but not many accept NFC yet, though I'm seeing it more and
| more. Some gas stations still only accept magstrip.
|
| We still have the stupid policy in restaurants where you hand
| your card to the server and they walk away with it (their
| terminals are usually chip), which is something that a lot of
| foreigners freak out about.
| gambiting wrote:
| >>which is something that a lot of foreigners freak out
| about.
|
| Well yes, we're being told by our banks specifically that if
| you give anyone your card and they walk away with it, they
| won't cover you for fraud. The card has to stay in your sight
| at all times. In fact if you are in EU and you find a
| business that does this, you can report them to
| Visa/Mastercard and they will get a warning if not outright
| lose their terminal.
| baal80spam wrote:
| > We still have the stupid policy in restaurants where you
| hand your card to the server and they walk away with it
| (their terminals are usually chip), which is something that a
| lot of foreigners freak out about.
|
| And rightfully so! What is stopping them from copying the
| PAN, expiry date and CVV2? I wouldn't give my card to anyone
| - that's what portable (wifi/BT) terminals are for.
| Andrew_nenakhov wrote:
| I always scratch away cvv2 code from a card.
| wiml wrote:
| What stops a server with a good memory from looking at your
| card as they put it in their terminal and remembering it
| for the 30 seconds it takes to walk away and note it down?
| They already reliably remember fairly complicated table
| orders which have got to have more bits of entropy than a
| credit card number.
|
| Credit cards handle risk very differently than we do for
| account passwords. They expect numbers to leak regularly,
| but the downside of a leak is bounded in a way that
| password leaks often aren't, and the issuers and merchants
| eat those losses as a cost of business.
| lxgr wrote:
| US merchants have widely accepted magnetic stripe card payments
| for many decades more than the rest of the world. It's a pretty
| typical example of a first-mover disadvantage: More legacy
| systems to deal with.
|
| That said, the switch to chip and contactless is happening
| pretty rapidly, in my experience, with an also entirely
| expected long tail of merchants that will probably hold on to
| their legacy POSes as long as technically possible.
| Scoundreller wrote:
| Are gift cards not a thing in Poland? How do they work?
|
| I have McDonald's gift cards in Canada, and I use the swipe for
| that.
| j_jochem wrote:
| All of the gift cards I've seen in the EU used barcodes, not
| mag stripes.
| gambiting wrote:
| They just have a chip like any other card? I bought a
| mastercard gift card some time ago and it just came with a
| pin. In fact I think gift cards don't even have a swipe part
| at all, and my own visa/mastercard cards still have it but I
| have it disabled through my online bank account - so I assume
| any magstrip transaction for those cards would be just
| rejected entirely.
| lights0123 wrote:
| They're talking about store-specific gift cards, not
| generic visa/Mastercard cards.
| [deleted]
| amluto wrote:
| Credit card security is comically poor. Off the top of my head:
|
| 1. An NFC-enabled EMV card will happily reveal its entire account
| number and expiration date over NFC with no authentication
| whatsoever. I don't know whether the CVV comes along, but I
| wouldn't be surprised if it did.
|
| 2. (As mentioned in the article) issuers accept transactions from
| EMV (chip)-capable readers that nominally originate from EMV-
| capable cards without requiring the chip to be used. So what's
| the point of the chip? (Note that this allows a card to be cloned
| without even touching the card - see #1.)
|
| 3. The information leaked in #1 is enough to buy things online
| (as long as the CVV2 can be found or guessed). Wtf?
|
| 4. For some reason I can't fathom (presumably just laziness), if
| your card number is stolen, the chip stops working until a
| replacement shows up.
|
| 5. Fancy merchants can arrange a subscription that survives a
| lost card or even a fraud report _against that merchant_. But
| these subscriptions can't be seen or cancelled on the cardholder
| website or even by customer service.
|
| But somehow all this comes with fairly stringent PCI
| requirements, which supposedly represent best practices, despite
| the entire system design being a case study on worst practices.
| isoprophlex wrote:
| > [...] found a global pattern that allows me to accurately
| predict American Express card numbers by knowing a full card
| number, even if already reported lost or stolen.
|
| > This means if I were to obtain your Amex card and you called
| it in as lost or stolen, the moment you get a new card, I know
| your new credit card number.
|
| Criminally hilarious.
| iancarroll wrote:
| Amex is already legally responsible for fraudulent charges on
| your card, so if they want to make the numbers predictable,
| why not?
| amluto wrote:
| > Criminally hilarious.
|
| ISTM it's only criminally hilarious if you catch Amex doing
| something fraudulent or illegal themselves. But it sure would
| be entertaining to have a big civil lawsuit on the basis of
| incompetent security practices.
| Scoundreller wrote:
| I suspect this has already been exploited in South America
| with at least one North American banks' Amex cards. Can't get
| into too much detail, but the pieces fit.
| lxgr wrote:
| > An NFC-enabled EMV card will happily reveal its entire
| account number and expiration date over NFC with no
| authentication whatsoever.
|
| EMV was enabled with the intention of replacing magnetic stripe
| payments quickly. Together with 3DS on the online payment side,
| this would have effectively made a card number by itself
| worthless. Unfortunately this hasn't happend (except for mobile
| wallets using tokenization like Apple and Google Pay), but
| given that (at the time entirely reasonable!) assumption, I'd
| cut the original designers some slack.
|
| Another reason: How would you even implement authentication?
| There are millions of terminals out there, operated by at least
| hundreds of different service providers. What key would you use
| for authentication and how would you hide it in a way that
| wouldn't eventually be leaked from legitimate terminals?
|
| > issuers accept transactions from EMV (chip)-capable readers
| that nominally originate from EMV-capable cards without
| requiring the chip to be
|
| Some issuers do, some don't. That's not the protocol's fault.
|
| > 3. The information leaked in #1 is enough to buy things
| online (as long as the CVV2 can be found or guessed). Wtf?
|
| At merchants not using 3DS, that is true - but these merchants
| also bear the full liability for any fraud happening. In the
| end, it's a prototypical security vs. usability/conversion
| tradeoff, in the same way that US credit cards don't have PINs,
| while almost every other market does.
| amluto wrote:
| > I'd cut the original designers some slack.
|
| I'm willing to cut the original designers some slack. I'm not
| really willing to cut the industry slack for not fixing it.
| It's been years. Heck, EMV had been widely deployed in Europe
| for years before it showed up in the US.
|
| > Another reason: How would you even implement
| authentication? There are millions of terminals out there,
| operated by at least hundreds of different service providers.
| What key would you use for authentication and how would you
| hide it in a way that wouldn't eventually be leaked from
| legitimate terminals?
|
| There's no need. Just have the chip have an entirely
| different account number that only works for EMV
| transactions. This wouldn't even need updates to existing
| card readers.
|
| > Some issuers do, some don't. That's not the protocol's
| fault.
|
| This is the payment card industry, which has an entire tome
| of moderately onerous requirements that everyone must follow.
| Surely there could be a new requirement for issuers to verify
| that the transaction is authenticated properly.
| Scoundreller wrote:
| > 2. (As mentioned in the article) issuers accept transactions
| from EMV (chip)-capable readers that nominally originate from
| EMV-capable cards without requiring the chip to be used. So
| what's the point of the chip? (Note that this allows a card to
| be cloned without even touching the card - see #1.)
|
| I would think the issuer could refuse the transaction higher up
| in the process, but it's faster and fewer packets going back
| and forth if the POS terminal could reject the swipe up-front
| and tell you to insert the chip.
| amluto wrote:
| That's like saying you think a server can reject a wrong
| password on the backend, but it's faster and fewer packets
| going back and forth if the client JavaScript just verified
| the password before sending POST. This is nuts. At least
| there's nothing fundamentally wrong with a card reader _also_
| rejecting the transaction.
|
| (It's also _not_ fewer packets. Although it does require the
| backend to know whether the card reader can read a chip, and
| I don't know whether the reader reports this as part of the
| transaction. OTOH there are rather severe penalties assessed
| on merchants with non-chip-capable readers, so something up
| the stack has at least some idea.)
| techsupporter wrote:
| > That's like saying you think a server can reject a wrong
| password on the backend, but it's faster and fewer packets
| going back and forth if the client JavaScript just verified
| the password before sending POST. This is nuts.
|
| I don't think it is nuts. The terminal doing the rejection
| accounts for the "oops the customer did something wrong"
| case of swiping the card when the issuer wants them to use
| chip. It's better to tell the customer this now than run an
| entire transaction.
|
| But checking on the far end that the transaction meets all
| of the issuers rule accounts for the fraud case of "someone
| has maliciously rewritten the magnetic stripe data to try
| to go around the requirement to insert the card." Since,
| hopefully, this happens far less often than the first case,
| it is an acceptable path.
| lxgr wrote:
| A better comparison would be the client JavaScript
| rejecting a four-character password, because it knows the
| backend policy requires at least eight.
|
| Done right (without e.g. checking for "key down" events to
| thwart password managers...), this could could actually
| improve security somehwat by avoiding whatever the user
| entered (maybe a low-entropy PIN?) hitting the network or
| backend, besides providing for a faster error response and
| thereby nicer UX.
|
| > It's also not fewer packets
|
| It avoids an entire round trip to the issuer's backend and
| back, which are often still somewhat expensive and slow,
| given the legacy systems and connections involved.
| amluto wrote:
| > It avoids an entire round trip to the issuer's backend
| and back, which are often still somewhat expensive and
| slow, given the legacy systems and connections involved.
|
| Not if done both client-side and server-side.
|
| Right now, if I swipe my magnetic stripe, then terminal
| will reject it if the stripe has the magic bit set. If
| the magic bit is clear, the terminal will (eventually,
| but usually while the customer waits) send a message to
| the network saying that the card was present and asking
| for authorization. The network responds. No additional
| round trip would be needed for the network to deny
| authorization if the chip was not used.
| gambiting wrote:
| >>3. The information leaked in #1 is enough to buy things
| online (as long as the CVV2 can be found or guessed). Wtf?
|
| At least in EU you can't do that anymore - all online
| transactions are required to implement 3D secure so you have to
| confirm the transaction some other way in addition to your card
| details.
| ComputerGuru wrote:
| It's a legal requirement for EU vendors but the cards
| themselves (or at least some of them) can still be used
| without 3DSecure.
| lxgr wrote:
| No, issuers need to enforce 3DS as well (for payments
| within the EEA), unless there is an applicable exemption.
| grishka wrote:
| > 2. (As mentioned in the article) issuers accept transactions
| from EMV (chip)-capable readers that nominally originate from
| EMV-capable cards without requiring the chip to be used.
|
| Last time I tried swiping my card -- and that was ages ago --
| the terminal displayed something to the effect of "this card
| has a chip, please insert the chip".
|
| > 3. The information leaked in #1 is enough to buy things
| online (as long as the CVV2 can be found or guessed). Wtf?
|
| 3DSecure is a thing and its job is to prevent this exact
| situation.
|
| So credit card security is comically poor, but _only in the
| US_. You were somehow still using the magstripe until recently
| and probably still do sometimes at places that didn 't upgrade
| their readers in time.
| iudqnolq wrote:
| > Last time I tried swiping my card -- and that was ages ago
| -- the terminal displayed something to the effect of "this
| card has a chip, please insert the chip".
|
| I think it's configurable depending on merchant risk
| tolerance. I've seen cases where the terminal lets you swipe
| after three failed chip reads, for example.
___________________________________________________________________
(page generated 2022-12-03 23:00 UTC)