Attacks/Breaches
7/23/2014
12:00 PM
Brian Riley
Brian Riley
Commentary
50%
50%

RAM Scraper Malware: Why PCI DSS Can't Fix Retail

There is a gaping hole in the pre-eminent industry security standard aimed at protecting customers, credit card and personal data

Target, Neiman Marcus, Michael’s, and possibly P.F. Chang’s all have one thing in common: They are recent victims of a type of malware called a RAM scraper that infects point of sale (POS) terminals. These data breaches occurred despite some, if not all, of these merchants complying with industry security standards.

In Target’s case, government analysts estimate the total financial impact could reach as high as $12.2 billion. And the fallout continues. Target’s CEO Gregg Steinhafel set a new precedent, marking the first time that the head of a major corporation resigned due to a data breach. Merchants clearly must go beyond merely complying with industry security standards to reduce their risk, especially in relation to POS terminal malware.

Image credit: Jay Reed on Flickr.
Image credit: Jay Reed on Flickr.

Why PCI DSS does not apply
As you undoubtedly know, point of sale (POS) terminals are computers with card readers. Most computers have permanent storage, such as hard drives or flash memory, and temporary storage, such as random access memory (RAM). The security standard that dictates how payment card data is protected is called the Payment Card Industry Data Security Standard (PCI DSS). It requires merchants to encrypt credit card data residing on permanent storage or traversing its publicly accessible networks, but not while being processed in RAM.

Malware known as a "RAM scraper" or "memory parser" exploits this. When someone swipes their credit card, the POS terminal processes the credit card data in RAM unencrypted. If RAM scraper malware resides on the terminal, it simultaneously scans the payment application's portion of RAM looking for card-matching patterns.

RAM scraper malware is not new. Verizon first reported its emergence as a threat in 2009 and use exploded in 2013. What is new is the surprising guidance in the current version of PCI DSS, which took effect January 1, that does not go far enough to address these attacks. The only reference to such malware is this: “...developer training should likewise be updated to address new threats -- for example, memory scraping attacks.”

To be sure, merchants that do not follow PCI DSS are surely more vulnerable to attacks than those who do. But, as we have seen, PCI compliance is not enough. How about US CERT’s solution? Their recommendations essentially boil down to a subset of PCI DSS and consequently won’t help merchants protect against RAM scraper attacks either.

Finding a solution
To start, merchants should ask the two questions of their POS terminal vendors.

  • Does the solution allow software applications to read each other’s memory?
  • Does the solution use open, standard, and approved cryptographic algorithms with an implementation that has been independently validated?

Most POS terminals run Windows, which allows a process to read another’s memory. Linux provides similar mechanisms. RAM scrapers exploit this.

Eventually, credit card data needs to be decrypted to be processed. If you are going to decrypt data on a system that allows unauthorized applications, such as malware, to access that data, then why encrypt the data at all?

Data must, therefore, only be decrypted when in a protected environment. Establishing protected environments in computers, such as POS terminals, requires separation. This simply means using hardware and software to logically partition the physical resources of a computer, such as RAM, ensuring that those partitions remain separate. A type of operating system known as a separation kernel was designed specifically for this.

People that build high-assurance and high-reliability systems know better than to allow applications to peek at each other’s memory unless explicitly designed to do so. That’s why, for example, they don’t use Windows to control the life-critical components of an aircraft. It wasn’t designed to provide the kind of separation that safety- and security-critical systems require.

On the other hand, Windows is known for providing a familiar graphical user interface. From that perspective, it makes sense that vendors created many POS applications for it.

Separation combined with virtualization has been used to separate and protect the processing of sensitive credit card data in one partition while allowing Windows and its existing POS applications to run in a separate partition. Virtualization is a way to run one or more operating systems on a single computer. But virtualization alone does not guarantee security because implementations and methodologies vary -- and some even increase the attack surface of the system, causing systems to be even less secure.

Credit card data should be encrypted the moment the card is swiped. PCI DSS rightly requires the use of "industry-tested and accepted algorithms" for encryption. Why? Attackers may exploit vulnerabilities that may be introduced if those algorithms are implemented poorly. That is why the security industry recommends using implementations that are tested and validated against standards such as National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) 140-2.

Brian Snow, former Technical Director at the National Security Agency, wrote in a 2005 paper, “In the security realm, the one word synopsis is SEPARATION: keeping the bad guys away from the good guys’ stuff!” So, to start securing payment systems, look for solutions that properly separate RAM (operating systems) and data (cryptography).

Brian Riley has 15 years of product development experience in embedded and enterprise systems software and security. He currently helps organizations solve security and mission challenges by promoting and adapting proven products, technologies, and processes, from ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
7/25/2014 | 9:50:07 AM
Re: Why PCI-DSS doesn't address Ram Scraper?
That's a great call to action, @brianriley. Here are two links about how to join the group of participating organizations and also about the companies that already belong.
brianriley
50%
50%
brianriley,
User Rank: Author
7/25/2014 | 9:42:47 AM
Re: correcting POS processing
Credit card data should be protected/encrypted at the earliest point in the transaction, the point of interaction. Moving the encryption to the card itself is yet another way to provide separation, moving some of the processing of the transaction to the card itself. It seems like such an approach would require a greater overall investment to update the infrastructure, since it requires changing more than just the POS terminals.

I agree that EMV is no solution to the RAM scraper problem. They were designed to solve a different problem, card cloning. In that regard, I do think they add value.
brianriley
50%
50%
brianriley,
User Rank: Author
7/25/2014 | 9:40:08 AM
Re: Why PCI-DSS doesn't address Ram Scraper?
In some operating systems, full administrator rights are not required to read memory from other processes. (Windows XP comes to mind.)  On the opposite end of the spectrum, there are ways to build a system to limit users (and administrators) to a subset of the system (or all of the system, depending on the purpose of the system). This may be accomplished through secure partitioning. Separation kernels are well suited for this.

POS terminals do present challenges with respect to physical security. Various levels of tamper detection and protection may be added to the system to reduce risk associated with physical attacks. Skimmers present an interesting challenge that may only be mitigated by implementing security controls outside of the POS terminals, such as video surveillance and monitoring of the physical environment.
brianriley
50%
50%
brianriley,
User Rank: Author
7/25/2014 | 9:34:23 AM
Re: Why PCI-DSS doesn't address Ram Scraper?
The next version of the standard doesn't go into effect until 2017, so obviously nothing will change before then. The most common way to participate in the PCI standards development process is to become a PCI Security Standards Council (SSC) Participating Organization (PO). I am aware of at least one major Participating Organization that is attempting to address the problem of RAM scrapers. (My employer is presently not a Participating Organization).
SgS125
50%
50%
SgS125,
User Rank: Moderator
7/24/2014 | 3:57:35 PM
Re: correcting POS processing
Really well thought out system, but it sounds expensive to the card issuer and somewhat cumbersomne to the consumer, especially if cards are replaced annually.

Perhaps some of the ideas could be brought into chip and pin and make it work?

For now I just use cash.
macker490
50%
50%
macker490,
User Rank: Ninja
7/24/2014 | 8:12:10 AM
correcting POS processing
Fixing the Point of Sale Terminal (POST)

THINK: when you use your card: you are NOT authorizing ONE transaction: you are giving the merchant INDEFINITE UNRESTRICTED access to your account.

if the merchant is hacked the card numbers are then sold on the black market. hackers then prepare bogus cards -- with real customer numbers -- and then send "mules" out to purchase high value items -- that can be resold

it's a rough way to scam cash and the "mules" are most likely to get caught -- not the hackers who compromised the merchants' systems .


The POST will need to be re-designed to accept customer "Smart Cards"

The Customer Smart Card will need an on-board processor, -- with PGP

When the customer presents the card it DOES NOT send the customer's card number to the POST.  Instead, the POST will submit an INVOICE to the customer's card.  On customer approval the customer's card will encrypt the invoice together with authorization for payment to the PCI ( Payment Card Industry Card Service Center ) for processing and forward the cipher text to the POST

Neither the POST nor the merchant's computer can read the authorizing message because it is PGP encrypted for the PCI service.  Therefore the merchant's POST must forward the authorizing message cipher text to the PCI service center.

On approval the PCI Service Center will return an approval note to the POST and an EFT from the customer's account to the merchant's account.

The POST will then print the PAID invoice.  The customer picks up the merchandise and the transaction is complete.

The merchant never knows who the customer was: the merchant never has ANY of the customer's PII data.

Cards are NOT updated.  They are DISPOSABLE and are replaced at least once a year -- when the PGP signatures are set to expire.  Note that PGP signatures can also be REVOKED if the card is lost.

Transactions are Serialized using a Transaction Number ( like a check number ) plus date and time of origination.    This to prevent re-use of transactions.   A transaction authorizes one payment only not a cash flow.

EMV is no solution: and EMV card passes the cardholders account number, name, expiration date, et al
to the POST in plain text -- making the same error that the mag stripe reader makes and which
has been heavilly exploited by criminals.

~~~
Roger Sanders
100%
0%
Roger Sanders,
User Rank: Apprentice
7/23/2014 | 7:15:46 PM
Re: Why PCI-DSS doesn't address Ram Scraper?
Reading memory from other processes requires a program running with full administrator rights. If the bad guys have already obtained that level of access to the POS system, it's game over anyway. By definition, the attackers have gained the ability to perform any operation on that machine. The entire system, and any data passed to it, is compromised, no matter what you do.

That said, I think you're right, the key here is separation, but i think the emphasis needs to be on separation of the POS system from the outside world. Why are POS terminals openly networked, with active internet connections? It's cheaper, easier to develop software for, and easier to administer. It's also incredibly vulnerable to attack. POS systems shouldn't have any means to communicate with each other or the outside world. They should have a single secured and encrypted point of communication with a central server of some kind where required, and other than that, they should be completely isolated.

At the end of the day, if an attacker can engineer a situation where he can gain unsupervised physical access to a POS terminal, he will be able to compromise it. That should be where it stops though. It shouldn't be possible for an infection to spread from one POS system to another, or for data from a compromised POS system to be leaked back over the internet. If attacks were limited to individual terminals, and recovering data required physical access, or additional hardware to be dropped in like a phone, it would greatly increase the difficulty and reduce the payoff for the bad guys, and they'll go back to targetting ATMs or the like where they also need physical access, but the payoff is bigger.

In terms of physical security too, why are POS systems often sitting on an open shelf right next to customers and employees, with exposed USB ports and no real physical isolation? Again, because it's cheaper and easier, but it's very insecure. POS systems should be viewed as filled to the top with cold hard cash, and secured accordingly.

POS systems could learn a lot from ATM security. Any software platform will have vulnerabilities just waiting to be discovered, and where there's a lot of money involved, the bad guys will find them. Network isolation and restricted physical access are key. When was the last time you heard about a network of thousands of ATMs being hacked? That's because they're heavily network isolated. The PCs themselves can be attacked if you can gain physical access, which is why they're supposed to be kept under lock and key in a safe. If the bad guys don't have to get a blowtorch out to compromise your POS system, you're doing it wrong.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
7/23/2014 | 2:50:03 PM
Why PCI-DSS doesn't address Ram Scraper?
Good article, Brian. Wondering if the card industry has given a reason for not tightening their standards to protect against the RAM scraper expoit. Do you see any activity in the future?
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-7178
Published: 2014-11-28
Enalean Tuleap before 7.5.99.6 allows remote attackers to execute arbitrary commands via the User-Agent header, which is provided to the passthru PHP function.

CVE-2014-7850
Published: 2014-11-28
Cross-site scripting (XSS) vulnerability in the Web UI in FreeIPA 4.x before 4.1.2 allows remote attackers to inject arbitrary web script or HTML via vectors related to breadcrumb navigation.

CVE-2014-8423
Published: 2014-11-28
Unspecified vulnerability in the management portal in ARRIS VAP2500 before FW08.41 allows remote attackers to execute arbitrary commands via unknown vectors.

CVE-2014-8424
Published: 2014-11-28
ARRIS VAP2500 before FW08.41 does not properly validate passwords, which allows remote attackers to bypass authentication.

CVE-2014-8425
Published: 2014-11-28
The management portal in ARRIS VAP2500 before FW08.41 allows remote attackers to obtain credentials by reading the configuration files.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?