15
May
11

Doctored Credit Card Terminals

It was announced this week that the Michaels retail stores breach was much larger than originally thought.  However, to those of us in the PCI business, this breach should not have been a surprise.  This sort of breach has been going on for quite a while.

Now before everyone goes out and pillories Michaels for their bad luck, I would like all of you to consider how you would have detected such a situation?  The bottom line is that for most of you, you would have been just as clueless until the FBI and Secret Service turned up at your doors.  So be careful about getting too sanctimonious.  More on how to detect these attacks later.

Regardless of what the PCI SSC has said in the past, credit card terminals are not the “dumb” devices as portrayed by the PCI SSC.  With the introduction of the PA-DSS v2.0, there was an indication that the PCI SSC had finally come to their senses and recognized this fact by having the software that is used in credit card terminals finally certified under the PA-DSS standard.  Let us face it, certain credit card terminals are just as sophisticated as netbooks, use a Linux or Windows Embedded OS as a base and have their own software development kits (SDK).  Not exactly the specification for a “dumb” device.

Another point that should not have been a shock is the fact that the terminal was used as the attack vector.  Those people advocating end-to-end encryption fail to remind people that wherever the endpoints are will become the new attack points.  As a result, the Michaels attacks will become a very popular attack vector once end-to-end is implemented.

Wait a minute, the terminal will become more popular for attacks?  After all of last year’s belly who about end-to-end encryption, I can tell you that merchants are under the impression that end-to-end encryption gets them out of being breached.  It is people like Bob Carr, CEO of Heartland Payment Systems, that are the biggest neglectors of explaining the whole story behind end-to-end encryption.  End-to-end encryption just moves the attack points, in this case out to the terminal at the merchant’s location.  Worse yet, it also makes security of the merchant’s endpoint even more difficult than it already is because the techniques used in doctoring terminals can easily go unnoticed.

Early attacks on terminals were crude and, for the most part, remain this way.  Typically, USB thumb drives are soldered into the terminals.  This attack approach requires the criminals to swap out the doctored devices periodically to obtain their contraband.  Fortunately the “electricians” used to doctor these terminals are usually not good at their tasks.  As a result, only a few of the doctored terminals actually work and collect usable track data.  To get their doctored terminals into retail locations, the criminals hire on as night custodians or other overnight stock help and swap the devices during that time.

But times change.  The criminal element gets smarter and begins doctoring terminals using software, not hardware.  After all, these devices are just small computers.  So now the device is programmed to collect the data and then transmit it during the overnight to a server on the Internet or, worse yet, a server that has been compromised on your own network.

So what can a merchant do to counteract such attacks?  Actually, quite a bit.

  • Put serialized security tape on all of the seam openings on your card terminals and check it at least daily to ensure that it is still in place and that the serial numbers match.  When the tape becomes worn, replace it and record the new serial numbers.  If you ever notice the tape missing or the serial numbers do not match, take that terminal out of service.  Contact your acquiring bank or processor and obtain a terminal directly from them to replace the potentially tampered with unit.
  • Use only reliable card terminal vendors.  I know that merchants are under tremendous cost pressures, but are these savings really in your best interest when you are leaking cardholder data on every transaction?  Probably not, particularly when customers start complaining and your legal costs start ramping up.  However, even trusted vendors can become a bad source of equipment, so keep this in mind.
  • Do not trust anyone that just shows up to replace your card terminals.  If you did not ask for service, no acquiring bank or processor is going to be proactive replace terminals unless they notified you.  Be very skeptical of any service person that appears out of nowhere to “fix” your terminals.
  • If your terminals are on your network, monitor your terminals for when they are disconnected.  In most organizations, terminals are rarely disconnected, so any such alert would be an indication that something abnormal has occurred and should be investigated.
  • Monitor your external network connections and connections from the terminals to devices that should not be in your cardholder data environment (CDE).  Any traffic from the terminals outside your network or to devices not in your CDE is probably someone leaking cardholder data from your terminals for their criminal use.  If you see such activity, notify your local FBI office immediately and ask them if you should stop the traffic.  At this point, you should also probably get a computer forensic analyst involved to begin gathering documentation on the attack.

These are just some ideas on how to address this situation.  You may have additional options available to you because of the way your organization is configured.  However, you need to begin considering this new attack vector as one that will only get worse.

About these ads

8 Responses to “Doctored Credit Card Terminals”


  1. 1 MB
    July 19, 2011 at 7:44 PM

    End to end encryption still hugely reduces the surface area of an attack to a point where there is a) more potential physical management in the merchant to counter skimming and deception b) less data to siphon over the course of the data’s life cycle. In addition, this post doesn’t acknowledge the huge changes between devices in retail reaching their end of life which are more likely to be tampered with (eg pre PCI PTS 1.0 devices) and more contemporary PCI PTS 3.0, SRED etc requirements.

    In any scheme – no matter what – where data in the clear needs to be presented to an interface for translation to a secure protocol or system, there is risk of exposure or manipulation at that interface. The question is how big is the risk and what is the cost benefit for the attacker ? In the Michael’s case, how many cards are at risk now – in the thousands. Contrast that to prior attacks at a processor or network layer – tens of thousands to million of cards at risk. Quite a big difference and different attack costs and risks.

    The PCI SSC has created anti-skimming guidance, and most contemporary devices have more intense tamper detection methods and active defenses (destruction of keys for example in an SCD boundary inside the payment device) to help maximize the cost barrier to a successful attack, and to potentially render intercepted devices impossible to use – and thus detectable.

    It will always be possible – at a given cost and risk profile – to replace a physical device with something that skims irrespective of scheme – imposters, fake devices and all manner of elaborate scams are the way of the sophisticated criminal past and future if the investment is sufficient for the return. The challenge is to make is so expensive and unattractive with the risk of being caught much higher as a defensive strategy until in the much longer term the payment schemes themselves evolve to more dynamic and scam resistant methods.

    In the meantime end to end encryption – especially that implemented in a secure tamper detection enabled device which is outside the scope of the OS and logical compromise – will be a very effective way to reduce the risk of compromise in no uncertain terms.

    Is there an alternative ? No.

    Disclaimer: I work for an encryption company – but what I describe above isn’t specific to a vendor.

    • July 20, 2011 at 5:15 AM

      I agree with your comments. The problem I see is that E2EE proponents do not discuss the fact that there is still a risk. Ask any merchant about E2EE and they think they are totally off the hook and that just is not true. There is still a risk that needs to be mitigated by procedures to ensure that their end of the chain is secure and remains secure. However, given the propensity of attackers to find new ways to get at the data, I am sure that we will be shown even more ingenious ways to take E2EE down and we’ll start all over again on a new scheme to secure our data.

      • 3 JJ
        July 20, 2011 at 6:35 AM

        Here it is. Our area had a large number of fraudulent card transactions in the past few months. They initially were pinned on a local restaurant, but there seemed to be too many. It did not pass a smell test. At a local group we have where people from different organizations meet to discuss fraud they’re seeing, the law enforcement rep said the focus has moved from the restaurant itself to their point-of-sale software. Yes, you read that correctly. They believe the PoS software may have been tampered with at the vendor before it was shipped to their customers. (No, they would not release the name of the software.)

        It’s similar to the process of infecting thousands of websites with malicious code. You either do it one web server at a time or you infect the common point, their banner ad provider. You want to grab a ton of numbers? Compromise the PoS software before it’s shipped.

        PA-DSS? They’re not storing anything they shouldn’t. File Integrity Monitoring? No problem. We install the new software, baseline it as OK and it’s still malicious. Ant-virus? Useless for custom software. End-to-end encryption? Bzzzt, wrong answer. Next contestant, please.

        If this turns out to be accurate, the focus will move to how the software companies protect their source code. Do they off-shore or outsource any of their work? Do they use independent contractors working out of their homes? Lowest cost wins again.

        This whole process is like squeezing a balloon. As soon as we squeeze off an attack vector one place, it blows up in another. TSA puts in body scanners that won’t penetrate the skin, so the terrorists think about putting explosives in bodies surgically. Poof. More millions of dollars in ineffective, reactive controls gone up in smoke.

      • July 20, 2011 at 7:29 AM

        There is a move afoot to address this potential problem. However, the method to be used will drive the cost of software significantly upward. The process involves using two different development teams given the same requirements and then test each solution to see if they both work the same. This is the process certain “three letter agencies” in the US government use to develop their software.

        PA-DSS was developed to ensure that software was developed to secure cardholder data, not to ensure that the software didn’t send it to Timbuktu at the same time it was sending it to the processor. This is the same for all of the PCI standards or any standards. There is an assumption will all standards that individuals of good character will obey the accepted norms of society and do their jobs. Unfortunately, there are individuals that do not want to follow the rules and it is those that we need to weed out of software development and other sensitive positions, if we can.

  2. 5 Alex
    May 18, 2011 at 8:13 AM

    The terminal should be secure. The whole point of buying a terminal from a reputable supplier is that the terminal is practically immune to tampering. Skimming card data is hard to fight, but PIN compromise within the terminal, if that happened, is unforgivable. Maybe Michaels did not have PCI compliant terminals like they should, in which case unfortunately liability lies with them. If the terminals were PCI compliant, there is almost certainly a liability question for the terminal vendor. Also, if the terminal is at fault then Michaels is likely only the tip of the iceberg if the same terminal is being used elsewhere with other retailers, and therefore with the same vulnerability

    • May 20, 2011 at 3:40 PM

      I have not heard that there were any PINs compromised and, really, who would need the PIN? Once you have the track data from either a credit/debit card, they can all be cloned and used as a credit card.

  3. 7 JJ
    May 15, 2011 at 6:31 PM

    Is this a natural consequence of the switch to self-checkout lines to save paying minimum wage to teenagers? The criminals observe that the discount stores have less staffing to reduce costs and that leaves the payment terminals without the physical protection of a cash register operator?

    I do wonder just how they pick the stores, though. Only one in my state was reported as compromised despite there being many stores within twenty miles of each other. Or is the compromise happening at the repair centers and it’s just the luck of the draw?

    • May 16, 2011 at 4:18 AM

      In the Michaels case, the terminals may have been doctored at a central point such as a repair facility or central supplier which is why you see the broad distribution. In a number of other cases I am aware, the terminals were located in a cluster around the criminal gang that was doctoring the terminals. And it is not like the terminals are not locked down and secured with video. However, when you have everything keyed the same and the switching is done by someone working the overnight crew, it really does not matter.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

May 2011
M T W T F S S
« Apr   Jun »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 926 other followers


Follow

Get every new post delivered to your Inbox.

Join 926 other followers

%d bloggers like this: