Slashdot Mirror
Crisis Trojan Makes Its Way Onto Virtual Machines
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."
like any one else? The attack surface is not the same as any other windows physical machine? What is the point, there's an anti-virus vendor waiting to sell vmware specific software?
First Mac, then Windows... Windows Mobile... What if it mutates and becomes human-human transmissible??!!! SAVE US!!!
#include <disclaimer.h>
STOP READING SLASHDORT NOW or things will be worse and money.
...but I want money, so I will read Slashdort.
You do not have a moral or legal right to do absolutely anything you want.
I like money
I can't believe you like money too. We should hang out.
Presumably this means that the affected host systems must have Java installed. Seems to me a brilliant example of the "Write Once, Run Anywhere" paradigm!
You never know what is enough unless you know what is more than enough. - Blake
So as it turns out, yes, VMWare can run Crysis. Er, Crisis.
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.
If the host is already infected, what's the advantage to be gained by infecting the images?
N^HLeo just needs to wake up before the van hits the water. Right?
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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.
Coffee-driven development.
Do we have time to go to Starbucks? I'd like a Gentleman's Latte with full release.
ESXi is not Linux in and of itself, it is a Hypervisor. 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.
grep -iw skynet
This will be disasterous for tens of people!
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 components that are derived from Linux, such as the driver system, and various drivers, so you could legitimately say that ESXi is a mixture of Linux code and some proprietary code in the same package.
I dunno, as far as I can tell, its difficult to make an assertion either way, unless you're an engineer that works for VMware. The Wikipedia page that I linked to says that this is how the bootstrap process still works in ESXi v5, so that's what I was going off of, you'd think a VMware person would come along and correct that article if that weren't the case.
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. In our environment, I can still enable SSH on ESXi 5 hosts, log into them and pretty much have all the commands available in a typical BusyBox environment as well as some proprietary ESX-related commands...
~ # uname -a VMkernel TSTESX01.local 5.0.0 #1 SMP Release build-474610 Aug 26 2011 13:51:17 x86_64 unknown
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, but there were no ill effects. You can still configure resource limits and reservations for the system in ESXi, which directly relates to the "Tech Support shell". So it appears that the tech support shell runs in its own sandbox or VM to limit its resources. That's what gave me the impression that the bootstrap process still works similar to how it did in ESX, except that the Service Console is now slimmed down, hidden by default and it's use for management tasks in ESXi is now unsupported by VMware.
grep -iw skynet
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 VMkernel, including the Tech support console runs in their schedulable entities that they call Worlds, which has similarities to the Linux concept of a process.
Sure it's possible to break your shell, or get it hung up. But the world your tech support console is executed by a separate world, it's not the same as the various other worlds on the system, that the various VMs run in.