Re: Conover's BCE

[Matt Conover <mconover () gmail com>]

> This sounds like a simple light-weight software-based virtualization (read
> VMWare or VBox), but has an obvious problem that to avoid a simple
> detection via
> DMA (a rootkit sets up a DMA via one of the devices, e.g. SATA controller
> and
> checks if its code is indeed at kernel addresses), the tool needs to
> emulate as
> much I/O as possible. This way it is becoming more and more like a VMWare
> Workstation product, losing all it's light-weight benefits. In the end it
> comes
> down to the question -- why not simply use VBox (which is opensourced, so
> one
> can easily insert "probes" there and also change the I/O devices strings so
> they
> don't immediately look like VBox's ones)?


Thanks for the feedback. I need to clarify Dave's original comment in order
to respond to Joanna. In its current form, it's more of an analyst tool. The
goal is to capture the rootkit's behavior, but it doesn't prevent the
rootkit from doing anything. Mostly it's just a proxy that sits between an
unmodified kernel driver running at ring3 and the kernel and records all the
interactions between them. The tool doesn't actually emulate things like DMA
or kernel APIs. Rather than trying to reverse engineer a packed driver with
a disassembler, the analyst can look at its runtime behaviors.

The basic idea is to run the driver in an isolated domain (non-executable
pages + running at ring3) and capture the faults this causes. Calls into the
rootkit from the kernel produce a fault, and all access from the rootkit to
kernel will produce a fault. The tool simply detects the fault (caused by
the driver running at ring3), records the event (i.e., the behavior), and
then re-executes the code that caused the fault at ring 0. The intention is
to make sure the driver cannot interact with the kernel on its own, it needs
the tool to serve as the middleman. If the rootkit calls WRMSR, for example,
it will cause an access violation at ring 3, so the tool will record the
attempt to use WRMSR, and then execute the WRMSR (at ring 0) on behalf of
the rootkit.

 The only instructions which are emulated/virtualized are the ones that
would leak the ring3 state (like "mov ax, cs") or EIP (the rootkit should
always see its virtual EIP). That was what Dave was referring to when he
said "virtualized"-- but the tool doesn't attempt to do anything too
sophisticated. The rootkit would still need to be run in a VM, because the
rootkit will still work exactly as it would in a native environment (at
least, it should).

The rootkit could break out of the tool using bluepill or even the whole VM
using cloudburst -- the tool would only be able to record the events up to
that point. So, the tool would definitely be able to report that the rootkit
did a bluepill/cloudburst, but it wouldn't attempt to prevent it and
wouldn't know what it did after that. But for the tool's current purpose,
that would be good enough.. the analyst would know its a malicious driver if
tries to do a bluepill/cloudburst (at least, until there are some legitimate
drivers using bluepill or cloudburst). Of course, there are a lot of other
subtleties I didn't mention here (some drivers are probably impossible to
run with this tool), but a lot of drivers work fine. The slides from the
presentation could probably further clarify, so feel free to contact me.

Side note: greets to Peter Ferrie :) BCE would not have been possible
without him

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave