It’s a Thursday evening, and happy hour begins in a few minutes. You’re ready to get out of the office, as quickly as possible. You’ve been working on a report, and you know you still have work to do in the morning. So you lock your machine. It’s safe enough, right? You’ve got a strong password and full disk encryption. Ophcrack or a bootable Linux distro like Kali won’t work. You’d think you’d be fine, but you’d be wrong. More and more, attackers are using blended attacks to get the good stuff, and that includes utilizing the latest in forensic techniques.
There is a single section of your computer full of unencrypted sensitive information any attacker would love to get their hands on: your active memory. The system stores all manner of valuable information in memory for easy reference. Full disk encryption mechanisms must store encryption keys within memory somewhere. The same is true for Wi-Fi encryption keys. Windows keeps the registry hives in memory, and consequently the System and SAM hives. Most clipboards are stored within memory. Many applications keep passwords within memory. The point is, memory houses much of the valuable information that the system needs at a moment’s notice. Getting to it requires using some of the same forensics techniques employed by attackers. This article helps add some of those techniques to your pentesting toolkit.
Setting the Stage
An entire profile of the system can be built simply from the memory dump. In recent years, the value of memory captures has been noticed by forensic specialists but has been largely ignored by penetration testers. There are a number of reasons for this. Forensic investigators use specialty software to capture memory, and it’s usually done while logged into the device. They use these captures to look for malware or hidden processes. A penetration tester would be more interested in stored hashes, files, and running processes. They most likely would not need a memory dump to get this information if they already had access to the system.
There are a few scenarios, however, where memory captures could be of great use to pen testers. Consider the following scenario: On an internal engagement, a tester is given access to machines on a walk-around of the facility. The client is confident that the tester will not be able to use these machines to gain any access to the system. The machines use full disk encryption, defeating the ability to boot into Ophcrack and download hashes. Any machines that are on are also locked. Little does the client know, however, that the tester is experienced with a few techniques that can be used to grab the contents of the active memory of the system. There are two techniques in particular that could be used in this situation: the Cold Boot Attack and the Firewire Attack.
Cold Boot Attacks
In early 2008, researchers from Princeton University, the Electronic Frontier Foundation, and Wind River Systems released a paper entitled Lest We Remember: Cold Boot Attacks on Encryption Keys which detailed a new kind of attack on live systems to recover information stored in memory. This attack is based around the principle of data remnants. Popular belief holds that data in memory (RAM) is immediately lost once a machine is powered off – flick the power switch, and everything is gone in an instant.
However, the researchers showed that this is not entirely true. In fact, it takes time for the data to clear itself from memory. Cutting power from a machine for only a second or two actually leaves most of the data intact. The effect can be lengthened by cooling the memory, which the researchers did using an old party trick – a can of compressed air held upside down. Chilling the memory can allow data to persist for many seconds, even minutes. This enabled the researchers to develop a series of tools which could extract information from memory in a machine that was rapidly powered off, and then on again.
The chance of experiencing small errors in a memory capture using this method is relatively high, which is why it’s been largely dismissed by the forensic community. However, a penetration tester does not require a forensic image of the memory. Even a 2% corruption of the memory would be acceptable if encryption keys or the SAM database are intact. This makes it a valid, albeit difficult, attack vector for internal penetration tests.
The Lest We Remember team created a number of tools for use in the attack which can be downloaded from the Princeton site at https://citp.princeton.edu/research/memory/code/. The main tool is the USB/PXE Imaging tool which can be downloaded as a tarball. The research team created a number of makefiles to make compilation easier, and they also included a good bit of documentation within the tarballs. The 32-bit extractor should be compiled on a 32-bit VM or machine, while the 64-bit likewise should be compiled on a 64-bit VM or machine. Remember to use the correct extractor on the target machine – while the 32-bit extractor will work on a 64-bit machine, it will not capture the full memory space, as a 32-bit extractor will not be able to address the full 64-bit memory range.
The result of the makefile compilation is a file named scraper.bin. This is the actual bootable imaging tool that can be copied to a USB drive. Because the USB drive will also be used to store the memory image, it’s recommended that the drive be large, at least 16GB given that most current systems contain between 4 and 8 GB of memory. Use the dd tool as root to copy the scraper to the USB drive, where sdb is the location of the drive:
sudo dd if=scraper.bin of=/dev/sdb
At this point, the USB drive is prepped and ready for a target. Ideally, a pen tester will carry both a 32-bit 8GB stick and a 64-bit 16GB stick into an internal engagement to be prepared for any target as well as a can of compressed air. The target machine should be a system that is on and locked. It does not matter if a user is logged into the machine or not. The target should also have full disk encryption – otherwise booting to Kali or Ophcrack would get superior results with less work.
Once a suitable target has been located, the pen tester (with the appropriate authorization from the client) should open up the case to expose the RAM. They should also plug in the USB drive. Once everything has been prepared, the pen tester can freeze the RAM by holding the can of compresses air upside down and spraying it over the RAM. Since this will result in frost on the chips, care should be taken to only hose down the RAM and not other sections of the motherboard. Figure 1 displays laptop RAM that has been chilled in preparation for the attack.
Figure 1: Chilled RAM for a Cold Boot Attack
Once the RAM has been sufficiently chilled, the pen tester needs to cut the power, and restore it as quickly as possible. On desktop machines, this is relatively simple and can be accomplished by hitting the reset switch. However, since most laptops do not have reset buttons, performing a quick reset is substantially more difficult. The best method is to quickly remove and replace the battery and then hit the power button. In both cases, the faster power is restored the better the memory image will be.
Once the pen tester boots the machine from the USB stick, the scraper tool will automatically dump the memory onto the drive. The screen shown in Figure 2 shows the scraper tool at work.
Figure 2: The Scraper Tool
Depending on the size of the memory and the speed of the USB port, the capture could take a while, up to a few hours on larger amounts of memory. Once the scraper has completed dumping the memory, it will restart the system. The pen tester simply needs to remove the USB stick and return to the machine used to compile the scraper. Within the tarball is a tool called USBdump. USBdump simply pulls every byte from the USB stick to the pen tester’s machine, and can be executed using the following:
sudo ./usbdump /dev/sdb > memdump.img
Once again, this could take a few hours, depending on the size of the memory capture. The result is a full memory image file containing a byte for byte capture of the target machine with hopefully a minimal number of errors.
The Firewire Attack
The Institute of Electrical and Electronics Engineers (IEEE) 1394 interface, better known by Apple’s implementation name of FireWire, is a high-speed communications interface originally intended as a replacement for SCSI. The main component of FireWire is its high data transfer rate, which is why it is used primarily for audio and video bulk transfers. One of the features of FireWire that contributes to its speed is the fact that it can directly address memory through Direct Memory Access (DMA) bypassing the CPU entirely. While this might be good news to the video editor that needs to download hours of footage from his camera, it’s even better news to a pen tester.
The DMA of FireWire allows a pen tester with physical access to a target machine to bypass the password protections in the OS by overwriting the section of memory which contains the functions for access control. DMA will also allow the pen tester to download the lower 4 GB of memory. This kind of access represents a significant security weakness in the IEEE 1394 specification, although FireWire only has access to the lower 4 GB of memory and can be guarded by Anti-Virus systems to prevent DMA. Due to the hot-plug functionality of FireWire, the target machine can be locked while the attack is conducted. In addition, while most OSs attempt to limit the DMA authorization to known FireWire devices (such as iPods), it is relatively easy to spoof these devices.
While the attack mainly targets FireWire, it will work on any device on the same bus. This typically includes ExpressCard (EC), PC Card, and the Thunderbolt port prevalent on all new Apple products.
Carsten Maartmann-Moe has developed a tool called Inception which makes exploiting FireWire almost trivial. The tool can be found at http://www.breaknenter.org/projects/inception/. Inception must be run from a Linux desktop. Linux cannot be a VM in this case as virtual machines do not implement a FireWire pass-through (for good reason). In addition, the pen tester will need Python 3 and Freddie Witherden’s libforensic1394 packages. Finally, the attacking and target machines both require a FireWire, EC, Thunderbolt, or PC Card interface.
Once Inception is installed and ready, the pen tester simply needs to connect the attacking and target machines with a FireWire cable, and run the following command with root privileges:
Inception will access the sections of memory which deal with access control and “patch” them, allowing us to access the machine with no password. Of course, the memory in the target machine contains a wealth of information, so the pen tester can dump the lower 4 GB of memory by using the command:
Memory Dump Analysis
Dumping a memory image is one thing. Analyzing the data is a completely different hurdle. Fortunately, a number of tools are available for just that purpose. Very few were designed with pen testing in mind. Most are forensic analysis tools used to find running processes, malware, and hidden data. Memory forensics is still a relatively new field, especially with 64-bit analysis. Many of the most powerful tools are still limited to law enforcement use. That being said, there are a number of tasks that can be executed to display risk to a client.
The Lest We Remember team also created an analysis tool for captured memory images. As the main thesis of their paper was that encryption keys could be recovered from memory, their tool, known as AESKeyFind, searched the captured memory image for AES key schedules and recovers the keys. The tool can be downloaded from the same site as the scraper. Once again, the tool comes with a makefile for easy compilation. Once the tool has been compiled, is can be run with the following command:
./aeskeyfind –v memoryimage.raw
The tool will proceed to search the memory image for AES keys and print them to the display. AESKeyFind will find both 128 and 256 bit keys. Even if the image is incomplete or contains errors, the tool may be able to recover keys. Figure 3, for example, shows an AES key recovered from an image containing a large number of errors:
Figure 3: AES Key Found in Damaged Memory Image
These AES key schedules could be used for a number of different purposes. They could be the master encryption keys for full disk encryption, for a VPN, or for the wireless network. Once they’ve been recovered, the only trick is figuring out what they decrypt.
Another useful tool is Volatility, an open source memory forensic analysis framework. Volatility has a number of modules that lets a pen tester extract useful information about the current processes and settings on the target machine. If the memory image is intact, the pen tester can even extract the Windows hashes out of memory.
The first step is to identify the architecture of the memory image, so that Volatility knows where to look for things. This is accomplished with the imageinfo module. Figure 4 shows the imageinfo module being invoked, and the resulting memory profiles being identified by Volatility.
Figure 4: Imageinfo Identifying the Image Architecture
Using this information, the pen tester can use additional modules to identify the SAM and System hives from the registry. Windows stores the registry in active memory while the machine is in use. Volatility’s hivelist module can be used to identify where each registry hive lives in memory. Figure 5 shows the hivelist module being invoked with the most likely profile identified by the imageinfo module.
Figure 5: Hivelist Showing Location of the SAM and System Hives
On a 32-bit system, Volatility has a hashdump module that can automatically extract the password hashes when given the addresses of the SAM and System hives. Unfortunately this module does not currently work on 64-bit systems, thereby limiting its usefulness. That said, Volatility is open source, and there is no reason a 64-bit module could not be written. In addition, it would be technically possible to extract the SAM and System hives from the memory image once their locations are known and use other tools to extract the password hashes.
Microsoft’s Security Response Center has their 10 Immutable Laws of Security. Number 3 is “If a bad guy has unrestricted physical access to your machine, it’s not your machine anymore.” Many clients feel that full disk encryption and strong passwords make up for any direct physical access an attacker would have to a machine. They fail to take into account the dangers of active memory. Enough information is stored in active memory that a pen tester could gain critical information or even access to the internal network. It’s never been considered an issue, because there was never a practical way to obtain an image of memory as an outside attacker. However, the Cold Boot and Firewire Attacks make it possible in certain situations to not only gain access to the memory but access the keys to the kingdom.
- Dieterle, D. (2011). Memory Forensics: How to Pull Passwords from Memory Dump. Cyber Arms – Computer Security. Retrieved 2013-11-18.
- Halderman, J. Alex; Schoen, Seth; Heninger, Nadia; Clarkson, William; Paul, William; Calandrino, Joseph A; Feldman, Ariel J.; Appelbaum, Jacob et al. (2008-02-21). Lest We Remember: Cold Boot Attacks on Encryption Keys. Princeton University. Retrieved 2013-11-18.
- Maartmann-Moe (Last update 2013). Inception. Available at http://www.breaknenter.org/projects/inception/. Accessed 2013-11-18.
Jonathan Fallone is a Senior Penetration Tester for Knowledge Consulting Group, where he conducts a variety of penetration tests for federal and commercial clients. He specializes in FedRAMP assessments of cloud solutions, enterprise-scale reconnaissance, and advanced password cracking techniques. Prior to his current role, he worked as a Validator on submarine systems for Naval Sea Systems Command. In his free time, Jonathan enjoys photography, soccer, football, and spending time with his wife and daughter.