32C3: Shopshifting — Breaking Credit Card Payment Systems

Credit card payment systems touch all of our lives, and because of this there’s a lot riding on the security of that technology. The best security research looks into a widely deployed system and finds the problems before the bad guys do. The most entertaining security presentations end up finding face-palmingly bad practices and having a good laugh along the way. The only way to top that off is with live demos. [Karsten Nohl], [Fabian Bräunlein], and [dexter] gave a talk on the security of credit-card payment systems at the 32nd annual Chaos Communications Congress (32C3) that covers all the bases.

While credit card systems themselves have been quite well-scrutinized, the many vendor payment networks that connect the individual terminals haven’t. The end result of this research is that it is possible to steal credit card PINs and remotely refund credits to different cards — even for purchases that have never been made. Of course, the researchers demonstrate stealing money from themselves, but the proof of concept is solid. How they broke two separate payment systems is part hardware hacking, part looking-stuff-up-on-the-Internet, and part just being plain inquisitive.

The first hack fools someone into entering their credit card PIN into a terminal, and then logging it to a PC. With the stripe data and the PIN, the credit card is totally compromised. Normally, you shouldn’t be able to change this part of the terminal’s behavior, but they manage to figure out the terminal’s secret password that enables creating arbitrary menus, and the game is over.

This was possible because the terminal checks the validity of the password byte by byte. You could therefore look for times that the CPU took a couple more cycles to respond and determine that  you had a correct byte. Iterate this eight times, and the eight-byte password is cracked.

The second hack is even more embarrassing. Armed with a password that [Fabian] found in a leaked document on the Internet, a terminal’s ID number (printed on every receipt), and a brute-forceable port address, they could initiate random purchases and refunds remotely.

shopshifting_hardwareFinally, and this is our favorite part, [dexter] goes through how he defeated the supposedly-secure hardware security machine (HSM) that holds the “secret” passwords on every card reader machine out there. The clever design stores the password in SRAM with a battery backup, and makes it very difficult to open the box without disconnecting the power, causing the bits to fade away.

After breaking a couple machines to see how they work, [deter] figured out just the right place to wedge a grounded needle under the shield and the secrets weren’t so secret anymore.

Is there a lesson in all this? Don’t store passwords on devices that you’re giving out to hundreds of thousands of stores. Someone will buy a couple on eBay and get those passwords. Using asymmetric encryption, like with public-key cryptography schemes, would mean that the secret key wouldn’t need to reside on the device at all, and would have thwarted our presenters fairly early on.

19 thoughts on “32C3: Shopshifting — Breaking Credit Card Payment Systems

  1. I think the talk is about DEBIT card not CREDIT card. Major difference.

    And I don’t know if those hacks are possible with modern terminals. The group uses the ARTEMA HYBIRD which is known for it’s security flaws since 2012. And therefore recommended not to use by the industry.

    1. The same terminal is used for debit as well as credit cards. So it just doesn’t matter whether it is the PIN of a debit or a credit card that is being recorded. Also, while all MAESTRO cards are debit cards, there are VISA and MasterCards that are NOT credit cards but issued as debit cards. Also keep in mind that most banks allow for a certain amount of overdraft – which (in Germany) can be as high as 2.5 monthly salaries. Any debit card linked to such a bank account can be used within this credit line. So in Europe in practice (from the consumers’ point of view) there is in fact no difference between debit and credit cards at all. Its just that some cards (like MasterCard, VISA, Amex etc.) are not accepted at all in some stores. But if they were, the shop would not have to buy separate processing terminals for these.

    2. Yes. In some countries, DEBIT cards are not seen everywhere. That’s why the sentence “random purchases and refunds remotely” bogged me. Refunds on a card ? Guess it’s possible with a debit card.

      1. Refunds are possible with both credit and debit cards. Whether businesses and/or specific banks permit this for their cards is another question. It has however nothing to do with credit vs. debit card.

    3. Watch the talk, they did not break a specific implementation via bugs, but all flaws were located in the protocols themselves and the backend setup. This will work on every terminal implementing these protocols.
      The only thing specific to this model is the HSM hack, which was just for fun and was not needed for the attacks at all.

  2. Really interesting video and talk. I’m not sure on the protocols used in the UK, but it seems many of these traditional protocols which typically used serial and modem links a decade ago are just being reimplemented over ip without much thought. I’d point out that it may not be simple to switch off refund capabilities, afaik to keep to terms if a shop refunds a customer, normally is has to be done to the same payment method. This avoids a possible cash advance situation where a customer buys a product on credit card and then has cash refunded.

    1. The Payment Card Industry (PCI) security rules are getting a lot tighter over time, specifically in regards to:
      – protection of the Hardware Security Module
      – intense scrutiny of TCP/IP stacks
      – assorted measures to kill off default factory passwords (e.g. forcibly assigning unique passwords, or forcing the user to set a new password)
      – a burning hatred for Bluetooth Low Energy v4.1 or lower (how many devices have you connected to with the ‘secret’ password “0000”?)
      – usable JTAG connections are discouraged

      1. – protection of the Hardware Security Module
        and
        – usable JTAG connections are discouraged

        are band-aids to try to hide the contained secrets from hackers, and _will_ fail eventually. The JTAG port was _inside_ the HSM in the demoed devices, and was thus “secure”. Removing the connectors from the board won’t stop someone from scraping traces and soldering wires anyway, but will be a PITA for manufacture. This is all obscurity more than security.

        Moving the secrets out of the POS terminals via asymmetric / public key encryption is a real solution. The ability to update / revoke the keys is probably not a bad idea either.

        As you mention, though, unique passwords per terminal would be huge.

        1. Current certification standards for payment terminals that accept PINs (PCI-PTS) have strict hardware design requirements and testing when it comes to the “HSM” (or better termed a secure processor).
          The terminal under test in this talk is not a currently certified device so would not be permitted in a PCI certified environment (with the caveat of a bad PCI QSA letting it go through).
          https://www.pcisecuritystandards.org/documents/PCI_PTS_POI_VQ_v4-1a_Sept_2015.pdf

          Modern designs contain a security processor (HSM) that has physical and logical tamper detection; secure key storage, hardware based cryptographic engines and side-channel analysis protections designed in.
          e.g https://www.maximintegrated.com/en/products/digital/microcontrollers/MAX32590.html

          The HSM in current (certified) devices do not have JTAG or debug ports enabled or accessible. Most manufacturers (Maxim, Broadcom etc.) of payment terminal HSMs fuse off the JTAG capability of the HSM modules that are put into devices (debug capability is only available on specific development chips that are not placed into end-user devices.

          The primary issues here are to do with bad implementation in the german system that was developed prior to good standardisation of security in the industry (PCI, SEPA etc.). Unfortunately this is common in many national banking systems due to the cost of upgrading these ‘baked in’ systems.

          Modern POS terminals already have support for public key cryptography schemes, the ability to (securely) wipe or update keys and encrypt card-holder data as well as PIN data; it’s just that the banks systems need to be upgraded to support all these features.
          Regards,
          Peter

  3. I don’t think that any hacking is necessary with these devices. Just a few button press on the pinpad and the transaction gets faked. Most banks fail to switch off this test feature in the configuration/firmware.
    Also there is a 3 button combination on the pinpad where you can cancel the (last) already processed transaction (refund) without any receipt printed. But this needs to have the card inside the terminal to work. (basically, enter the pin, wait for the transaction to complete, press this 3 button combo, wait ~5 sec, profit)

    Source: one of my friend worked as an installer.

  4. In 2013 the business I was working for got a new credit card reader from a major bank. However it arrived late we ended up switching to an iPad based system (Which had its own problems, but they were different ones). When I was re-boxing the bank’s credit card reader I saw a sticker on the bottom that proudly proclaimed “Secured with 3DES.” I was, needless to say, not impressed.

    1. @Nick,

      3DES in modern terminals isn’t the problem. In order to break DES, it takes around 2^49 rounds. In order to break 3DES, it takes 2^112 rounds, and requires about 1.6 billion terabytes of storage. The PIN pads are using a protocol called DUKPT, which generates a unique 3DES key for each encryption, making it hard to test 2^1 keys, let alone 2^112 of them. The internal counter is required to disable the terminal and erase the keys after 1 million encryptions. And the DUKPT key injection process injects a unique key into each terminal, meaning no terminal ever directly has the Base Derivation Key (aka the Super-Secret Key) injected at any point in its lifecycle.

      There’s a much older PIN pad protocol called Master/Session, which stored the global master key in each PIN pad. It was garbage 15 years ago, but I understand it’s still supported in some ignorant corners of commerce.

      No, it’s much easier to defeat the hardware and abuse the machine directly than it is to defeat this 3DES implementation.

  5. Nothing that interesting. If you can get in on the LAN where the POS and all the POSi are you can do malicious ROM updates on the POSi machines or scrape transactions which is what most POS scraper malware does using just a single NT API call and regex.

    A lot of the time there are RF attack vectors on these store networks via embedded inventory scanners. These devices are on the same subnet as the POS and POSi and have no traffic isolation. At most a IDS with weak signatures. Otherwise you have to get in to locked offices or back-rooms under survalliance to get in on the network physically. There is also remote phishing attacks that can get in through main office VPN.

Leave a Reply to Peter FillmoreCancel 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.