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

Brian Riley, Technical Director, Government Programs, Green Hills Software

July 23, 2014

4 Min Read
Image credit: Jay Reed on Flickr.

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.

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).

About the Author

Brian Riley

Technical Director, Government Programs, Green Hills Software

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 safeguarding data to ensuring availability of resources. Prior to joining Green Hills Software, Brian developed real-time embedded software at Raytheon for various government and commercial communication systems and sensors. He earned his Bachelor of Science in electrical engineering from the University of Maryland, College Park.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights