Slashdot Mirror
Microsoft Research Warn About VM-Based Rootkits
Tenacious Hack writes "According to a story on eWeek, lab rats at Microsoft Research and the University of Michigan have teamed up to create prototypes for virtual machine-based rootkits that significantly push the envelope for hiding malware and maintaining control of a target OS. The proof-of-concept rootkit, called SubVirt, exploits known security flaws and drops a VMM (virtual machine monitor) underneath a Windows or Linux installation. Once the target operating system is hoisted into a virtual machine, the rootkit becomes impossible to detect because its state cannot be accessed by security software running in the target system."
...and nuke the entire site from orbit.
It's the only way to be sure.
Everything I know about rootkits tells me that you cannot detect one from within the running system, you have to be objective (I consider the current fingerprint detection to be working because of bugs in the rootkit implimentation, these will be "fixed" over time).
Keep a known secure boot CD.
Drain the battery and reset the bios then boot from that cd.
If theres anything sophisticated enough to bypass this level of paranoia then it can damn well have my credit card number and I'll gladly send spam for them.
liqbase
Why is microsoft researching this kind of thing? And with Linux too? It makes me wonder if the next time you go to install Windows on a partition somewhere with the same machine as you also dual boot into Linux whether your linux boot will not then be "taken over" by Windows, and MS can insert any little hooks, DRM, inspection code or other things running underneath the linux system you have.
Then they can force linux to perform worse than Windows and nobody will be none the wiser.
Except when you boot into linux and then you get a blue screen it will give it away lol.
You never sure if this is a feature or a bug. Either way, they will probably charge a subbscription fee to get the feature or get rid of the bug.
Original Paper
Abstract
Attackers and defenders of computer systems both strive to gain complete control over the system. To maximize their control, both attackers and defenders have migrated to low-level, operating system code. In this paper, we assume the perspective of the attacker, who is trying to run malicious software and avoid detection. By assuming this perspective, we hope to help defenders understand and defend against the threat posed by a new class of rootkits.
We evaluate a new type of malicious software that gains qualitatively more control over a system. This new type of malware, which we call a virtual-machine based rootkit (VMBR), installs a virtual-machine monitor underneath an existing operating system and hoists the original operating system into a virtual machine. Virtual-machine based rootkits are hard to detect and remove because their state cannot be accessed by software running in the target system. Further, VMBRs support general-purpose malicious services by allowing such services to run in a separate operating system that is protected from the target system. We evaluate this new threat by implementing two proof-of-concept VMBRs. We use our proof-of-concept VMBRs to subvert Windows XP and Linux target systems, and we implement four example malicious services using the VMBR platform. Last, we use what we learn from our proof-of-concept VMBRs to explore ways to defend against this new threat. We discuss possible ways to detect and prevent VMBRs, and we implement a defense strategy suitable for protecting systems against this threat.
Gan Family Homepage
It may not be feasible for home environments, but for workplaces. What about booting off either dedicated ROM boot keys, or USB memory keys with a some sort of physical read only/read&write switch. Put the key into your machine to boot (for bonus points, the key tells the machine who you are and begins to load your roaming profile), when it comes time for a new image the IT guys either give you a brand new ROM key, or update your USB key by toggling the switch.
My worry with keeping things inside the machine (the article indicates that AMD and Intel have ideas) is that it's just going to be a perpetual arms race. Since we can't rely on the user to know when it is and is not apropriate to allow your OS to modify your boot sector, evenually virus/malware authors will just trick people into accepting the updates.
paul reinheimer
You can only be secure if your run hardware with treacherous computing modules installed on the motherboard and in the "approved" CPUs and BIOS chips, and that only works with treacherous computing software, sort of expensive hand in designer glove..
Kind of a sneaky advertisement, isn't it? Instill terror to sell vendor lockin hardware and operating systems. Maybe even get a law or three passed. They sort of gloss over the "get the rootkit there in the first place" part, don't they?
Here is a link to the actual paper the article references:d f
http://www.eecs.umich.edu/virtual/papers/king06.p
The authors make an interesting point -- users and rootkits are about control. Whichever one controls the outer layer wins. If the user is in a protected environment, a rootkit running as root can win. If the user is root, then the rootkit must be a kernel-level root-kit and run in the kernel. If the user can control the kernel, the rootkit must control the machine, in this case, put the user kernel in a VM.
My take is: in this game of cat and mouse, you'll stop only at the hardware -- it is hard for a rootkit to control the hardware short of the rootkit script kidde being able to get physical control. So yes, the user can win this game, if he controls the hardware that controls the software. How does the hardware control software? You guessed it: trusted computing ala TCPA ala Palladium etc etc.
Can you think of a way to win against rootkits without TCPA?
On a normal machine, if you try to virtualize it you would notice right away that something was wrong as it would slow quite a bit.
There might also be driver issues that could tip you off something isnt right. May not know what, but it should be apparent something is amis. It would have to emuate all the hardware that you had installed at the time of infection, unlike something like VMWare which presents a 'standard' ( but different ) set of hardware devices. Thats a prety tall order to pull off.
---- Booth was a patriot ----
i've been working on a compromised system to poke for holes in the concept and i hit upon a novel idea. in fact, it's really simple
all you have to do is-END CARRIER-
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
that virtualising i386 was hard and carried quite some overhead.
a l_machines) - it is amazing how many of those technologies run guest OSs at native or near native speeds!
Not in the slightest. When you emulate a different architecture, sure, that takes a significant overhead having to translate the machine instructions. But virtualisation runs the existing machine instructions more directly on the hardware, which can run at near-native speeds.
Some of the latest hardware from Intel (the Vanderpool technology : http://en.wikipedia.org/wiki/Vanderpool) is even able to do virtualisation at the hardware level directly.
We are looking very seriously at replacing several servers with this virtualisation technology using VMWare ESX and VMotion. It should prove to save on hardware costs and running costs in terms of power and air conditioning, not to mention the flexibility you have! I'm sure other folks who have used this technology will be able to tell more about that.
Also, you can check out the Wikipedia comparison of virtual machine technology (http://en.wikipedia.org/wiki/Comparison_of_virtu
an image of an idiot user taking their computer to a repair shop and the repair person uncovering 500 instances of VMWare running with 1 instance of spyware in each one?
is to run under a virtualization manager from the beginning. Than, there will be no way for these VM-based rootkits to actually run on the real haardware. They'll think they are doing so, but the outermost vm will be able to detect them easily.
How do you install the rootkit? Yes, you guessed it, through an insecure operating system. This article is imho just another promotion FUD campaign for TCPA.
If your current operating system and security measures are good enough, such rootkits-with-virtual-machines are not even going to be able to be installed, heck as long as you don't have to login as administrator to print out a document or surf the web, you're pretty safe.
And as soon as you notice your box could be r00t3d, you take it out anyway and don't trust it. And if you don't notice one of your boxes is generating extra traffic or doing things it shouldn't, you shouldn't have to have admin privileges anyway.
Custom electronics and digital signage for your business: www.evcircuits.com
If the bastards already have enough access to be downloading and executing code on your machine, it is trivial for them to crash your box and make you reboot... assuming they can't just reboot your box out of hand.
Notice how one of their solutions is secure hardware?
I think we know why MS is funding this.
[Fuck Beta]
o0t!
Some functions cant be passed through, they need to be emulated, even on the same architecture, redirecting memory, storage and I/O requests, interrupt handlers and such. All these things suck performance, and in the case of games, where LOTS of memory and low-level calls to the graphics hardware are being made, performance sucks BADLY.
Any gamer will notice a loss of 15 FPS or more in their favourite game. Developers will notice it too, when their profilers output does not match their codes timing.
You can't play with the time, even if you are in a VM. People will notice this - even if the software wont.
LL
This may very well astonish you, but such sophisticated infection mechanisms already exist and have already been demonstrated. See this rootkit concept overwriting your BIOS to create a permanent backdoor.
Note: removing the CMOS battery will not destroy this rootkit because the CMOS battery erases the NVRAM, not the BIOS flash chip. The only known way to recover from a BIOS rootkit is to reflash your BIOS... but what if the rootkit is intelligent and tries to re-corrupt the new image being flashed ? This is a possibility. In this case your only option is to physically change the flash chip with a known good one. And don't forget that a modern computer has a lot of flash chips that can theoretically be infected: hard disk firmware, video card BIOS, DVD drive firmware, etc.
So basically what it is, is a rootkit designed to run in a virtual machine (like VMWare, VirtualPC, Bochs, QEMU, etc) that takes root control of the virtual machine, but the host OS is unable to detect the malware because it runs under a virtual machine and not on the host OS itself.
Microsoft had tested code under VMWARE for Linux, and VirtualPC for Windows that allowed them to gain root access to the host OS from the virtual machine, and run the rootkit malware under the virtual machine.
Yet what they are not telling you, is that the virtual machine has to run on the host OS, and that can be detected, even if the malware cannot. If you are really paranoid, just don't run a VMWARE or Virtual PC virtual machine or any other virtual machine, and if you find one on your OS, remove it. The problem with that is that malware scanners will be looking for virtual machine files and suspect them of being malware and warn the user. Besides any virtual machine has to be installed on Linux with root access anyway, and VMWARE Server apparently when I installed it on my Linux box had to compile a part of itself to match my kernel, and asked me to download a few libraries before it would continue. I doubt someone can use VMWARE to install as a regular user on Linux without someone with root access allowing it. Still, Xen is a virtual machine and is becoming popular with Linux, I wonder if it is vulnerable as well?
The whole VM rootkit fails, unless the malware author finds a way to install a VM on a host OS without being detected, and without Root or Administrator access. The only way I can see that happening on Linux and Unix systems is if they use a trojan horse method of making it part of a program the user or administrator wants to install and they use root or administrator access to install it. On Windows it would just use an exploit to get Administrator access.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
My roommate runs a PC repair biz. I've noticed those dual-BIOS mobos. Always felt weird to me. If they want to make sure you have a good BIOS at all times, isn't it cheaper to install ONE bios socket, and send you two chips? Then you'll only swap if you really need to. And the "clean" chip is guaranteed clean because it can't be tampered with when it's not in the computer.
In any event, programs being able to flash your BIOS without telling you about it is A Very Bad Thing(TM). Disabling BIOS writes except when booted from a floppy would be a start. But at a very bare *minimum*, when the BIOS is modified by anyone or anything, the next time you boot the machine, the BIOS boot routine should throw a warning up on the screen:
"Your BIOS has been modified since last reboot. If you have not intentionally changed your BIOS, or added new hardware, you should discard these changes. Discard changes? (Y/n)"
And the code that performs this check, and throws up the error message, should be in a ROM or OTP chip where software can't tamper with it.
Here is how you detect any VMM on linux or Windows,no such thing as undetectable if you know how to find it. http://www.trapkit.de/research/vmm/scoopydoo/scoop y_doo.htm
The obvious solution is... Windows VISTA!
Heck the OS is so large any VMBR trying to "hoist" it is going to probably:
A.) Run out of space (memory or HDD).
B.) Take so long to hoist the OS, the user will probably reboot thinking their machine's locked up again.
C.) Cause CowboyNeal to acquire a hernia.
They (MS) are probably just looking for more selling points for their new BIG baby.
No, the worst part is that they're right and we have a strong possibility of losing the freedom to use our own property in the ways we wish to. This research is a direct response to this TPM (formerly Palladium) initiative, and is intended to force TPM into future hardware;
There is a lot of potential value in something like TPM, but since some of the earliest applications (although abandoned in Vista) included remote attestation of installed software, the most likely purpose would be to force computer users into a rental model for software use."I've got more toys than Teruhisa Kitahara."
Stephen R. Donaldson wrote the "Gap Series". At one part of the story, the "Data First" of a pirate vessel put a virus in the firmware of one of the pieces of hardware controlling the ship. Even if the ship's computer was reloaded from known good stores, the virus would re-infect the computer. The virus was rigged to totally wipe the ship's computers if a password wasn't entered at specified intervals. Since you couldn't navigate or operate equipment without the computers, this was effective extortion. Billions of miles from home, there was simply no getting back without functional computers.
The cure was to install known good hardware (itself tricky considering the circumstances) and to reload the ship's computer. The story also featured a kind of WORM device called a "datacore" that every ship had to carry by law. It was a combination flight-recorder and criminal evidence accumulator. Come to think of it, many IT issues were dealt with pretty well in this series. It's worth checking out. The IT issues are essential in certain parts of the story but they aren't the main point.
You would soon know if you were running multiple Windows Virtual Machines because within minutes of the infection you would receive an email from Microsoft demanding you pay for the additional licences.
AT&ROFLMAO