“Borrow” Payment Cards With NFC Proxy Hardware

Contactless payments are growing in popularity. Often the term will bring to mind the ability to pay by holding your phone over a reader, but the system can also use NFC tags embedded in credit cards, ID card, passports, and the like. NFC is a reasonably secure method of validating payments as it employs encryption and the functional distance between client and reader is in the tens of centimeters, and often much less. [Haoqi Shan] and the Unicorn team have reduced the security of the distance component by using a hardware proxy to relay NFC interactions over longer distances.

The talk, give on Sunday at DEF CON, outlined some incredibly simple hardware: an NFC antenna connected to a PN7462AU, an NRF24L01 wireless transceiver, and some power regulation. The exploit works by using a pair of these hardware modules. A master interfaces with the NFC reader, and a slave reads the card. The scenario goes something like this: a victim NFC card is placed near the slave hardware. The master hardware is placed over a payment kiosk as if making a normal payment. As the payment kiosk reader begins the process to read an NFC card, all of the communications between it and the actual card are forwarded over the 24L01 wireless connection.

The demo video during the talk showed a fast-food purchase made on the Apple Pay network while the card was still at a table out in the dining area (resting on the slave hardware module). The card used was a QuickPass contactless payment card from China UnionPay. According to a 2016 press release from the company, over two billion of these cards had been issued at the time. With that kind of adoption rate there is a huge incentive to find and patch any vulnerabilities in the system.

The hardware components in this build aren’t really anything special. We’ve seen these Nordic wireless modules used in numerous projects over they years, and the NXP chip is just NFC build around an ARM core. The leaps that tie this together are the speed-ups to make it work. NFC has tight timing and a delay between the master and slave would invalidate the handshake and subsequent interactions. The Unicorn team found some speedups by ensuring the chip was waking from suspend mode (150 µS) and not a deeper sleep. Furthermore, [Haoqi] mentioned they are only transmitting “I/S/R Block Data” and not the entirety of the interaction to save on time transmitting over the 24L01 wireless link. He didn’t expand on that so if you have details about what those blocks actually consist of please let us know in the comments below.

To the card reader, the emulated payment card is valid and the payment goes through. But one caveat to the system is that [Haoqi] was unable to alter the UID of the emulator — it doesn’t spoof the UID of the payment card being exploited. Current readers don’t check the UID and this could be one possible defense against this exploit. But to be honest, since you need close physical proximity of the master to the reader and the slave to the payment card simultaneously, we don’t see mayhem in the future. It’s more likely that we’ll see hacker cred when someone builds a long-range link that lets you leave your NFC cards at home and take one emulator with you for wireless door access or contactless payments in a single device. If you want to get working on this, check out the talk slides for program flow and some sourcecode hints.

31 thoughts on ““Borrow” Payment Cards With NFC Proxy Hardware

  1. There also used to be a relay attack like this using two NFC enabled android phones, one rooted, one not that worked pretty well. Not sure if the apps/code is still around, haven’t looked for a few years.
    And thanks to android/apple pay, no-one is going to look twice at you paying with a phone. :)

  2. Some one is gonna go by one, follow the RF24 instructions and think their device is broken because the pins are different in python example than the .cpp in the extra folder. Just got mine working this weekend talking to eachother and passing messages. Other than seeing these used for normal relay type and small data transmission, I like the non nefarious example these guys have given.

    1. I don’t agree. Tell me why I have to carry a shielded wallet. That’s like curing the symptoms instead of the illness.
      Contactless is broken by design.
      The only way to make it safer is to make the pin insertion mandatory for every purchase (even though that it will remain still hackable) and thus give an additional confirmation.
      And contactless with pin insertion every time is a paradox since the meaning of this kind of card is to avoid human interaction as much as possible.
      Otherwise, just punch a hole in card and break antenna. Without NFC they need physical access to the card to steal money. Not impossible, but definetly harder.

      From this description, this hack is very similar to the one used to stole keyless cars, where they used just a 2-way amplifier to make the car detect the real key, open the doors and let the engine on.
      You can put all cryptography you know, but when you just increase the active range …

      1. Even when you want to be a bad boy and start stealing small amounts with your portable payment terminal from many people to earn money, you won’t be able to keep that up for long since the terminal is issued on your name. The more people you steal small amounts from, the higher the chance gets someone will actually see the amount on their balance and report it. Considering the penalty the pro’s just don’t weigh up to the cons.

      2. Punching a hole can damage some ATM machines… Whats more, you’ll not know if the card got stuck or stolen…. Off to the bank in a hurry to get the old card canceled.

        Thinking on the lines of burrs and abrasive effects against rotting/soft rubber feed rollers (Usual and most common mechanism) or possibly against a gripping mechanism (The stage that clamps and inserts the card into the chip reader) .

        Then there is those Mag-stripe reader only ATMs:
        The ones that can scare the knowledgeable types into thinking there’s a skimmer attached by reinserting the card several times to read the mag-stripe.
        It takes one catch of said hole on the read head mounting/adjust screws and it’s stuck whereas only the inserting edge would cause a reject in this case.

        Oh, I asked my bank for a NON-RFID card… they still sent out another RFID card and invalidated the old (Only a week old) card.

        Only hope is RFID blockers/scramblers.

        1. or calling your bank and having that form of payment disabled on your account. Give that a try, it worked for me and now all of my cards are chip and pin only, the mag stripe wont work either.

          1. Glad your bank listened to you.

            I tried, they sent another active RFID card, Talking to said bank is a waste of my time when two plates of WiFi RF shielding, a capacitor+rectifier+resonating circuit and two Wireless charging receiver modules sandwiched together in a plastic envelope with both charger circuits coupled together seems to work for now (Tested, contactless stopped working through the wallet.)

            Quicker to construct than possibly asking 20+ times and having the same results with an unusable card for days at a time.

            That is until I order an RFID blocker card case that’ll hopefully fit better in my current wallet I’ve had for about 21 years now (Have the same leather wallet since I was 6 years old).

          2. @ Unferium

            My bank refused too. So I ordered a new card as a replacement, put my old card in the microwave to find the exact path of the antenna traces and then using a sharp knife on the replacement card cut the traces in the right spot. Stuff ’em. I would happily have ordered more cards until I figured it out (I have more than one account).
            That was the old card 3 years ago.
            The new card they recently sent me out actually has the NFC circuit built under the chip. So the traces were even easier to find. Score a line around the chip.
            Using the NFC reader on your phone helps spot if it’s disabled or not.

            And it’s not a case of paranoia on my part. I simply do not wish to use the service. The onus is on me to spot rogue transactions and if I’m not using the tech there is zero chance of a transaction nor me having to check for them every month.
            It’s called security.

      3. I use Android Pay instead of contactless on my card and it does require that I enter the pin or have recently entered the pin every time. It also makes my phone vibrate, has a big splash screen with a picture of a card and whatnot. After that there’s a notification of how much was paid to who when and where. It’s way better than regular contactless for authorisation and knowing when a payment has been made in my opinion so I feel a bit safer using it.

      4. Security has long since moved on from technically 100% sound solutions to monitoring, detecting and deterring.

        No, your mobile bank app isn’t 100% secure, nor are the websites your bank offers. Nor is your credit card, nor are direct-debit solutions. Yes, if you invest some time and take some risk, you’ll be able to steal some money. But either you or your infrastructure will be caught / dismantled.

        Yes, your actions will cost the bank money. They’ll likely have or want to repay the account holder the money you stole and know there’s little chance of recovering that loss. But it’s still less than it would cost to implement 100% security. Not to mention that the customers will move to banks with more hassle-free “security procedures”.

          1. Contact chips have been cloned, and readers have been modified to make larger charges than the screen displays. Not ‘very secure’ by any definition I’d accept. Better than a signature though, I guess.

    1. They also do it in the US as well in fact there are thieves who specialize in stealing cars with passive entry systems since they are so easy to steal and they don’t have to dmage anything on the vehicle.

  3. I,S, and R blocks are just the protocol blocks used in the low level ISO 14443 communication between the reader and the card. I blocks contain commands and data, R blocks either ACK or NAK, and S blocks allow you to negotiate parameters like frame delays and wait times. So I don’t see how “only sending those blocks” saves any time since that’s all that’s ever sent. PIN and chip solves this.

  4. Do they make an RF shielded wallet with an outside pocket that is not shielded?

    I ask because I don’t want to have to take my workplace entrance card out every morning to get into the building.

  5. For those talking about RF blocking wallets, just do yourself a favor and call your bank (or card provider) and have that method of payment blocked. They can easily set your card to Mag-stripe and chip+pin or just chip+pin, or at least set the limits of tap to pay much lower (like 5 bucks or what ever a fancy coffee costs now a days). Tap to pay is nothing more than a convenience play to get you to drop holding cash. It makes things easier for sure, until someone compromises your card and your bank totally disables your card and then comes the inconvenience of rectifying the situation and getting a new card. Ill pass on expanding the attack vectors to get at my money.

  6. I alternate between head-slapping and shouder-shrugging on these hacks. Everything that’s RF based that doesn’t require user interaction is susceptible to relay attacks like this. Even when the user does take action, it can often be jammed and replayed or relayed. That’s just the way life is.

    The question is whether the convenience outweighs the security hole.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.