It took some doing, but you finally persuaded senior management to invest in an encryption product to protect the...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
company's sensitive data. The file server now automatically encrypts documents and files, database fields containing sensitive data are encrypted, thumb drive access is controlled, and network traffic is encrypted using IPsec. You're sitting pretty, right? Not so fast.
You may have covered the key areas of data at rest and in transit, but what about data in process? That is, while it is decrypted so an application can process or use it. The attack on Heartland Payment Systems Inc. relied on network sniffers that captured card data when it was momentarily unencrypted during the transaction authorization process. All those other protections mentioned above -- to the file server, database and on the network -- made no difference.
One place where data in process is often especially vulnerable is RAM and virtual memory. Attackers can search RAM and virtual memory page files on system servers for sensitive data, particularly passwords or encryption keys that can then be used in other attacks. Encryption software doesn't encrypt data held in RAM, and most programs don't clear the memory area in which they store unencrypted data after they have finished with it. This means that unencrypted data may remain in RAM until the computer is turned off. Because of a process called DRAM remanence, this data may be retrievable for some time even after power to the machine is turned off.
Another type of attack that targets unencrypted data in RAM and virtual memory focuses on a common operating system function. In this tip, we'll examine how to prepare for attackers that can mine valuable information from a memory dump.
Memory dump attacks
In many operating systems, a fatal error in a program automatically triggers a memory dump, a display or output that includes the working memory. The user running the application (and those with administrative privileges) can view this memory dump file. Typically this information is used to diagnose or debug errors in the operating system or computer program.
An attacker who can invoke an abnormal termination of a program or system, perhaps with a buffer-overflow attack, or with a simple request for the system to output a full memory dump, can scan the crash dump files for sensitive data that would normally be encrypted. Tools like the bios_memimage package, which include utilities, such as aeskeyfind or rsakeyfind, will output any encryption keys they find.
As memory dumps are part of an OS's design, it's unlikely that a security update would fix this type of attack. So what can be done?
For starters, whenever a system or application suffers an unexpected crash, investigate not only why it happened, but also whether there are any signs of intrusion attempts, malware such as packet sniffers or keyloggers present, or open ports that should be closed. This involves checking firewall log files, running AV software to search for unauthorized programs and scanning the network with Nmap to look for configuration changes to ports and services.
Have a question for Mike?
- Send in your application and platform security questions to Mike Cobb.
With this type of attack in mind, it is also important to ensure enterprise applications are built to store and process sensitive data. After a sensitive transaction, like user authentication, applications should clear the memory area that contains critical data such as a username and password. On the basis that you can't steal what's not there, the hash value of passwords can be stored instead of the password itself so that it cannot be accessed from memory. Tokenization could be another option, where sensitive data is stored in a separate location and is referenced solely by a unique identifier. Both options would prevent a potential memory dump attack from retrieving valid credentials.
Developers that use the .NET framework can apply features such as Data Protection API and a class called SecureString. SecureStrings are text containers held in encrypted memory, and they are only unencrypted when they are accessed. The strings limit the amount of time that data is in plaintext and the memory that was used to hold an encrypted string is zeroed out when it's disposed of. So even if a memory dump is triggered, the chances are slim that valid data can be retrieved.
Another programming measure to help thwart memory dump attacks is to ensure all communication connections are made thread-safe. In a thread-safe program portion, one thread with permission to open a connection will not store the connection in a global location; otherwise a malicious thread could use the open connection without having that permission explicitly granted to it. Of course, applications should be given only the minimum set of permissions that are needed to enable them to function, and users should only have the minimum permissions to enable them to complete any necessary tasks.
Finally, the physical security of systems storing or using sensitive data must be taken seriously. Cold-boot attacks that utilize data remanence to retrieve memory content and the copying and manipulation of memory using the firewire port can all be prevented if access to the machine is strictly controlled.
Memory dump attacks are not prevalent, but they're constantly getting more sophisticated. Network administrators should understand how they work and how encryption and good physical security together greatly reduce the chances of them succeeding. Application developers should also look at how their code handles sensitive data, decrypting it only when needed and then clearing the memory of any traces post-processing. Your investment in encryption hasn't been wasted, but encryption alone is not a silver bullet.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.