Saturday, January 20, 2007
Beyond The CPU: Cheating Hardware Based RAM Forensics
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). 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 we’ve 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. As far as the PC architecture is concerned, probably the first two papers in this area are those about Tribble and CoPilot. As an alternative to expensive dedicated PCI cards, one can also use a FireWire bus, as it has been described by Maximillian Dornseif at el., and later by Adam Boileau.
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 to do some checks itself (like e.g. CoPilot does).
The whole idea behind hardware based RAM acquisition is that the process of reading the memory is using Direct Memory Access (DMA) to read the physical memory. DMA, as the name suggests, does not involve CPU in the process of accessing memory. So, it seems to be a very reliable way for reading the physical memory…
But it is not! At least in some cases...
Next month, at Black Hat DC, I will be demonstrating how to cheat hardware based memory acquisition on AMD based systems. In other words, I will be showing that the image obtained using DMA, can be made different from the real contents of the physical memory as seen by the CPU. Even though the attack is AMD-specific, it does not rely on virtualization extensions. Also, the attack does not require system reboot. Nor does it require soldering ;)
I have tested my proof-of-concept code against a FireWire-based method of memory acquisition, using tools from Adam Boileau’s presentation.
I wanted to test it also against some PCI cards, but it turned out, that for an ordinary mortal person like myself, it is virtually impossible to buy a sample of a dedicated PCI card for memory acquisition… E.g. the Tribble card is still unavailable for sale, according to its author, even though the prototype has been build in 2003... BBN, the US company known for doing lots of project for the US government, apparently has a prototype (see page 45) of something similar to Tribble, but is not willing to discuss any details with somebody who is not involved in a project with the US government... Finally, Komoku Inc., whose main customers, according to the website, are also US government agencies, also rejected my inquiry for buying a sample of CoPilot, claiming that the device "is not generally available right now" ;)
Anyway, even though I was able to test the attack only against FireWire based method, I’m pretty confident that it will work against all other devices which use DMA to access the physical memory, as the attack itself is very generic.
See you in DC!
Posted by Joanna Rutkowska at Saturday, January 20, 2007
Subscribe to: Post Comments (Atom)
I wish I could stay in DC next month!! Well, there is one only thing about this article I disagree with: you're not an ordinary mortal person!!! You're an extraordinary amazing girl! :p Enjoy DC Joanna! Kisses from Spain.
It's about damn time. Good luck with your presentation.
Will you also present this at Black Hat Europe?
¡CHAPEAU JOANNA! zorionak
I got your name reading a VISTA article in tha Australian PC Authority magazine.
I immediately went on your website and I must say I am quite impressed.
One part talks about using a PCI card and DMA to take a memory shot. First I thought
this is an excellent idea, but when I really started thinking about it I found 2 flaws.
1. With DMA you never get an EXACT memory snapshot, because you cannot stop the processor
before you take the shot.
2. Background DMA slows down other processes (because of the additional memory cycles)
so it is detectable by self timing programs.
I think I have a solution that works better.
1. Instaed of using DMA you install a second memory on the PCI card that runs on the same
address range than the PC's memory.
2. This memory is configured in a way that you can only WRITE to it from the PC's address
and data bus. Reading is not required and not recommended, because the output drivers
of the two memories would not like it.
3. To take a snapshot you just disable the write.
4. To read the data the address and data bus is switched to an on board processor that
reads it and transmits it to an external PC via serial port or other means.
This type of memory snapshot is always current and more important IT IS TOTALLY
TRANSPARENT to the PC. It does not slow it down in any way and does not need any
PC software to operate it.
There is another nice advantage.
When you add a third memory to the adress range and connect a clock to the databus
of that memory you get a TIMESTAMP for each memory write.
With this timestamp you can trace the scheduling of processes and analyze how spyware
blocks protected processes, for example two processes that wait for input from each
other without a timeout.
Uli Dinklage (firstname.lastname@example.org)
...So when are you going to change your name to Trinity? Excellent work!
I understand your dissappointment at being unable to source these cards.
I myself used an off-the-shelf PCI-based FPGA demo board. The PCI functions are provided by an IP-Core and you can simply code the engine in Verilog or VHDL.
So, No SMT work at all (I know that SMT worries some people) and it romps in much MUCH cheaper (and more flexible) than those proprietary DMA sniffer cards that nobody wants to part with.
Increasingly these days the FPGA is the hackers closest ally. Armed with an FPGA you can process spliced uplinks on the fly (A PIC microcontroller struggles above 10Mbps and stronger controllers struggle above 100Mbps) - but a cheap FPGA solution can MITM, inject, clone and reroute selected packets on DMT and QAM64 based technologies after dropping in some IP-Cores and a little packet logic.
I respectfully suggest that Joanna takes a look at the readymade IP-Cores for PCI functionality and demoboards which are fully wired SMT PCI cards with an FPGA programmable logic IC premounted.
Lets face it, with FPGA's making their way into HSC environments it is almost mandatory for the hacker to invest some time in learning to code in Verilog/VHDL.
I've implemented DMA before in this fashion although not for this particular application. I'd suggest it is almost certainly the best route for the hacker to explore such detection systems on a tight budget.
Of course, let them have these cards... for such a technology to be useful they need to be able to RECOGNISE malware. And that, as we all know, is a much trickier proposition.
I've yet to meet a career hacker that used off-the-shelf rootkits anyway. And heuristic analysis at the kernel layer is almost impossible against all but the simplest and most direct of rootkit approaches.
Interesting story. Any new updates?
What no one seems to mention is that a CPU cache’s contents are NOT always coherent with the DRAM copy! This sort of defeats DMA, and even the proposed "shadow" RAM of Uli Dinklage.
Some code could even "unroll" whatever it wanted to a section of cache that had been configured to NOT map to physical/logical RAM address and no one would see it!
This is great, thank you so much for sharing! You should go global with this, hit up Black Hat Japan if you're not already planning to.
Excellent work!.. it is interesting to read.., i am not in hardware industry but i liked its title.
"Beyond The CPU: Cheating Hardware Based RAM Forensics"
Post a Comment