eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
ARLINGTON, Va.—Unless you were at Black Hat on Feb. 28, you probably woke up safe in the assumption that if a rootkit hit your system, reimaging would remove it. You probably also thought that the best way to search a PCs volatile memory, or RAM, was by grabbing it with a PCI card or a FireWire bus.
You were wrong.
At the Black Hat Briefings here on Jan. 28, two breakthrough hardware hacks were demonstrated. One shocker was Coseinc Senior Security Researcher Joanna Rutkowskas demonstration of a way to subvert system memory through software—in essence, the shattering of our long-held belief that “going to hardware” to secure incident response is a security failsafe.
Security professionals at the show called it the “attainment of the holy grail,” particularly since the only way to fix the systems memory corruption is to reboot—thus erasing all tracks of the subversion.
Its a digital forensic teams worst nightmare. How can you figure out—and prove in court or to auditors—what people have been doing on your companys PCs, for good or evil?
Hardware heresy didnt stop there. John Heasman from NGSS (Next Generation Security Software) proved that rootkits can persist on a device—on firmware—rather than on disk, and can thus survive a machine being reimaged. Even reformatting wont save us these days.
These hacks are esoteric, but theyre proving that much of what we thought of as hardware unassailability is pure folklore.
Jamie Butler, principal software engineer at security services provider Mandiant, explained the significance of Rutkowskas hack in an interview with eWEEK at Black Hat here. “The significance of it is theres been this folklore, this legend that if you do hardware acquisition of memory, its not subvertible,” Butler said. “But if youre running software and youre accessing memory, you can be subverted.”
Heres how Rutkowska herself described our current beliefs about hardware unassailability on her blog: “We all know that any software-based system compromise detector can always be cheated if malware runs at the same privilege level as the detector (usually both run in kernel mode),” she writes. “This is what I call Implementation Specific Attacks (ISA). Because of that, mankind has tried to find some better, more reliable ways for analyzing systems, which would not be subject to interference from malware. “And we all know what weve come up with as a solution—hardware-based devices for obtaining the image of volatile memory (RAM), usually in the form of a PCI card.”
Those devices include a proof-of-concept called Tribble (PDF), from security professionals Brian Carrier and Joe Grand, as well as BBN Technologies CoPilot, a device you cant get unless youre doing research for the U.S. government. The idea behind these devices is to access physical memory by using DMA (Direct Memory Access). This method doesnt touch the CPU when it accesses memory, so its been considered a reliable way to read physical memory that hasnt been mucked up by whatever havoc malware has been playing with the operating system. Not.
“The point is: once we get the memory image, we can analyze it for signs of compromises on a trusted machine or we can have the PCI device do some checks itself,” Rutkowska said. “So, it seems to be a very reliable way for reading the physical memory …. But it is not! At least in some cases ….”
Butler explained it this way: “Because the CPU accesses physical memory through a different channel than DMA access, she was able to redirect DMA access somewhere else. The significance is that people were using DMA-based acquisition, either with FireWire or PCI, to get physical memory from a machine. Then they could search for processes, ports, whatever was happening at the time of acquisition. Now shes redirected that access, that read of memory, to some other place. She just filled in all that memory with [the character F, repeated multiple times: FFFFFFFF]. Now theyre reading something completely different than whats actually running.”
In her demonstration at Black Hat, Rutkowska showed her work on x86/x64 architecture, specifically AMD64-based systems. Not that this hack wouldnt necessarily work on 32-bit systems, but, Rutkowska said, AMD is what she had on hand.
Bear in mind, you wont hear from AMD or Intel about patches for your hardware, because theres nothing wrong with it. Rutkowska pulled everything she needed out of AMD manuals. So yes, she shattered beliefs in hardware architecture, but in essence she just played with what was already known.
“Its about design,” she said during her demonstration. [PCs] werent designed for security. They were designed to do complex work.”
2
None of this likely matters to you unless youre a nation state. Or the subject of intense interest on the part of very smart hackers who have a keen interest in subverting your systems, for purposes of espionage, say, or perhaps destruction of your countrys security infrastructure.
If you are, you should know that Rutkowskas trick is considered cool because the hardware itself cant tell its being subverted, since it cant read the registers that are actually subverting it.
“These hardware devices can request an address and range they want to read,” Mandiants Butler said. “They cant read hardware on the chip set. They dont know theyre being sent somewhere else. She said you can definitely be subverted if youre only hardware, and definitely if youre only software, and if you combine the two, you can maybe be subverted because you can perhaps read registries and tell youre being shipped somewhere else.”
Heres the scary part, particularly for digital forensics investigators: Even if you can tell somebodys pulling a Rutkowska hack on your hardware, theres absolutely nothing you can do about it.
“Even if you knew you were being shipped somewhere else in memory, you couldnt do anything about it because she was setting in the register a lock bit. The whole purpose of memory acquisition is to see whats running. If a lock bit is set, the only way to read is by rebooting. So everything in memory is now gone.”
So thats hardware myth No. 1 demolished. John Heasman, director of research at NGSS, took care of the rootkit reimaging myth with a little thing he called firmware rootkits.
The current state of application security, Heasman said during his briefing, is in general getting a lot better. The problem is that those applications are running on increasingly complex hardware distributed in multiple ways—multiprocessor machines, for example, with a number of devices in them, each device having its own hard drive and its own storage.
“Unless we address hardware security, were leaving an interesting area of attack,” he said.
Current rootkit detection tools consider only the PCs disk. “But many devices have firmware,” Heasman pointed out. “Even your battery has firmware [i.e., software that is embedded in a hardware device], and you can update it from the operating system.”
Firmware is a ripe target for rootkit exploitation because its practically ignored, Heasman said.
“Consider each and every machine on your network,” he said during the demonstration. “Typically in a well-managed network, admins will be aware of every machine on that network and what its running. But can they tell me exactly what PCI devices are available on every machine on the network? Network cards, graphics cards? And where did those graphics cards come from? Which manufacturer? What exchanged trust from that manufacturer to your network?
“Which of these cards are flashable [i.e., allow for firmware updates]? Not all are. If you know which ones are flashable, what firmware do you have on each device? How can you trust the integrity of that firmware? Do you trust in it? Did you audit it yourselves? Did you download it from a random Web site, from the manufacturers site? Did they provide a signature? Did you verify the signature?”
In most cases, Heasman said, the answer is “I dont know.”
“By and large, I would imagine most corporations dont have this information at hand,” he said.
Heasman chose to persist a rootkit on a PCI device containing a flashable expansion ROM. At the present time, how to detect and prevent such an attack isnt understood when the system in question doesnt contain a TPM (Trusted Platform Module).
“My thinking is if you can get a rootkit into an environment where they reimage the system daily, as in some secure systems, we could still survive,” Heasman said in an interview with eWEEK. “There are no tools in pub domain that would detect that.”
Heasman went on to demonstrate the abuse of PXE, the Preboot Environment developed by Intel as part of is “Wired for Management” initiative.
For now, suffice it to say that no evidence has been found to suggest that malwares using his technique.
“Its dubious as to whether it ever will be exploited by malware,” he said, given how easy it is to compromise home users machines. “As long as that remains, theres no reason to develop something that gives you firmware control.”
But after Black Hat, we now know that it can be done, just one more shattering of a hardware misconception.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.