Re: VM Rootkits: The Next Big Threat? (PC Magazine)

Technophobe wrote:

> PC Magazine - SubVirt, a proof-of-concept virtual machine rootkit
> created by MS Research and the University of Michigan, pushes the
> envelope for hiding malware. Will this new threat strike from below?

Gentlemen,

Something for your VM Rootkit discussion.

Subversive SubVirt
(http://www.viruslist.com/en/weblog?weblogid=182153387)

Ron

Ron Lopshire wrote:
> Technophobe wrote:
>
>> PC Magazine - SubVirt, a proof-of-concept virtual machine rootkit
>> created by MS Research and the University of Michigan, pushes the
>> envelope for hiding malware. Will this new threat strike from below?
>
> Gentlemen,
>
> Something for your VM Rootkit discussion.
>
> Subversive SubVirt
> (http://www.viruslist.com/en/weblog?weblogid=182153387)
>
> Ron

yeah, or
http://anti-virus-rants.blogspot.co...d-rootkits.html

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

A tidbit for the Rootkit discussion pot. I recently downloaded some
rootkit related programs from rootkit.com, including one
eeyebootroot.zip file containing ebrk.img ... a 512 byte boot sector
image file. Here's the readme:

*****************************************************
[READ ME]

This text is a quick introduction to the eEye BootRoot project and the
eEye BootRootKit network kernel backdoor. For much more information,
please refer to the slides (eeyebootroot.ppt).


[ENCLOSED FILES]

The eEye BootRootKit NDIS backdoor is a demonstration of boot-time
Windows kernel subversion technology. The assembly source code
(ebrk.asm) was written for use with MASM 6.11. It comes in
pre-packaged executable form as a floppy disk image (ebrk.img) and as
a CD-ROM ISO-9660 image (ebrk.iso).

Note that the ISO is bare-bones and does not contain a file system,
only a boot sector. If you burn it to disc, it will for the most part
appear to be a blank CD.

We've also included the source for a very simple demonstration packet
(demrsod2.asm), and a compiled binary file (demrsod2.bin) to be used
with netcat ("nc -u").


[OVERVIEW]

eEye BootRoot is a project presented at Black Hat USA 2005 by Derek
Soeder and Ryan Permeh of eEye Digital Security. The goal was to
explore *and* *implement* technology that custom boot sector code
could use to subvert the Windows NT-family kernel as it loads. To our
knowledge, such technology had not previously been publicly
demonstrated.

eEye BootRootKit is a manifestation of this technology -- a
removable-media boot sector that situates itself to regain execution
later, as Windows is loading, and then seamlessly continues the boot
sequence from hard drive 0. The basic concept employed is to hook INT
13h and "virtually patch" the Windows OS loader as it's read from
disk, then leverage this patch to hook into NDIS.SYS after it has been
loaded into memory and validated.

The hook function's purpose is simple: scan all incoming Ethernet
frames for a signature in a specific location, and execute code (with
kernel privileges) from any matching frame. The RSoD2 demo gives a
very simple display of this capability, by patching NTOSKRNL.EXE in
memory and causing a "red screen of death" kernel crash. Try sending
the packet to a closed UDP port on a firewalled machine running
BootRootKit, or use the broadcast address!


[FREQUENTLY ASKED QUESTIONS]

Q: Why is it "eEye BootRoot"?

A: Someone else is already using the "BootRoot", so we wanted the
distinction to be absolutely clear.


Q: How does it work?

A: Please refer to the slides (eeyebootroot.ppt) included in this
package. They were written to cover every detail and even provide
some handy reference material in case you're interested in producing a
derivative work, or writing your own.


Q: Is BootRootKit a virus?

A: No, it does not modify the contents of the hard drive, nor any
other non-volatile storage. And before you even ask, it only hooks
NDIS.SYS to monitor incoming packets, so no, it does not send any
traffic from the system on which it's running.


Q: From what other media could BootRootKit load?

A: Theoretically, any boot media. We haven't experimented with
bootable USB drives, although we do have a working PXE BOOTP/TFTP
server for serving up BootRootKit which we're not releasing at this
time. BootRootKit could of course be modified to exist as a
replacement hard drive MBR, but again, this would require some code
changes.


Q: I attended the presentation and got a CD, but it's empty! What's
the deal?

A: It's not empty, it just doesn't contain any files. No, seriously.
It has a BootRootKit boot sector, which is of course "below" the
ISO-9660 file system, so it wasn't necessary to put any files on the
disc. If you don't believe me, try booting from it and see if the
nefarious "blue smiley" appears in the upper-left corner. Then try
sending yourself the demrsod2.bin sample packet with "nc -u", but save
your work first. Or rip the CD back into an ISO file and inspect the
contents.

Oh, and thanks for checking out our talk! =)


[FEEDBACK]

Please send questions, comments, and anything else eEye
BootRoot-related to {dsoeder,rpermeh} at eeye.com.
*************************************************
Detection of the image file was spotty at Virus Total. Eleven of the
twenty four products alerted, at least in some fashion, but only five
produced identification. I haven't though installed the thing on some
drive to see which av alert on the Trojanised boot sector during
a "formal" scan.

Is the image file, as such, dangerous? Could some Trojan installer
package manage to copy the image to the boot sector of a active
hard drive under certain conditions?

Art

http://home.epix.net/~artnpeg

On that special day, Art, (null@zilch.com) said...

> Is the image file, as such, dangerous?

Not, as long as it hasn't been put on a floppy disk or CD, and a
computer BOOTED from said data storage.

> Could some Trojan installer
> package manage to copy the image to the boot sector of a active
> hard drive under certain conditions?

From inside a running OS? I hope XP won't allow for such an action.
However, if the machine is started from another device (removable
disk), it might happen, as XP doesn't really have the sole control over
the boot sequence.

I would not run a computer on the net, that has been started with eEye
BootRoot. Theoretically, one of the incoming packets might command,
that the start disk be modified and now contains an fdisk and sys
command, that does modify the hard disk's MBR, followed by a reboot
command.

The machine gets rebooted, and if you don't remove the floppy disk in
time, you're caught.


Gabriele Neukam

Gabriele.Spamfighter.Neukam@t-online.de


--
Ah, Information. A property, too valuable these days, to give it away,
just so, at no cost.

Art wrote:
> A tidbit for the Rootkit discussion pot. I recently downloaded some
> rootkit related programs from rootkit.com, including one

rootkit.com was founded by greg hoglund who happens to be a champion of
the 'rootkits are for hiding things' camp... as such there's a lot from
rootkit.com that i disagree with...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

On Sat, 18 Mar 2006 18:53:12 +0100, Gabriele Neukam
<Gabriele.Spamfighter.Neukam@t-online.de> wrote:

>On that special day, Art, (null@zilch.com) said...
>
>> Is the image file, as such, dangerous?
>
>Not, as long as it hasn't been put on a floppy disk or CD, and a
>computer BOOTED from said data storage.

I know, which is why I asked the question. Why should av alert on the
supposedly harmless image file? It isn't harmless though if it's
accompanied by a Trojan that copies the image to removeable media
boot sectors. So I suppose there's some good reason for alerting on
it.

I Trojanised a diskette with the boot sector image, and KAV 3.5 alerts
as Backdoor.Boot.Dins.a McAfee command line scanners and F-Prot
for DOS do not alert. Neither does KAVDOS32 for some odd reason. This
is the first time I've run across a discrepancy in detection between
KAVDOS32 and KAV version 3.5.

I'll probably pursue this with other scanners and Trojanised disks.
Without av alerting on Trojanised disks, this thing could cause a
helluva difficult situation.

Art


http://home.epix.net/~artnpeg