Hacker Defeats Hardware-based Rootkit Detection

Manequintet writes "Joanna Rutkowska's latest bit of rootkit-related research shatters the myth that hardware-based (PCI cards or FireWire bus) RAM acquisition is the most reliable and secure way to do forensics. At this year's Black Hat Federal conference, she demonstrated three different attacks against AMD64 based systems, showing how the image of volatile memory (RAM) can be made different from the real contents of the physical memory as seen by the CPU. The overall problem, Rutkowska explained, is the design of the system that makes it impossible to reliably read memory from computers. "Maybe we should rethink the design of our computer systems so they they are somehow verifiable," she said."

Comments

I thought this was invalid anyway

[LiquidCoooled]

I was under the impression that the only way to reliably detect a root-kit is to examine the system from another clean system?

ie remove the drive/devices and check them all.

Re:I thought this was invalid anyway

[JackHoffman]

The rootkits that are written to the disk aren't the biggest problem. Like you said, one can "simply" look at the drive from a clean system. The problem is with rootkits that are only installed in RAM, while the system is running. The attacker exploits some hole in an application or in the OS and then transfers the whole system into a virtual machine that looks exactly like the real thing, so the rootkit can't be detected from inside the OS. Nothing is written to disk, so when the system is powered down, the rootkit vanishes into thin air. Servers are unlikely to be powered down often and even if they are, the cracker can simply attack again. With the rootkit undetected, it is likely that the exploited bug has not been corrected. Common wisdom was that this type of attack can be detected by looking at the contents of the RAM in a way which bypasses the OS. The rootkit has to be somewhere, right? Well, according to this article, there is a way to hide the real RAM contents from hardware assisted forensic methods.

Re:I thought this was invalid anyway

[Score Whore]

An "ultrathin hypervisor" as some call it is a very tiny OS wrapper. The wrapper does indeed have negligible effect on the system - about as much effect as, say, running a small background process.

Like I said, if you are going to do nothing, then sure, you'll have a hard time detecting it. But if it does something, like keylogging or sending spam, then it'll have measurable effects.

Wrong -- "measurable" in this sense may not be so measurable. The clever malware could fool the system timer to be a little bit off (say, 0.1%), so that it hides its tiny footprint in the timer. Thus, any attempt to query the timer would just return the expected result.

Not wrong. My timer is on my wrist. There's another one on the wall. Neither one is attached to my computer. There is another on my network for the specific purpose of keeping track of the slew in my various systems' clocks. Additionally if you start screwing with my system clock, other systems on my network would see this behavior in fucked up timings in the local system's network stack. If your hypothetical malware is slowing my system timer to hide its consumption of system resources, then keepalives would be arriving at remote hosts late. Also there would be drift in the system clock vs. my gps receiver.

Then there are devices that have physical clock rates. Serial ports, PS/2 ports, sound cards, video cards, etc. You can go into a tight loop for X number of intervals of playing a known number of 44.1 Khz samples to your sound card. If you used to be able to get through 250 million interations of the loop and now you can get through 247 million iterations of the loop, then you know something is consuming resources on your system. And if you really want to measure the impact of the malware then make your loop perform privileged operations so that they must be virtualized.

And there is the fact that you could compare two clocks, the mobo's time of day clock and the CPU's cycle clock. If you screw with them both you'll see all sorts of bad behaviors. If you don't, then you can compare the relative speed of the two to see the loss due to malware.

Finally the malware has to live somewhere in system RAM. It can't allow itself to be over written. The original OS knows how much RAM is supposed to be there, so just consume all memory. When it attempts to swap out to a local hard drive, go ahead and fill that up too.

There's a lot of hyperbole and sensationalism about virtualized root-kits.

AACS "Improvement"

[SydShamino]

At this year's Black Hat Federal conference, she demonstrated three different attacks against AMD64 based systems, showing how the image of volatile memory (RAM) can be made different from the real contents of the physical memory as seen by the CPU.

Isn't this exactly what HD-DVD / Blu-Ray players need to prevent the AACS keys from being stolen? Just last week there was a story saying something like "PC-based movie players are inherently crackable, because the key has to be in main system memory for at least a brief instance, and then we can copy it." Now, this lady says there are methods to prevent anyone from truly reading what is in RAM. I don't understand.

Re:AACS "Improvement"

[Phil Resch]

Well, no. Not entirely.

Under normal conditions, that's correct. If a player has loaded the key into memory somewhere in order to use it, you can probably isolate the location in memory and retrieve the key. Which is what has been done to retrieve the AACS keys.

But the pathological case, the case dealing with rootkits, changes the game. How do you track the contents of your physical memory? Typically, through OS mechanisms. What happens if a rootkit (or a software media player using rootkit technology) subverts the OS mechanisms? You can't be assured of reliably tracking the contents of memory any more; maybe your OS is LYING to you! What is really in memory is not what you're being told is in memory, and maybe you can't find that key any longer.

Which brings us back to the article. Direct Memory Access (DMA) is a way of taking the responsibility for managing physical memory access (reading, writing, whatever) away from the processor and moving it to some other place in hardware (presumably some place that you can trust). And that's what hardware-based rootkit detection is about. Use hardware with DMA (which you trust) to access memory instead of letting the processor do the work and relying on the OS to tell you the truth.

The problem is that the way computers are currently designed, there's no way of starting DMA without having to talk to the processor (by way of the OS) first. Your DMA hardware has to ask "Hey, can I access memory?" and the OS has to say "Sure thing! You do it, and we won't bother the processor any more!"

But if the (subverted-by-a-rootkit) OS has a vested interest in you NOT being able to get true results using DMA, well, what are you going to do? The OS will just interfere. That's why Rutkowska is suggesting a direct, non-subvertable hardware port that you can jack into to use DMA without having to go through the OS first.

Trying to have her cake and eat it too?

[kscguru]

Let's see ... last year, she got all over the headlines claiming that virtual machines are a Bad Idea because rootkits could use them to remain undetectable (even though virtual machine experts discounted her "trivially easy and left unimplemented" parts as technically intractable).

And now a year later, she claims we need specialized hardware interfaces to scan memory for rootkits, even though this problem is laughably easy in the world of virtual machines.

And on to the actual work ... the research basically observes that MTTR registers (some of the MSRs in the CPU) can cause memory mappings to look different between the CPU and the northbridge, and then comes up with a pretty easy way to cause the northbridge to either lock up or read data that is different (really easy once you see the specs for the appropriate registers). And she totally ignores the possibility of a system defending itself against this attack by verifying the registers she's modifying. Lousy research, girl.

Oddly enough, this "hack" is ALREADY IN USE ON YOUR SYSTEM and is actually necessary. See, when the processor is running in SMM (System Management Mode), it switches to exactly this configuration: the PCI bus sees VGA hardware mapped at the well-known address, but the processor maps the RAM at that address, which gives SMM mode a few kilobytes of memory that the normal system can't touch. SMM mode is used for things like "legacy USB devices" (e.g. having your USB keyboard act like PS/2 so DOS can use it) and other implement-in-software hacks that your OS doesn't know about, but your BIOS vendor gives you as "value-added features".

She's a girl

[LS]

and reasonably cute, blah blah basement blah blah over 30 blah blah imaginary blah blah

There's already one solution available

[btarval]

"I'm thinking about motherboard manufacturers adding a special port which would allow for *direct* (this time really "direct") access to RAM and potentially some other critical resources like e.g. CPU system registers and maybe even caches," she said.

You can already do this, with many common CPUs. It's called JTAG. In short, it allows you to control the CPU directly, so that you can do exactly what Ms. Rutkowska proposes. That includes by-passing the caches and getting direct access to memory.

JTAG is what embedded people use to port an O.S. to a new hardware platform. And to debug really tough kernel problems. It beats the snot out of printks anyday. And there are certain sections of boot-code and kernel code where it is extremely difficult and annoying to develop without JTAG.

There are two immediate problems with JTAG however. The first is that not all CPUs support it. Believe it or not, I've met CPU designers who have never heard of JTAG (and this is usually a clue that they don't know what the heck they are doing).

The second problem is that some CPU manufacturers consider the JTAG interface proprietary. Intel is one (there's only one JTAG debugger available for x86, and it will cost you between $5,000 - 15,000 depending on what you get). That is absolutely silly, as these can be built for well under $500.

Why they keep the JTAG API interface proprietary is beyond me. I have yet to hear a non-lame excuse yet.

But in any case, the point is that this problem has already been solved. It's surprising to me that anyone seriously doing forensics wouldn't be using JTAG already, for the reasons that Ms. Rutkowska suggests.