A top objective of the Payment Card Industry Data Security Standard (PCI DSS) is to mitigate the risk of credit card data compromise via persistent storage (e.g. disk) through controls securing the flow of credit card (CC) data.
However, the standard controls mandated by PCI DSS, like encryption and network segmentation, for instance, are not necessarily sufficient to address the risk from non-persistent storage of card data, such as when data is stored temporarily as files on a disk or in memory. Even organizations that comply diligently and persistently with the 12 requirements of PCI DSS can fall prey to errors in technology, process or people that result in sensitive data landing where it shouldn't. That is not to say PCI DSS or the PA DSS (Payment Application Data Security Standard) does not cover inadvertent storage of unencrypted CC data. It limits itself to log files and troubleshooting (debug) (PCI-DSS – 3.2.1-3 and PA DSS – 1.1.1-3, 1.1.5 and 2.3).
In this tip, we'll outline how one particular type of malware can threaten an enterprise's efforts to protect sensitive card data, and how to prevent such malware from causing a data compromise.
More on PCI DSS
- Learn two key steps that can help assessment success with PCI DSS standards and secure data storage.
- Learn how to change from WEP to WPA for PCI DSS compliance.
- See why the PCI Council calls point-to-point encryption immature.
I am going to take this opportunity to delineate a couple of assumptions to limit the scope of this discussion. The first assumption is that, for this scenario, compliance with PCI DSS can be effective in addressing security around the persistent storage of card data. The second assumption is that the flow of card data is encrypted once it leaves the point-of-sale (POS) system or point of capture. The reason I am making these assumptions is that they allow me to touch upon a relatively recent threat: memory-scraping malware. Memory-scraping malware (for the purpose of this example, as it can have a broader definition) is malware designed to examine memory (potentially through techniques similar to those used in memory forensics) for sensitive processes (e.g., payment applications) and extract data which would otherwise not be available on persistent storage.
We will need to set a context for the existence of this malware sample, and, for that purpose, let us assume the malware has made its way onto a POS system through some attack vector, such as a zero-day vulnerability or an unpatched system, both of which unfortunately are common occurrences in most enterprises. The POS system hosts the payment application, which is the primary mechanism that a retailer with a brick-and-mortar presence uses to process credit card transactions. When a customer's card is swiped at the POS terminal, the card data, which includes the personal account number (PAN) and other related information, is sent to the payment gateway for approval. This data is also sent to the retailer's back-office system on a daily basis for chargebacks, marketing and audit-related purposes.
In its basic form, memory-scraping malware would copy the process memory of the POS application to disk, and then parse the output file for track data (which at this juncture would be unencrypted) while installing itself as a service for persistence. (Just to clarify: Not all memory dumps of the POS application reveal unencrypted track data. There might be cases wherein the memory was dumped after the routines to encrypt PAN data have been called, making the memory unreadable.) Trustwave published a report recently in which it documented future iterations of this malware (.pdf) as it developed antiforensic techniques, making detection and source-tracing analysis difficult, cleaning up remnants of any temporary files it created and also encrypting all track data that it extracted on disk. Perhaps the most distressing aspect of this malware is that this data-leakage scenario could have occurred even if the POS application were compliant with the Payment Application Data Security Standard (PA-DSS).
Ironically, this malware's characteristics actually mimic those of a forensic investigation of system memory, except instead of identifying malware in memory, the sample attempts to image and analyze card data. The Trustwave paper mentioned above hints that the malware is using open source memory-imaging tools to initiate the data theft. There are a number of tools that facilitate the acquisition of memory and most of them are freely available. Some mainstream examples of these tools include: win32dd/win64dd, FastDump, FTK Imager, Winen, Kntdd, Memoryze and F-Response.
Enterprises should use host-based (IPS, content integrity checkers, antivirus products) and network-based (IDS/IPS, network device logs) monitoring tools, if available, to identify suspicious activity like that described above, and upon discovery of likely memory scraping, analyze the memory images of affected systems. This analysis requires that one understand the operating system and the data structures that the operating system uses to manage memory on the running system. Luckily, Volatile Systems has done the heavy lifting on this by providing the Volatility Framework, which provides ready-to-use plugins to extract useful information from memory. The framework is written in Python and is a completely open command-line tool.
This very same approach employed by memory scraping malware can also be used to analyze malware in memory. The process of analyzing and extracting malware from memory (memory forensics) has been gaining a lot of momentum of late. Memory forensics can be especially useful in situations where malware authors use a combination of encryption and anti-debugging mechanisms to thwart traditional forensic and malware investigation techniques.
Though PCI DSS or PA DSS do not explicitly address sensitive information in memory, they do address controls which could help protect against malware. Following host hardening guidelines, enforcing network perimeter security, proactively patching the system and using an antivirus product with intrusion prevention capabilities (IPS) will go a long way to help mitigate the risk of malware making its way onto the system in the first place.
But this is only one part of the solution. What happens if malware still manages to make its way onto the system undetected? Memory forensics tools like those listed above can help analyze the malware in memory, which could aid in identification and eventual removal, but there is a period of time -- however short it may be -- where the malware exists on the system undetected. During this time it is safe to assume the malware could have unrestricted access to the system's resources, including memory. At this point, an organization should assume unauthorized data exfiltration has occurred, and it should deploy its data breach response plans accordingly.
PA DSS in its current form does not explicitly address protecting sensitive information in memory, though it does address it for data at rest. One concept that may be effective as a mitigation tactic is that of key-encryption keys; these can be used to encrypt the key in memory, and then split it up and spread it throughout memory to make it difficult to reconstitute. This is similar to the concept of encrypting encryption keys on disk, which is used to render sensitive data unreadable.
This tactic could be taken a step further by developing bogus key data structures to throw malware scrapers off. A bogus key is created to attract malware scrapers, but the key is zeroed out as soon as the calls to crypto functions are completed. Enforcing key rotation similar to that which is enforced for data at rest could make it even more difficult for malware to scrape the memory. Implementing such a technique would definitely add to the complexity of developing and maintaining the payment application, but the advantages are many, given the nature of the current threat landscape. Extending the PCI DSS requirements to address these scenarios would be a step in the right direction.
About the author:
Anand Sastry is a Senior Security Architect at Savvis Inc. Before joining Savvis, he worked for clients in several industries (large and mid-sized enterprises in financial, healthcare, retail and media) as a member of the security services group for a Big 4 consulting firm. He has experience in network and application penetration testing, security architecture design, wireless security, incident response and security engineering. He is currently involved with network and web application firewalls, network intrusion detection systems, malware analysis and distributed denial of service systems.