When Will The PCI SSC And Card Brands Stop The Mobile Payment Insanity?

This week PayPal introduced Here, their mobile payment processing application for Apple iOS and Android devices.  The good news is that PayPal Here at least appears to encrypt cardholder data, but that appears to be the extent of the good news.

If you pay attention to the latest Suzie’s Lemonade Verizon Wireless advertisement, you will see Intuit’s GoPayment solution on a tablet computer processing a payment.  In another bit of good news, the Intuit GoPayment solution is also encrypted.

But what is most disconcerting is that this is just another in a string of mobile payment processing solutions to be introduced with no way of knowing whether or not the security claims are accurate or can even be trusted.  This is because the PCI Security Standards Council halted last year the certification of any of these mobile payment processing solutions through the PIN Transaction Security (PTS) and Payment Application Data Security Standard (PA-DSS).  Do not get me wrong, the Council was in a tough spot and did not have a plan as to how to deal with these solutions, so the called a halt while they went back and reassessed things.

However the marketplace is not waiting.  So while the marketplace continues to deliver solutions, the merchant is left to their own devices to know whether any of these mobile payment processing solutions can be trusted.  And what I am fearful of is that small merchants, who are the marketing target of these solutions, will be put out of business should the device somehow be compromised or they lose a device.

So what are the questions surrounding the PayPal Here?

First, what is the encryption algorithm that is used?  I am guessing that they are using DUKPT, as that is common with these sorts of devices, but it is something that should be explicitly identified in their FAQ.  What PayPal currently says is, “… the PayPal Here card reader is encrypted and is backed by over a dozen years of experience of providing buyers and sellers the highest levels of security.”  If they are using DUKPT, can the key be changed?  Most of the mobile solutions I have seen do not allow for the key change under DUKPT which could be a problem.

Then there is the fact that you can manually enter a cardholder’s information through the iOS/Android application.  Given the fact that these systems are notorious for having keyboard loggers of industrial strength that means that any manual input will be recorded in the device.  I am guessing that would include cardholder name, PAN and expiration date.  However, if PayPal Here collects the CVV/CVC/CID value in manual entry that would be an extremely bad thing as the device will retain that until it overwrites it months later.  Again, there is no documentation to determine what is allowed to be manually entered, so we cannot assess how much risk this might introduce.

But the scariest feature of the PayPal Here is unrelated to credit cards; it is the remote capture of checks.  PayPal Here allows the merchant to scan a check and then submit it to their financial institution.  Again, given the data retention of these devices, I can only guess that the check images processed through the PayPal Here application will remain on the device until the space is needed which could be months.  The problem with all of this is that if people think credit card security was questionable, check processing security is nonexistent.  As a result, anyone with a modicum of knowledge could use the check information on one of these devices to drain every bank account stored.

Let us hope that the PCI Security Standards Council and the card brands quickly get back to certifying these applications so that merchants are not using insecure payment solutions.

Advertisement

A Carrot for Chip and PIN

On August 9, 2011, Visa USA announced an interesting program to give merchants a carrot to drive them to adopt dual-interface chip technology terminals that will accept EMV (aka Chip and PIN) as well as mobile payments using near field communication (NFC) also known as contactless cards and devices that can transmit card information via NFC.

The carrot Visa USA is offering merchants is a waiver on annual PCI compliance if merchants implement dual-interface chip technology terminals.  The criteria merchants must meet in order to obtain the waiver is:

• At least 75% of the merchant’s transactions must originate from dual interface EMV chip-enabled terminals;

• The merchant validated their compliance with the PCI DSS within the last 12 months with the merchant’s acquiring bank or the merchant filed a defined remediation plan with the merchant’s acquiring bank;
• The merchant must have confirmed that they do not store sensitive information (i.e., track data, PIN, CVV) after completion of any transaction; and
• Not involved in a breach situation.

The first requirement certainly drives the swap out of old terminals.  However, until banks start issuing the EMV and/or contactless cards in bulk, the investment by merchants in the dual-interface chip technology terminals is not going to happen.  What I am sure Visa USA is hoping is to get a large merchant like Wal-Mart, Best Buy or Target to buy into the program and therefore drive the issuers and banks to get on board.  Without a big box merchant, this program is pretty much dead on arrival.

The next two points are pretty much the same thing.  In order to be compliant with the PCI DSS, a merchant must prove that it is not storing sensitive credit card information.  The only reason I can see for the third point is, I am sure, to cover the “defined remediation plan” of the second point in the event that the gap found was related to storage of sensitive information.

The fourth and final point just makes complete sense.  If a merchant has been breached, they must have shown that they are PCI compliant before being allowed to be waived from a PCI assessment.

Is it a good idea to waive the annual PCI assessment for merchants all in the name of getting them to adopt a new technology? Particularly technologies that do not entirely solve the fraud issue with credit cards.  Yes, you heard me right.  EMV and contactless technologies do not entirely solve the fraud problem.  While they minimize fraud in the case of card present transactions, they do not even address fraud in card not present transactions.  And it is in card not present transactions where fraud is most prevalent.

So why the push for EMV and contactless cards?  That is a good question.  The proponents of EMV will tell you it is to curb fraudulent purchases.  However according the latest information I could find, while EMV is expected to drop card present fraud by 35% this year in Canada (the first full year they have EMV); card not present fraud is continuing to go up.  Based on statistics from a variety of sources, card not present fraud ranges anywhere from 40% to more than 60% of the total card fraud committed.

So, if EMV and contactless do little or nothing for the majority of fraud being committed, why the push for them?  That is a really good question.  And to tell you the truth, I have no idea why Visa USA is pushing this other than to make things consistent worldwide.  And from a standpoint of curtailing card present fraud, at less than 5% in 2009 (the last year statistics are available); there is certainly no ROI for EMV.  This is why EMV has not been rolled out in the US.  There is no payback if banks and merchants invest in EMV.

But then you have contactless cards.  Contactless cards rely on near field communications (NFC).  NFC is made possible by radio frequency identification (RFID).  Like the magnetic stripe, the RFID in a contactless card only has the PIN block encrypted.  Numerous proofs of concept attacks have been documented against these contactless cards.  The bad news for cardholders is that unlike EMV and regular credit cards, a contactless card can be skimmed without their knowledge or even suspicion.  The only way the consumer knows their contactless card has been skimmed is when they get their statement and see the fraudulent charges.

But the really stupid thing about EMV and contactless cards is that until every merchant has the ability to process them, they will continue to have to have a magnetic stripe.  This is particularly true for automated teller machines (ATM).  Even in Europe where EMV is the only type of card available, ATMs still require a magnetic stripe.  This would hold true for the US as well since even the major banks cannot afford to change out the card readers in all of their ATMs to support EMV and contactless.  As a result, any transition to these new cards will be a very long time coming.

That is not to say that EMV or even contactless could not take a significant bite out of card not present fraud.  While the hardware for the cards exists for PCs, the problem is that such a solution would require a standard application program interface (API) which the card brands, banks, payment processors and merchants have done nothing to create.  Over the years there have been a number solutions proposed by banks and card brands, but nothing that was adopted by everyone.  As a result, instead of fixing the problem, everyone just accepts it.

The bottom line appears to be that Visa USA is pushing high technology as a solution for card present fraud that just does not address the real problem.  However, I guess it is better to appear like you are doing something rather than not doing anything.

Relevant reading:

Chip And PIN

The Chip And PIN Debate – Part 1

 PCI SSC Nixes PA-DSS Certification For Mobile Payments Applications For A While

The Chip And PIN Debate – Part 3

In my last post I discussed the statistics surrounding the adoption of Chip and PIN.  In this post I want to go back and discuss the issues from my old post regarding security risks regarding Chip and PIN.

In my original post I discussed a number of shortcomings regarding EMV.  A lot of those issues were taken from old sources as well as some that were questionable.  I apologize for the misleading information in some cases.  However, the reason I included a number of these old issues was that they still can be an issue to the EMV card as not every financial institution has necessarily converted their entire card base to newer EMV standards.  I know this to be true because one of my clients manufactures EMV cards and they continue to produce cards to older standards.

EMV, like any other security method, is not perfect.  So what are the viable issues?  Here is my take on the security issues for EMV.

Man-In-The-Middle Attack
At the IEEE conference in February 2010 a number of researchers from the University of Cambridge presented a paper on a man-in-the-middle attack where they used somewhat expensive equipment to build hardware and software that essentially intercepted the communications between the EMV card and the terminal to fool both into believing that a transaction has been properly completed.  After this paper was presented there was a flurry of newspaper articles about the problem hyping it as the reason why EMV is a “false prophet.”  A few days later, a number of articles came out dismissing the research as bunk because of the expense and complexity of the equipment.

However, the flaw that these researchers found is more exploitable than most people think.  Terminals are more sophisticated that most people give them credit.  Today’s terminals are not the “dumb” devices of yesteryear.  Today’s terminals are like netbooks in disguise and run embedded Linux or Windows.  Vendors provide software development kits with these new generation terminals for the development of sophisticated solutions for processing credit cards, giving loyalty rewards and other merchant friendly purposes.  And after four years, it appears that the PCI SSC has recognized the threat from these new terminals and is modifying the PA-DSS to include them in the certification process.

I have personally been involved with a client that had their terminals tampered with by a gang to store cardholder data on USB drives embedded in the terminals.  These terminals were swapped for legitimate terminals by gang members posing as the night cleaning or the stock crew.  Then there is the Hannaford breach.  While we know that it was malware installed on the POS servers at each store, there has never been an official explanation given as to how the malware got on those servers.  Most people just assumed that the hackers somehow compromised Hannaford’s network and placed it on all of their servers.  But the rumor I heard was that the Hannaford breach was the result of tampering with their master ghost image for their POS server.  Hannaford had updated their POS hardware and software as part of their PCI remediation efforts (how is that for a real piece of irony) and had hired a third party to provide the additional resources necessary to ghost the new servers.

The bottom line is that there is ample evidence that data gathering at the source is a real threat.  Given the sophistication of terminals these days and the likelihood that they and POS software can readily be tampered with, the ability for a successful man-in-the-middle attack is higher than most people believe or want to believe.  As a result, it is not too farfetched that tampered with terminals or POS software could be created and distributed to unsuspecting merchants by unwitting or unscrupulous vendors and/or resellers.

Card Cloning
In May 2010, Lloyds-TSB admitted that a number of their customers had been the victims of card cloning.  Apparently, this is not your run-of-the-mill amateur cloning operation, as these cloners are cloning everything and determining the cards’ PIN.

It is not difficult to skim the magnetic stripe on an EMV card as most of them have a stripe so that they can be used in non-EMV situations.  Now a lot of you are probably wondering how the bad guys got the cards’ PINs.  It is just a simple use of a rainbow table to break the encrypted PIN block.  The problem with the current PIN block encryption specification is that it is published.  And though you might think that PIN encryption would be tough to beat, banks usually only change their private keys annually so if you have a card from a target bank, you can figure out the private key by using the information from a known card.  As a result, it is not difficult to generate the necessary rainbow table(s) to quickly crack PIN blocks.

Once cloned, the cards are used at ATMs around the world to obtain the victims cash.  Why ATMs?  Turns out that almost all ATMs, even those in Europe, still rely on a card’s magnetic stripe to conduct withdrawals not the chip.  To add insult to injury, it turns out that Lloyds-TSB’s and most other banks’ fraud detection systems ignore ATM withdrawals.  And because ATM transactions from foreign ATMs took anywhere from a week to a month to show up on customers’ statements, it usually was quite a while before the customer contacted the bank to dispute the transactions.

So until EMV is the configuration all over the world, the magnetic stripe is the weak link in the chain.

Card Theft

This is still a problem even with EMV.  The bad guys have taken a tip from the long distance telephone scammers of the late 1980s playbook.  It was that brief time before today’s truly portable cell phones and people relied on long distance calling cards.  I can personally remember at Newark Airport, the terminal had scammers shoulder surfing people as they made calls writing down the calling card numbers as they keyed them into the phones.

What today’s EMV scammer does is electronically shoulder surf at ATMs and merchants and then lifts the victims’ wallet or purse.  They then quickly conduct as many fraudulent transactions as possible before the victim can notify their bank of the stolen card.

Granted, this is not a great way to make a living, but properly done, one can make a living.  With the new PCI PTS standard, even electronic shoulder surfing the PIN should be more difficult, but not necessarily impossible.  And with the prevalence of video monitoring everywhere these days, the chance of obtaining footage containing recordings of people entering their PINs is even greater.  So your new targets of hackers may be the DVRs that contain that footage.

Reverse Engineering Attack

This attack is a prime example of why some things should never be published on the Internet for everyone to see.

This is an attack that is developed by a person using their own credit cards as testing devices.  Even in today’s economy, banks issue credit cards to almost anyone that applies as long as their credit score is good.  Therefore it is not impossible to believe that someone would use their existing credit cards to reverse engineer keys.

First and foremost, all of the documentation is available on-line for anyone to see so the attacker has a readily available instruction manual for reverse engineering the standards.  All of the hardware and software development kits are readily available and in some cases can be obtained for little or no cost from vendors or through eBay.  If you think this is farfetched, remember that at this year’s Black Hat a guy explained how he learned to hack ATMs by buying them through eBay and other sources.  As I discussed earlier, what makes these attacks possible is that the private keys the banks use in their encryption do not change very often.  At most they change once per year, possibly even less than that.  As a result, anyone that desires can use off-the-shelf software to monitor the network and capture the traffic when the card authenticates.  From that traffic, the private key can be determined and then any card from a particular bank can then be easily cloned.

I am sure there are other attack vectors waiting to be discovered by some ingenious attacker.  I only wish I had the free time to look into this topic further, but that is for the attackers who have such free time.  But this is not to say that EMV would not bring something to the security table.  However, the bottom line is that there are risks with EMV and it is not the panacea that its proponents like to portray.  It has known and unknown flaws just like any other piece of technology.  So, let us all admit that fact and move forward.

UPDATE:  Here are some more links to other information regarding issues with Chip and PIN and explanations of the above threats.

http://blog.itsecurityexpert.co.uk/2010/02/chip-pin-weakness-smoke-screen-for-real.html

http://blogs.techrepublic.com.com/security/?p=3153

Extremely Mobile Payment Processing

In a previous post I discussed mobile computing and PCI compliance.  In the last couple of weeks I have been questioned about using mobile devices such as smartphones and Wi-Fi enabled PDAs as payment terminals and I thought this particular incarnation of mobile computing deserved an in-depth look.

Pay attention to that Apple iPhone advertisement.  If you notice in one of their advertisements they show a person processing a credit card payment on their iPhone.  As Apple likes to say, “There’s an app for that.”  However, it is not just Apple that has a payment application for a mobile device; there are also payment processing applications for Windows Mobile environments.  There are also proprietary solutions from VeriFone and the like.  Some of these applications are PABP and/or PA-DSS certified.  Devices from VeriFone and the like are PCI PTS certified, but the iPhone and other cellular phones as well as PDAs are not PCI PTS certified devices.

So when the pizza delivery person shows up at your door and wants to swipe your credit card through their mobile device, how do you know that it is safe?  You likely will not know.

The security surrounding the telecommunications used by these devices is the easiest thing to discuss.  All of the devices I have been able to examine use telecommunications methods that are encrypted either by SSL v3 or TLS.  The cellular network and Wi-Fi are just used as the conduit and are not relied upon to provide any security.

Do not assume that VeriFone and the like are meeting all of the PCI standards.  While their mobile payment terminals are PCI PTS certified, the application software in those devices is not PA-DSS certified.  I pointed to the flaws in these devices in a previous post.

But there are bigger problems lurking with the iPhone.  Ask any computer forensic examiner about the iPhone and they will talk at length about the fact that the iPhone has a number of “features” that make security and privacy things of the past.  From a PCI compliance perspective, some of the more problematic issues are as follows.

• Deleted information does not physically get deleted.  In some cases, deleted data can remain on an iPhone for up to six months or even more depending on use.
• The iPhone has a built-in keyboard logger, so anything typed into it is recorded.
• While it is not certain that card swipes would be retained on the iPhone, given all of the other information it retains, it is highly likely that such information would also be retained.

As a result, using the iPhone as a payment processing platform is probably not a good idea until it is certified.

So what, if anything, are the PCI SSC and/or the card brands doing about this situation?  As much as they can, given that these solutions are popping up faster than they can identify them.  The problem is that the developers of these applications are usually unaware that they are required to comply with various PCI standards.  And since the developer is responsible for certifying their solution unless they get ‘ratted out’, the solution will not get certified.  So it is up to the application developer and the merchants to ensure that an application is properly certified.  If that is not worrisome enough, the cost involved in certifying such an application would likely raise the cost of that solution to a point where it would not be economical to the merchant or salesperson.

The Threat Landscape Has Changed

In an earlier post, I discussed how the PCI DSS changes based on changes in the threat landscape.  Attention, Robert Carr at Heartland Payment Systems and anyone else processing, storing or transmitting cardholder data, here is a change in the threat landscape that will radically affect the PCI security standards, most definitely the PA-DSS, but also the PCI DSS.

Verizon Business Services recently announced that they are seeing a rise in RAM scraping attacks.  RAM scraping is an attack that utilizes a program to go through the memory of a device looking for certain information.  RAM scraping has been around for quite a while, but only recently was this technique adapted for finding cardholder data.  With the push for end-to-end encryption, Verizon Business Services predicts that RAM scraping attacks will continue to rise.

Now if you are Robert Carr, you are likely questioning how RAM scraping attacks can gain access to cardholder data when end-to-end encryption has been implemented.  After all, you have been told that end-to-end encryption is the answer to protecting cardholder data.  Yes, once the data is encrypted, as long as strong keys and proper key management practices have been implemented and are followed, the data is protected.  However, the data is not protected at the end points where the data is encrypted and decrypted.  It is at these endpoints where RAM scraping targets end-to-end encryption.

At some point, the data must be in a format that can be processed and that is what the people that develop these RAM scrapers rely on.  But the cardholder data is only in memory for such a short time, possibly only a millisecond.  Do not be so sure.  Unfortunately, with the advent of high-level languages and cheap memory, memory management is not as well managed as you might think.  We have seen instances of cardholder data being stored in the memory of card terminals and PCs for hours, days and in some very rare cases, forever.  As a result, if you can gain access to the memory of these devices, you can hit the mother-lode in cardholder data.

Now before you go off in a panic, the PCI DSS does have some protections that are already provided.

• Requirement 1 – Firewalls.  There are a number of requirements in this section regarding the regular review of firewall rules, control of network traffic and other topics.  However, the purpose of these requirements is to respond to the changing threat environment.  In addition, firewalls generate alerts and log data, so these should be regularly reviewed to make sure that a RAM scraper has not been introduced into the environment.
• Requirement 3.5 – Encryption Key Management.  As long as you follow the recommendations in this set of requirements, your encryption keys should be safe.
• Requirement 5 – Anti-Virus.  Most of these RAM scrapers are installed through some sort of attack that uses virus and/or malware techniques.  If your anti-virus is up to date and it protects against malware, you will likely be notified of such an instance.  The attack is likely not going to be direct, so you need to make sure that all systems that interact with your cardholder data environment need to be monitored to ensure that a RAM scraping payload is not delivered anywhere in your network.  The key is monitoring.  If you are not actively monitoring attacks, you will likely miss the introduction of the RAM scraper.
• Requirement 10 – Log Analysis.  If you are properly reviewing your logs, the alerts from your anti-virus and critical file monitoring should be contained in your log data.  The key is that you are conducting log reviews at least daily, if not more often.  If you have a centralized log collection system, I would recommend that you create queries that use criteria to meet various PCI DSS requirements.
• Requirement 11.5 – Critical File Monitoring.  RAM scrapers are executable files.  If you have configured your critical file monitoring correctly, this new executable will trigger an alert.  However, not all end points can be monitored this way, so you may have to find another approach to protect those devices.  Again, monitoring is the key.

If you are religiously following these points, you should be addressing this new threat as best as you can.

As I have constantly stated, security is not perfect.  So, just because you are following the PCI DSS does not mean that you will not have an incident.  It only means that the impact of an incident will be minimized.

Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

• The PANs can only be displayed one at a time.
• You have to be in administration mode to view the PANs.
• The PANs cannot be printed out.
• The PANs are stored in memory, not on a hard drive.
• The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.”

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.