The Target, Neiman Marcus and the potential other breaches of retailers to come should be a learning moment for all of us to demand that the card brands change their business paradigm to one that is more secure.
Bolt-Ons Do Not Cut It
For all intents and purposes, how a credit card works has not changed since the late 1950s when they were introduced. Yes, there have been advancements such as EMV, 3D Secure and end-to end encryption (E2EE), but those are all things that just bolt onto the original concept. The trouble is that, given today’s technologies and their capabilities, the card and the bolt-ons are just no longer providing the security they once did.
With the Target breach there has been a call to get the US to finally convert to EMV. The trouble is that EMV would have leaked enough information for fraud to be committed as well, so it is not an answer.
Trade association spokespeople trotted out 3D Secure and other methods of securing online transactions. The trouble is that most merchants eschew 3D Secure and its kind. In addition, there are known vulnerabilities with these supposedly secure payment methods so they also have potential issues that could be exploited.
Then there is E2EE also known as point-to-point encryption (P2PE) from a PCI perspective. These also can be exploited. It may be more difficult, but when you are determined to gain access to sensitive information, that does not matter.
After the release of the PCI DSS in 2008, a lot of retailers implemented a variety of E2EE solutions. Unfortunately, the endpoint at the retail location was the POS register and not the terminal. This was not due to merchants’ negligence; this was due to how their POS applications operated. This allowed for attacks such as that used in the Target breach to succeed. All the attacker has to do is insert their malware into the POS process so that the malware can “see” the cardholder data before it gets encrypted.
Even in solutions that do E2EE/P2PE to the terminal can be defeated by taking the same approach and inserting the malware into the terminal process before the terminal can encrypt the data. Worse yet, if the terminal is breached, the attacker can capture PINs if they also have malware that captures the keystrokes on the terminal before the PIN is encrypted. There are a number of methods to minimize these risks at the terminal, but if the terminal supply chain is compromised as it was over a year ago in the Barnes & Noble breach, there is little a merchant can do to stop such attacks.
The bottom line is that all of these solutions are bolt-ons to the existing card paradigm and all still have risks that a breach could occur.
Using Complexity Against Us
Brian Krebs and others have wondered aloud how a sophisticated organization such as Target that has information security and forensic resources second possibly only to the government could have been compromised. Particularly after the 2007 compromise by Albert Gonzales when Target totally revamped and increased their security posture to minimize the likelihood of another event.
The first clue to me came when I read the iSIGHT PARTNERS report on the Target breach. The theme that comes through loud and clear is that the attackers are using the complexity of Target’s technology infrastructure against Target. I mean how could FTP activity and huge data transfers (internal and external) go so unnoticed?
Actually, that was likely fairly easy. The attackers used existing network traffic to mask their own network traffic. They sought out servers that already had large volumes of traffic and put their data collection server on one of those servers that already had a lot of traffic. Better yet, a server that was already running as an FTP server. As a result, even with diligent monitoring, the increase in traffic likely did not raise any alarms.
People assume that such breaches are like a “snatch and grab” in the real world. The attackers break into an organization’s network, quickly take what they can off of the computers they encounter and leave. That was the modus operandi (MO) in the past, but not today. Sophisticated and organized attackers such as those that breached Target, do what they can to remain unseen while they learn more about their victim. They take their time mapping out the network and determining what devices they want to compromise to further their efforts to gain access to the sensitive information they seek. Because of this, it is highly likely that the Target attackers encountered the Target customer database during their investigation of the Target network and took it first so that they would have at least something for all of their efforts.
The most insidious thing I think the attackers did was that they likely used Target’s software distribution system to disseminate their malware. Given the number of POS systems compromised (around 51,000); I find it hard to believe that the attackers manually installed their malware on those POS systems. It would have placed their operation at extreme risk likely resulting in its discovery. By using Target’s software distribution system, the attackers got an added benefit of legitimacy to their malware because they Target themselves did the installation. As such, the malware would appear as valid because Target’s software management system initiated the change.
Now What?
All of this brings up an interesting conundrum. If attackers are stepping up their game and using such techniques, how do we detect them? It is a very good question with no good answers. The iSIGHT report offers methods to stop and eradicate this particular attack. However, the next attack and the attack after that will all likely use different malware and different techniques to get the data out of your network.
We are in is a war of escalation with no end in sight. Merchants step up their efforts to stop such attacks and the attackers adapt and adopt new techniques to breach organizations and gain access to their sensitive information. What we need is a solution that stops the escalation and gets us out of this vicious circle.
That is why I am pushing the 15 – 16 character single use transaction code as that solution. My reasons are as follows.
- The algorithms already exist as a number of the card brands experimented with them a decade or more ago.
- It will work with existing POS technology and applications.
- It will work with existing eCommerce sites.
- It can be implemented into eWallet applications.
- It can be processed, stored and transmitted without encryption.
- It can be generated by PCs, smartphones, tablets, credit card sized devices and any other devices that have computational capabilities.
- It can be displayed on devices in a character format for manual entry or as one or 2D bar codes for scanning.
- It can be transmitted via swipe, EMV, near field communication (NFC), Wi-Fi or even Bluetooth.
- And best of all, it is secure by the very nature that it can only be used once.
There will be some changes that would be required at the transaction processors and acquiring banks to handle such a solution. But given that some of the card brands already have experience with this solution, there is a body of knowledge that already exists as to how it needs to be implemented.
Let the discussion begin on how we move ahead with a better, more secure solution.
PCI Guru 
I think the ultimate solution falls within the realm of a two-prong system of verification; the first prong being the retail purchase, the second the processor verification. The first prong will require the customer to use their existing credit/debit cards and PINs at the retail merchant (whether brick-and-mortar or online) to authorize the merchant approval to process funds. Much like a Net30 account, the verification holds the card-holder liable for payment, and the business is invoiced the amount, only the card-holder processor issues a payment, but in a “pending deposit” state (like some banks do with personal checks). Then the customer has to log into their bank account and authorize the finalization of the payment within say 72 hours. Failure to do so will result in automatic approval from the customer (a default to prevent merchants complaining too much, but so that consumers aren’t having to swamp their bank’s websites every other day to authorize what could be a lot of transactions). The customer/consumer can always decline a transaction if fraud or theft is a concern, or flag it as suspicious for review (in cases where the merchant description doesn’t match what the customer expects [this happens to me when I purchase from a franchise with multiple brands; my Taco Bell purchase comes out as “Plucky Holdings Inc.” which is the franchisee for the Taco Bell]). This allows customers to feel better about their purchasing, increases the awareness of purchases and fraud, and provides a high level of protection for the merchant and customer (plus could be implemented immediately). There’s always the risk of the customer not approving a transaction to fraud the merchant, which would then require the merchant to either take the hit or press legal charges. I’m not saying this is the final or best solution, but it would create a human element which would be far more difficult for attackers to penetrate.
“Actually, that was likely fairly easy. The attackers used existing network traffic to mask their own network traffic. They sought out servers that already had large volumes of traffic and put their data collection server on one of those servers that already had a lot of traffic. Better yet, a server that was already running as an FTP server. As a result, even with diligent monitoring, the increase in traffic likely did not raise any alarms.”
Yes, “easy” as in an FTP server that was allowed access to the Internet to arbitrary destinations. Either some admin or manager took the “easy” route or the security department was oblivious to what traffic was allowed outbound because it was “too hard” to do it. Or they have an abundance of Internet access points, some of which the security group doesn’t even know about? Or everyone took a head-in-the-sand approach to what everyone knew was a bad practice? Or “D. All of the above and more”?
I’ll not comment on whether it truly was a clear-text FTP server because “FTP” is sometimes used generically.
“The most insidious thing I think the attackers did was that they likely used Target’s software distribution system to disseminate their malware.”
Maybe insidious but hardly unique. That was the (alleged) mechanism used against ARAMCO when they had 30,000+ computers wiped out. A single software distribution admin (allegedly) was phished and the disk wiper program was pushed out to all desktops.
Why does that attack work so well? Because software distribution like patching is considered a nuisance rather than a core competency or security risk. It’s typically delegated to help desk or junior admins who are evaluated on getting the job done on time.
How well are YOUR Alteris, SMS, SCCM, etc. distribution systems protected? Do you code-sign your software packages with a well-protected key and do you prohibit software installations that are not signed by your key? Or do you do like many other companies and simply allow “Authenticated Users” read-write access to your \\SoftwareServer\Packages$ share?
The biggest part of our jobs is learning from the mistakes of others before they happen to us. Rationalization, minimization and denial are our biggest enemies.
We do not know the actual specifics of HOW this breach was done. Yes, we know details, but we do not know that the FTP server had direct access to the Internet. There could have been a number of servers involved, not just one. That said, in this day and age, to expect to have an organization without an Internet facing FTP server is like expecting McDonald’s to not have french fries.
I agree that having an FTP server with connections allowed to anywhere is not good. But remember, Target deals with organizations all over Southeast Asia and that those vendors change regularly. I am sure if you go back and look at the change tickets for the FTP server, at some point security got overruled for the sake of business expediency to open up access to that FTP server. Security probably did what they could to minimize the risk, but an opening is an opening. And that is an even larger opening when you look at it from the inside looking out.
In my experience, compromising Alteris, SCOM and the like are not always as easy as one might think. And deploying a non-Microsoft product is problematic at best. However, this adds credence to the assessment that the attackers were sophisticated as they did get a non-Microsoft product deployed.
Having knowledge of Aramco, I can tell you that their security posture has been and was questionable at best. After all, when you can rely on “we will have our government find you and kill you” as your primary security measure, you tend to be a bit lax in other areas. 😉
A single-use transaction code could be disruptive to those who need to do recurring billing or allow a customer to tweak an order after it has been placed (such as in an e-commerce scenario), necessitating a new authorization. But you could use the same idea (a compatible 16-digit token) that is locked down to a specific merchant account (the first one that authorizes against it) and has a reasonable expiration window (configurable in the request, perhaps, or configured on the merchant account). If the token is compromised, the network would know who was compromised right away and the damage would be limited to a single merchant account, which reduces its value to the bad guys. That’s not to say the merchant can run an insecure system, but this would for most merchants dramatically reduce the incentive for bothering to compromise such a system.
Going forward, I have not understood why Visa and MasterCard have not tried to implement a standard checkout flow that’s like PayPal’s Express Checkout. Start on the merchant site, redirect to a Visa page to log in and authorize the transaction, return to the merchant to complete checkout, with the merchant only interacting with a token. I guess they tried to fix this with Verified by Visa but that was poorly implemented (it is basically a phishing attack) and cost more (the merchant didn’t have to pay the fraud, but they also had to pay a higher transaction fee, so it didn’t make sense to use it for most merchants), and you were still flinging the real PAN around (which is the actual problem that needed to be solved). And they sort of do this with V.me, but it’s very limited and doesn’t interface with the network in the usual way, it’s more like Stripe. I guess there is some resistance from the existing gateways like Authorize.net (who don’t want to become unnecessary and like the status quo) and lack of incentive for the banks (since most card-not-present fraud seems to be charged back to the merchant).
As someone who has done a work on a lot of e-commerce stores, I love to use the tokenization services provided by the gateways like Braintree or Authorize.net because I’d rather let someone else store the toxic waste that is the PAN for the long term. But they’re all inconsistent interfaces, and the merchant still has to get the PAN to the gateway for that initial tokenization. There have been clever tricks around this to avoid the PAN from flowing through the merchant’s servers (Stripe using JavaScript, Braintree using a silent post-redirect), but a standard solution like PayPal Express Checkout provided by the card networks would (1) provide a standard consumer interface and (2) entirely eliminate the problem of the merchant having to ask for the PAN in the first place. Until the card networks do this, this is the best that merchants can do to solve the problem, and it’s a pain and it’s not ideal.
So my ideal scenario would include (1) a way for merchants to obtain a token by redirecting through a card-network-hosted checkout flow that’s like PayPal Express Checkout and (2) a way for consumers to obtain a token by pressing a button on their card or logging into their bank Web site/app in their browser/phone, and those tokens would be locked to the first merchant account that authorized against it. #1 is the ideal way forward, and #2 solves the backwards compatibility problem. With those two things in place there is no need for anyone to know the real PAN, and no reason for it to be embossed on the card.
The only reason PayPal doesn’t dominate traditional credit cards in e-commerce today, I think, despite having solved this exact problem years ago, is that they have made a lot of missteps in customer service and developer satisfaction, and haven’t positioned themselves to be any better than the credit cards (because fraud is still usually passed through). The banks need to tell their card networks to fill in that gap and provide a uniform, secure interface into the network for merchants to use. At some point asking every merchant on the planet in an ever-connected world to keep a number that’s embossed in plastic a secret forever is simply absurd, and the ever-exacting standards of the PCI DSS speak to that — instead of fixing the problem, the banks simply made it a merchant problem. Talk about blaming the victim.
Great comments.
Tokenzation could still be done with my scheme. The transaction processor would generate a token just as they do today and send it back to the merchant.
The problem is with the merchant having access to the sensitive authentication data (SAD) when the payment process is started. With eCommerce, I can redirect the customer to a processor’s payment process and isolate the merchant from coming into contact with the SAD. , but that doesn’t work in a brick and mortar store with a card terminal. The reason redirects are not popular with online merchants is due to abandoned carts occurring when the customer sees that the payment process does not appear integrated. Some merchants solve this by using an iFrame. But we have seen issues with how some processors implement their iFrame that makes it relatively easy to cause an attacker’s iFrame to be used instead.
There are solutions that tokenize the PAN at the terminal. But the flaw there is that if the terminal is compromised and the attacker inserts malware between the customer’s card and the tokenization process, the attacker has access to the SAD just as the Target attackers did. While compromising the terminal is not an easy task, it can be done and can be rolled out on a massive scale within a large merchant by a centralized terminal update process.
I agreed with you right up to the end, where you espoused the use of ‘single use transaction codes’. Absolutely they are better than static card numbers, and yes, their use can be more easily integrated with EXISTING infrastructure, but I can only ever see them as one step closer to where we need to be. Payments are not about the transfer of payment data, it’s about authentication of the individual wishing to access funds. The funds are in the back end, so should the transaction be, the up-FRONT aspect is all about trust. Numbers up-front, even one-time use will fall by the wayside when common sense catches up with innovation.
I agree with your thoughts. As you point out it’s a step in the right direction. Security is a journey, not the means to an end. As with all schemes created by humans, they have flaws that ultimately become exposed. I’m just trying to get us there one step at a time.