I am excited to be speaking at SyScan Singapore 2012 today. SyScan
has a reputation for being a high-quality, extremely technical
conference, as you can tell by the impressive line-up of speakers.
In my presentation, I/O, You Own: Regaining Control of your Disk
in the Presence of Bootkits," I will debut operating
system research I've been working on for the past few months.
As the title suggests, the research introduces a novel technique
to side-step MBR rootkits ("bootkits"). The secret sauce
in this technique involves utilizing (note: not tampering with or
altering) the crash dump mechanism provided by the Windows operating
system in order to read/write to disk. All software that runs on
Windows (including forensic tools) uses the "Normal I/O
path" to disk in order to save or open files. The Normal I/O
Path consists of various drivers (port, miniport, class, file
system, volume, partition, and so on) that provide access to the
physical hardware. Over the past 20 years, rootkits and bootkits
have been infecting various drivers in this Normal I/O path in order
to hide malicious files. As I will show in my presentation, the
mysterious crash dump mechanism, which is largely undocumented by
Microsoft, provides an alternative path to disk (the "Crash
Dump I/O Path") that can be used to locate data hidden by
rootkits. To my knowledge, there is no malware in the wild today
that hooks or alters the crash dump I/O path. That means it is a
pristine path which effectively defeats all known disk I/O-hooking
rootkits.
The naysayers will be quick to point out the fight
against rootkits is a cat-and-mouse game and that within weeks there
will be some new rootkit that defeats this technique. While this
might be true on some level (every defense mechanism in software can
be undermined in some way), I would argue that tampering with the
crash dump mechanism presents a unique challenge to rootkit authors.
In short, it is much harder to tamper with due to technical
restrictions which I will leave up to the rootkit authors to
discover. Additionally, infecting the crash dump mechanism presents
a conundrum for an attacker. If it is corrupted or rendered
inoperable, the attacker's presence would be revealed, because the
system would not be able to "blue screen" and generate a
crash dump. Either way, I look forward to the debate.
In
addition to covering the technique to use the crash dump mechanism
outside of the operating system, my presentation will cover details
of how the crash dump process itself works, from Windows 2000 up to
Windows 7. This material is a result of weeks reversing the Windows
kernel and related crash dump drivers, as well as port and miniport
drivers for SCSI and IDE drives.
I hope this post has piqued
your interest. Stay tuned to the M-unition blog for links to the
slides and whitepaper, which will be released after the
conference.
