Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Crisis Trojan Makes Its Way Onto Virtual Machines

Soulskill posted more than 2 years ago | from the virtual-security dept.

Security 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."

Sorry! There are no comments related to the filter you selected.

err, A virtual machine is not a machine? (2)

dudacgf (757927) | more than 2 years ago | (#41086125)

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?

Re:err, A virtual machine is not a machine? (0)

Anonymous Coward | more than 2 years ago | (#41086165)

I also don't get it. Do they mean that it can "break out" from the VM? Because THAT would be scary...

Re:err, A virtual machine is not a machine? (5, Informative)

Sarten-X (1102295) | more than 2 years ago | (#41086229)

Other way around: It can break into a VM from a Windows host. From TFA:

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:err, A virtual machine is not a machine? (1)

Desler (1608317) | more than 2 years ago | (#41086491)

'Breaking in' implies that it had to bypass some security mechanism, but that isn't the case.

ah don't get it (1)

Thud457 (234763) | more than 2 years ago | (#41086829)

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?

Re:ah don't get it (2)

crunch_ca (972937) | more than 2 years ago | (#41086981)

I imagine this might be of concern to shared hosting sites.

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:ah don't get it (1)

Jeremiah Cornelius (137) | more than 2 years ago | (#41088153)

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:ah don't get it (2)

dave562 (969951) | more than 2 years ago | (#41087425)

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 can setup a golden image VM and use that VM to clone out all other subsequent VMs.

Re:err, A virtual machine is not a machine? (2)

Jeremiah Cornelius (137) | more than 2 years ago | (#41088097)

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:err, A virtual machine is not a machine? (2)

RMingin (985478) | more than 2 years ago | (#41086857)

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:err, A virtual machine is not a machine? (1)

snemarch (1086057) | more than 2 years ago | (#41086945)

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 malware.

Re:err, A virtual machine is not a machine? (1)

dave562 (969951) | more than 2 years ago | (#41087545)

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 possible. In order to do that, it spreads as widely as possible. There are only so many places to hide on a computer. MFT/GPT on the hard disk. RAM. Video memory. Files. A few others.

A VM is just another place for the virus to hide so that it can live a little longer and fulfill its second purpose.. replication.

Re:err, A virtual machine is not a machine? (1)

snemarch (1086057) | more than 2 years ago | (#41091571)

The days where people wrote malware for fun & fame are long gone - today it's serious business with big money involved. You don't add features for shit & giggles, and for "let's build ourselves a botnet" or "let's harvest as many CC numbers and login credentials", you don't spend time adding code that will only affect a (relatively) few users.

Re:err, A virtual machine is not a machine? (1)

mysidia (191772) | more than 2 years ago | (#41090191)

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:err, A virtual machine is not a machine? (1)

Zero__Kelvin (151819) | more than 2 years ago | (#41089995)

Why the hell would it be any more scary? Are you unaware that many companies use virtualization to run their critical services?

Re:err, A virtual machine is not a machine? (1)

EmagGeek (574360) | more than 2 years ago | (#41086235)

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:err, A virtual machine is not a machine? (1)

Sarten-X (1102295) | more than 2 years ago | (#41086267)

The attack surface of a VM is (surface of the guest) + (surface of the host). In this case, an infected Windows host can infect a VM image residing there.

Re:err, A virtual machine is not a machine? (2)

AvitarX (172628) | more than 2 years ago | (#41086821)

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:err, A virtual machine is not a machine? (1)

mysidia (191772) | more than 2 years ago | (#41090227)

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:err, A virtual machine is not a machine? (1)

AvitarX (172628) | more than 2 years ago | (#41097279)

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:err, A virtual machine is not a machine? (1)

mysidia (191772) | more than 2 years ago | (#41103805)

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 run on the physical computer would be a risk.

If all risky activities are done in a VM, and all secure activities are done in a different VM, the configuration of the risky VM is edited to disable copy and paste, and enable isolation functionality (such as disablement of folders shared with the host, and running programs on the host via the VMware backdoor), and the virtualization software is kept up to date,

Then the secure VM will be protected from most threats, other than possibly network-based Man in the Middle attacks.

The possibility of man in the middle attacks by an infected normal-use VM could be mitigated by bridging the different VMs to different NICs on different LANS behind different routers

It's evolving... (1)

Fatch Racall (2330110) | more than 2 years ago | (#41086213)

First Mac, then Windows... Windows Mobile... What if it mutates and becomes human-human transmissible??!!! SAVE US!!!

Re:It's evolving... (2)

tlhIngan (30335) | more than 2 years ago | (#41087631)

First Mac, then Windows... Windows Mobile... What if it mutates and becomes human-human transmissible??!!! SAVE US!!!

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 (especially if you go after VMWare AND VirtualBox).

Re:It's evolving... (0)

Anonymous Coward | more than 2 years ago | (#41088107)

It also has found a way to spread to Windows Mobile devices

All three of them!

Viroses are good for you (1)

For a Free Internet (1594621) | more than 2 years ago | (#41086249)

I want to be a dnacer. I will amuse the audience with my daring leaps and twirls!!!!! DNACER I WILL BE, so there hellooooooooOOO HOLLYWOOD you cannot touch my butt. without EXPRESS pormishin. Comrades, this is what hapens when you read slashdort. SO STOP READING SLASHDORT NOW or things will be worse and money.

Re:Viroses are good for you (1)

Sarten-X (1102295) | more than 2 years ago | (#41086289)

STOP READING SLASHDORT NOW or things will be worse and money.

...but I want money, so I will read Slashdort.

Re:Viroses are good for you (0)

Anonymous Coward | more than 2 years ago | (#41086411)

Where is this Slashdort that bestows wealth upon its readers?

Re:Viroses are good for you (1)

Anonymous Coward | more than 2 years ago | (#41086421)

I like money

Re:Viroses are good for you (2)

denvergeek (1184943) | more than 2 years ago | (#41086453)

I can't believe you like money too. We should hang out.

Re:Viroses are good for you (1)

Jaktar (975138) | more than 2 years ago | (#41087795)

Do we have time to go to Starbucks? I'd like a Gentleman's Latte with full release.

Java is the vector again (0)

Anonymous Coward | more than 2 years ago | (#41086261)

once again its Java that the exploit uses, its a security risk out of the box, remove java and adobes PDF reader and 95% of this crap stops.
Oracle need to be spanked in the wallet for anything to change, it comes pre-installed on so many desktops and as soon as you connect to the web and hit the wrong site you are pwned.
exploitable from the start

Firefox/Opera need to disable Java in the browser permanently, its just too risky to have it installed

Re:Java is the vector again (0)

Anonymous Coward | more than 2 years ago | (#41086393)

Oracle wasn't the one who pushed the Java malware on the masses. They are just the latest purveyor. We should retroactively sue Sun for this massive malware infection.

Re:Java is the vector again (0)

Anonymous Coward | more than 2 years ago | (#41086425)

So you are saying that if I uninstall Java then I won't get infected by virus/trojan/etc. that uses Java? And if I uninstall Adobe products that I won't get infected by virus/trojan/etc. that uses Adobe products as a vector? Wow. What about viruses written in native x86 code? Should I uninstall all native programs too? I think you are confusing the vector with the problem.

It shouldn't matter what program I run under a user account, that program shouldn't be allowed to infect the operating system. In fact, such a program pretty much shouldn't be able to *affect* the operating system. Neither Java or Adobe products have magical powers. They run under a user account same as other programs.

It is the fault of the operating system if a userland program can corrupt the operating system. Plain and simple. Now where do we assign blame for faulty operating systems...?

Re:Java is the vector again (1)

Desler (1608317) | more than 2 years ago | (#41086545)

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:Java is the vector again (1)

snemarch (1086057) | more than 2 years ago | (#41087187)

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.

ok (0)

Anonymous Coward | more than 2 years ago | (#41086273)

So it searches a compromised system for resident VMimages and then copies its self to the disk image so when it runs that image is already compromised. This is different than saying its infecting VMware, like ESXi. Which should have no images stored on an infected machine. so this is to infect VM workstation or player images?

Re:ok (0)

kelemvor4 (1980226) | more than 2 years ago | (#41086775)

It only affects windows and mac systems. ESXi is Linux.

Re:ok (4, Informative)

EXrider (756168) | more than 2 years ago | (#41087803)

It only affects windows and mac systems. ESXi is Linux.

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:ok (2)

mysidia (191772) | more than 2 years ago | (#41090291)

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.

Re:ok (1)

EXrider (756168) | more than 2 years ago | (#41094615)

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.

Re:ok (1)

mysidia (191772) | more than 2 years ago | (#41103711)

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.

+1 to redundancy in the summary (0)

zrbyte (1666979) | more than 2 years ago | (#41086321)

+1 to redundancy in the summary

JAR File? (1)

Sesostris III (730910) | more than 2 years ago | (#41086473)

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!

Am I the first to make this joke? (5, Funny)

gman003 (1693318) | more than 2 years ago | (#41086543)

So as it turns out, yes, VMWare can run Crysis. Er, Crisis.

Oh no, not Windows Mobile! (3, Funny)

epp_b (944299) | more than 2 years ago | (#41089767)

This will be disasterous for tens of people!

Re:Oh no, not Windows Mobile! (1)

mysidia (191772) | more than 2 years ago | (#41090317)

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.

Re:Oh no, not Windows Mobile! (0)

Anonymous Coward | more than 2 years ago | (#41091513)

Your spelling's "disasterous" (disastrous). My eyes!!!

VMware View (0)

Anonymous Coward | more than 2 years ago | (#41092687)

The major problem with this is VMware View with Local Mode, which places use as it's more secure for laptop users on a BYOD deal or external contractors.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?