Slashdot Mirror

← Back to Stories (view on slashdot.org)

Crisis Trojan Makes Its Way Onto Virtual Machines

Posted by Soulskill on from the virtual-security dept.

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

49 comments

  1. err, A virtual machine is not a machine? by dudacgf · · Score: 2

    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?

    1. Re:err, A virtual machine is not a machine? by Anonymous Coward · · Score: 0

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

    2. Re:err, A virtual machine is not a machine? by Sarten-X · · Score: 5, Informative
      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.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    3. Re:err, A virtual machine is not a machine? by EmagGeek · · 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.

    4. Re:err, A virtual machine is not a machine? by Sarten-X · · Score: 1

      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.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    5. Re:err, A virtual machine is not a machine? by Desler · · Score: 1

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

    6. Re:err, A virtual machine is not a machine? by AvitarX · · 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.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    7. Re:err, A virtual machine is not a machine? by RMingin · · Score: 2

      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.

      --
      The preceding comment is my own, and in no way construes an opinon of the Emperor of Mankind.
    8. Re:err, A virtual machine is not a machine? by snemarch · · Score: 1

      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.

      --
      Coffee-driven development.
    9. Re:err, A virtual machine is not a machine? by dave562 · · Score: 1

      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.

    10. Re:err, A virtual machine is not a machine? by Jeremiah+Cornelius · · Score: 2

      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.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    11. Re:err, A virtual machine is not a machine? by Zero__Kelvin · · Score: 1

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

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    12. Re:err, A virtual machine is not a machine? by mysidia · · Score: 1

      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

    13. Re:err, A virtual machine is not a machine? by mysidia · · Score: 1

      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.

    14. Re:err, A virtual machine is not a machine? by snemarch · · Score: 1

      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.

      --
      Coffee-driven development.
    15. Re:err, A virtual machine is not a machine? by dave562 · · Score: 1

      Previous post re: serious applications

      http://slashdot.org/comments.pl?sid=3065739&cid=41087425

    16. Re:err, A virtual machine is not a machine? by AvitarX · · 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

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    17. Re:err, A virtual machine is not a machine? by mysidia · · Score: 1

      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

  2. It's evolving... by Fatch+Racall · · Score: 1

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

    --
    #include <disclaimer.h>
    1. Re:It's evolving... by tlhIngan · · Score: 2

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

    2. Re:It's evolving... by Anonymous Coward · · Score: 0

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

      All three of them!

  3. Java is the vector again by Anonymous Coward · · Score: 0

    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

    1. Re:Java is the vector again by Anonymous Coward · · Score: 0

      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.

    2. Re:Java is the vector again by Anonymous Coward · · Score: 0

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

    3. Re:Java is the vector again by Desler · · 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.

    4. Re:Java is the vector again by snemarch · · Score: 1

      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.
  4. ok by Anonymous Coward · · Score: 0

    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?

    1. Re:ok by kelemvor4 · · Score: 0

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

    2. Re:ok by EXrider · · Score: 4, Informative

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

      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 /etc/services
    3. Re:ok by mysidia · · Score: 2

      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.

    4. Re:ok by EXrider · · Score: 1

      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 /etc/services
    5. Re:ok by mysidia · · Score: 1

      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.

  5. Re:Viroses are good for you by Sarten-X · · Score: 1

    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.
  6. +1 to redundancy in the summary by zrbyte · · Score: 0

    +1 to redundancy in the summary

  7. Re:Viroses are good for you by Anonymous Coward · · Score: 0

    Where is this Slashdort that bestows wealth upon its readers?

  8. Re:Viroses are good for you by Anonymous Coward · · Score: 1

    I like money

  9. Re:Viroses are good for you by denvergeek · · Score: 2

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

  10. JAR File? by Sesostris+III · · Score: 1

    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
  11. Am I the first to make this joke? by gman003 · · Score: 5, Funny

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

  12. ah don't get it by Thud457 · · Score: 1

    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

    1. Re:ah don't get it by crunch_ca · · Score: 2
      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.

    2. Re:ah don't get it by dave562 · · Score: 2

      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.

    3. Re:ah don't get it by Jeremiah+Cornelius · · Score: 1

      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.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
  13. Re:Viroses are good for you by __aaqvdr516 · · Score: 1

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

  14. Oh no, not Windows Mobile! by epp_b · · Score: 3, Funny

    This will be disasterous for tens of people!

    1. Re:Oh no, not Windows Mobile! by mysidia · · Score: 1

      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.

    2. Re:Oh no, not Windows Mobile! by Anonymous Coward · · Score: 0

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

  15. VMware View by Anonymous Coward · · Score: 0

    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.