Crisis Trojan Makes Its Way Onto Virtual Machines 49
Trailrunner7 writes "The Windows version of the Crisis Trojan is able to sneak onto VMware implementations, making it possibly the first malware to target such virtual machines. It also has found a way to spread to Windows Mobile devices. Samples of Crisis, also called Morcut, were first discovered about a month ago targeting Mac machines running various versions of OS X. The Trojan spies on users by intercepting e-mail and instant messenger exchanges and eavesdropping on webcam conversations. Launching as a Java archive (JAR) file made to look like an Adobe Flash Installer, Crisis scans an infected machine and drops an OS-specific executable to open a backdoor and monitor activity. This week, researchers also discovered W32.Crisis was capable of infecting VMware virtual machines and Windows Mobile devices."
err, A virtual machine is not a machine? (Score:2)
Re:err, A virtual machine is not a machine? (Score:5, Informative)
The threat searches for a VMware virtual machine image on the compromised computer and, if it finds an image, it mounts the image and then copies itself onto the image by using a VMware Player tool.
Re: (Score:1)
'Breaking in' implies that it had to bypass some security mechanism, but that isn't the case.
ah don't get it (Score:2)
N^HLeo just needs to wake up before the van hits the water. Right?
Re: (Score:2)
Imagine your VM being infected just because the hosting server is infected. In most cases, even if a server is infected, the VM remains in a relatively clean state. Now, just because you're hosted on an infected server, you can get rooted.
Re: (Score:2)
Hosting servers can NOT be infected by this. There is no VMware attack vector or vulnerability - and the exploited condition belongs to Windows/Java/Flash.
There are "always on" Endpoint AV solutions for vCenter. So if an infected machine were somehow copied from a user desktop machine (unlikely), it would be detected and cleaned, without installing an AV program in the VM.
Re: (Score:3)
Imagine of the machine is mapped to a network share where a team of developers store their VM images. Before this risk came out, the developers could be fairly certain that if a workstation was infected, they could just pick up another laptop and resume their work while IT re-images the infected machine.
One of the key benefits of virtual machines in a development environment is the portability of the VM. You can fire it up on a laptop, work on it, and then later deploy it onto a 50 node cluster. Or you c
Re: (Score:3)
OHHH NOES!
Stuxnet targets USB DRIVES!!!!
Really. It is about as relevant. The VMDK file is used to hitchhike.
There's also 0% chance of this occurring on the real, VMware ESX - or vSphere stuff. It doesn't have an attached Windows instance to exploit.
Re: (Score:3)
This is largely irrelevant and non-news. ESX/ESXi is not affected (bare metal, no host to infect), it only infects VMs running directly on a Windows box. That makes them almost certainly not production, just dev VMs, or most likely VMs set up to help bypass web filtering.
The real interest here is that the infected VM can hang back, get missed by a virus search-and-destroy (by being off), then reinfect other hosts after admin thinks they're clean.
Re: (Score:2)
That seems plain stupid.
Breaking out of a VM could be useful for getting at a researcher's interesting files (and there's been a few windows of opportunity where at least vmware has been vulnerable), but breaking into a VM? Why on earth would you want to do that? I can think of one reason that kinda makes sense, and that's getting access to an image that's going to be spread into the cloud, but that seems like such an insanely specialized usecase that I don't grok why it's included in a generic piece of mal
Re: (Score:2)
I can think of one reason that kinda makes sense, and that's getting access to an image that's going to be spread into the cloud, but that seems like such an insanely specialized usecase that I don't grok why it's included in a generic piece of malware.
I take it you've never written a virus? It is like a game. You create a piece of code that functions like a living organism inside the ecosystem of the computer. It has one overriding function, survival. The whole point of a virus is to live for as long as
Re: (Score:2)
Re: (Score:2)
Previous post re: serious applications
http://slashdot.org/comments.pl?sid=3065739&cid=41087425 [slashdot.org]
Re: (Score:2)
Why on earth would you want to do that?
The same reason malware might want to compromise a printer or other network device. It's a place the malware can hide on the network, from AV scanners.
Another trick would be for the malware to create a VM of its own running a general purpose OS, or create a nested VM situation to run its malware payload.
Any of those techniques can accomplish the objective of allowing remote usage of the host's CPU and callback to the malware author to receive work
Re: (Score:2)
Re: (Score:1)
According to the article, the malware looks for virtual machine files on the host PC (for example a windows box running VMWare Player) and mounts the image. It then adds itself to the image.
This is not a vulnerability in VMWare Player or ESXi. It's just a better mousetrap that mounts virtual hard disks and infects them.
Re: (Score:2)
Re: (Score:2)
Also, I bet that often times a non-privileged user can infect the privileged area of a VM set to be run-able by that user.
Re: (Score:2)
If the user has physical access to a machine, then they have privileged access to that machine, and every virtual machine and local software run on that physical machine while they have physical access to it.
Re: (Score:1)
Yes, the user the person does obviously, but that does not necessarily imply that the user the account do.
I think the risk is that the user account essentially has physical access to the virtual machine. I've read many a post here recommending all banking be done from a virtual machine that only goes to a bank's website. This malware demonstrates why that's poor advice by taking advantage of software's "physical" access to a machine
Re: (Score:2)
This malware demonstrates why that's poor advice by taking advantage of software's "physical" access to a machine
A keylogger on the host can still capture keystrokes sent to a guest VM.
It's sound advise, but missing an an important additional proviso:
In addition to doing banking in a banking VM, the web browser on the host, and all software other than virtualization software should be disabled and removed
A new separate Virtual machine should be created for all non-Banking activity.
Any program r
It's evolving... (Score:1)
First Mac, then Windows... Windows Mobile... What if it mutates and becomes human-human transmissible??!!! SAVE US!!!
Re: (Score:3)
I'm surprised it doesn't have adb and look for an attached Android phone to infect as well.
Though, given it's multiplatform, it's also interesting that it skips out having a Linux vector - you'd think if you went to al lthe trouble of making a Mac OS X version, you'd also do Linux for not-very-much-more effort. Scanning for VMs on Linux and infecting those is also pretty profitable (especiall
Re: (Score:2)
STOP READING SLASHDORT NOW or things will be worse and money.
...but I want money, so I will read Slashdort.
Re: (Score:1)
I like money
Re: (Score:2)
Re: (Score:2)
Do we have time to go to Starbucks? I'd like a Gentleman's Latte with full release.
Re: (Score:1)
No, the installer itself does not run with normal user permissions. These trojans require the user to voluntarily choose to install it thus granting them elevated permissions in the process. You would have a point if this was a drive-by exploit, but its not.
Re: (Score:2)
Other trojans, though, start by exploiting a bug in Java, Flash or AdobePdf... then they're either content with running with normal user privileges (with which you can still do a lot of harm), or they use a privilege escalation exploit (present in all common desktop OSes - some just not known widely because it's more profitable to keep them private for very targeted attacks) - and b00m, you're owned.
It's hard to write bugfree software, sure, but the unholy trio above is appalling.
Re: (Score:1)
Re:ok (Score:5, Informative)
ESXi is not Linux [wikipedia.org] in and of itself, it is a Hypervisor [wikipedia.org]. ESXi boots a minimal Linux kernel, which then loads vmkernel (the Hypervisor) along with some other virtualization components. After vmkernel is loaded, it takes direct control of the hardware and partitions the Linux kernel off into the first VM with a custom BusyBox shell (compiled for vmkernel support) as the Service Console. While the vmkernel does utilize a proc filesystem and some modified linux kmods for 3rd party device driver support, it in and of itself is a microkernel and does not nearly contain all of the Linux API's. It has very few ways to communicate with the outside world, one of them being the Service Console itself. But you can literally crash (and reboot) or CPU bound the Service Console up completely and have little to no effect on the other VM's running on that host.
ESX did contain a mostly complete Linux distro that was also cast off into a guest VM after vmkernel loaded. This Service Console was based off of RHEL, but they've abandoned ESX support in the latest versions of their Hypervisor releases and it will eventually be EOL [vmware.com].
Re: (Score:3)
ESXi boots a minimal Linux kernel, which then loads vmkernel (the Hypervisor) along with some other virtualization components.
No... there is no "Linux" kernel that ESXi contains, as the service console was completely removed, there is only the VMkernel; there are some superficial similarities between the Tech support ESXi shell and a Linux shell, much in the same way as there are some superficial similarities between a command shell interface on AIX and Linux.
However, the VMkernel contains compone
Re: (Score:2)
VMware's ESXi documentation doesn't really go into much detail about how the boot process works in ESXi, or how it's different between ESX vs ESXi.
Re: (Score:2)
The ESXi shell is not an OS, but a process
I've even managed to lock up the busybox shell doing things like forcing an unused datastore to unmount, you would think doing things like this directly upon vmkernel would be a bad idea and have the potential to disrupt VM's running on the host
Well, it certainly would, if any VM were running on the datastore, and you were actually successful. It's more likely you just broke the shell, and the management world was still running happily.
Everything on the VMker
+1 to redundancy in the summary (Score:1)
+1 to redundancy in the summary
JAR File? (Score:2)
Am I the first to make this joke? (Score:5, Funny)
So as it turns out, yes, VMWare can run Crysis. Er, Crisis.
Oh no, not Windows Mobile! (Score:4, Funny)
Re: (Score:2)
This will be disasterous for tens of people!
I believe you may be in error on that.... last I heard, the remaining 10 people using windows Mobile have since been assimilated, and joined Balmer's army of Windows-using (formerly human) Zombies, as a result, the total count is 0 of the mobile users effected are people.