The Virtual Machine Trojan

29 views
Skip to first unread message

Reuven Cohen

unread,
Apr 21, 2009, 8:46:14 AM4/21/09
to cloud...@googlegroups.com
Sergio Castro has released a functional, open source Virtual Machine Trojan called ViMTruder. I've held off for a few days before posting this news. I wasn't sure if helping spread the news would do more harm then good but, several other blogs have picked up the story, so why not.

So what is a Virtual Machine Trojan? According to Castro virtual machine trojans are seemingly benign virtual machine you download from the Internet contains a trojan. The objective of the trojan is to remotely take control of the machine for nefarious purposes: steal information, send spam, conduct click fraud, stage denial of service attacks within a botnet, etc.

ViMtruder is written in Python and consists of a client which is installed within a virtual machine, and a control server, which sits in a host on the Internet. The virtual machine, running Linux, is configured to automatically run the VMT client in the background upon boot up. The VMT tries periodically to contact the control server through the Internet using port 80 outbound. Once the control server links with the VMT, you can send it Nmap commands to scan the target LAN where the VMT is connected.

The types of attacks a VMT can execute are different than a normal trojan. The VMT does not have access to the host machine; rather, it has access to the local network. Therefore, a VMT can be programmed to do the following:

1) Sniff traffic in the local network
2) Actively scan the local network to detect machines, ports and services
3) Do a vulnerability scan to detect exploitable machines in the local network
4) Execute exploits  in the local network
5) Brute force attacks against services such as ftp and ssh
6) Launch DoS attacks within the local network, or against external hosts
7) And of course, send spam and conduct click fraud

My first thought is imagine something like this embedded into an EC2 AMI and the potential damage it would cause.

Direct Link:
http://code.google.com/p/vimtruder/

--
-
Reuven
CCIF Instigator

Geir Magnusson Jr.

unread,
Apr 21, 2009, 8:54:14 AM4/21/09
to cloud...@googlegroups.com
From the title, I thought this was a product advertisement that got through moderation for cloud computing prophylactics


geir

Geir Magnusson Jr.

unread,
Apr 21, 2009, 9:02:34 AM4/21/09
to cloud...@googlegroups.com
Serious question - Hasn't everyone thought of this the first time (or every time) they start a VM on EC2?  I use the ubuntu images from alestic since I can't fathom what Canonical is trying to achieve with their beta program, and every time start an image, that thought goes through my head.

I keep going because I tend to be doing things like testing OSS software, so don't really care, and also assume that someone else has looked over the setup :)

geir

On Apr 21, 2009, at 8:46 AM, Reuven Cohen wrote:

Jorge Oliveira

unread,
Apr 21, 2009, 9:08:38 AM4/21/09
to cloud...@googlegroups.com
This is just a matter of concept - no news there...

For example, on windows machines, one could simply bundle a virtual machine with some other trojan software installed and, because most of us would not run antivirus software on a virtual machine, it would never be detected.

Jorge Oliveira

Chris Marino

unread,
Apr 21, 2009, 9:23:28 AM4/21/09
to cloud...@googlegroups.com
Geir, I certainly have. I think this is another of the 'don't ask, don't tell' risks of AWS and other IaaS providers. But then again really no different from any other software dowload you might find at SourceForge, etc. And, anyone that's sophisticated enough to download a VM and run it ought to know better.

Caveat emptor will probably work at this nacent stage of CC, but if anyone needs another reason why there are still serious conserns w.r.t CC security, they don't have to look any farther than this.
CM

Sam Johnston

unread,
Apr 21, 2009, 9:25:19 AM4/21/09
to cloud...@googlegroups.com
On Tue, Apr 21, 2009 at 3:02 PM, Geir Magnusson Jr. <ge...@pobox.com> wrote:
Serious question - Hasn't everyone thought of this the first time (or every time) they start a VM on EC2?  I use the ubuntu images from alestic since I can't fathom what Canonical is trying to achieve with their beta program, and every time start an image, that thought goes through my head.

I keep going because I tend to be doing things like testing OSS software, so don't really care, and also assume that someone else has looked over the setup :)

Yeah this is an undiscovery if I've ever seen one (and yet another off-topic blog post spam - there's only so many ways one can say "stop").

Exactly the same concerns apply to hardware appliances and pretty much every piece of software ever written, and in today's environment the bigger risk comes from trojans installed post-deployment. The only difference with appliances is that having OS cruft doesn't help because it creates many nooks and crannies in which to hide evil. Reducing the size of the workload as much as possible and making what remains open to inspection is arguably the best solution (that's one key advantage of cloud platforms over infrastructure).

Another thing to consider is the incentives of the virtual appliance manufacturer... if a company like JumpBox were to have been found to have shipped a trojan (even for "legitimate" support purposes) they'd be unlikely to survive the resulting backlash.

In other news dog bites man, film at 11.

Sam

Geir Magnusson Jr.

unread,
Apr 21, 2009, 1:59:20 PM4/21/09
to cloud...@googlegroups.com
I'm not convinced this is as off-topic as you think.

geir

Reuven Cohen

unread,
Apr 21, 2009, 2:08:38 PM4/21/09
to cloud...@googlegroups.com
Given the conversations around the dangers of VM portability and packaging last week, this type of functional VM trojan is a perfect example of the problems facing IasS offerings such as Amazon Ec2

I think the bigger issue is that of due diligence when using a random VM or in the case of Amazon a random AMI. Realistically, if you're going to use a virtual appliance provided by some else, you should do you homework -- especially if you decide to use it in a production environment.

r/c

Alex Esterkin

unread,
Apr 21, 2009, 3:01:39 PM4/21/09
to cloud...@googlegroups.com
I fully agree with Geir.   This could affect interoperability standards.    For example, CCUser-VM communication may need to be encrypted, use communication endpoints, use IPSec, etc.   Certain hypervisor services may need to be added or standardized. ...

Regards,
Alex Esterkin

Matthew Zito

unread,
Apr 21, 2009, 3:04:53 PM4/21/09
to cloud...@googlegroups.com


Just to be clear, the issue being discussed originally on this thread isn't someone maliciously controlling a hypervisor from inside a VM, which I agree is a real concern with cloud computing environments. 

It's someone who made a pre-built virtual appliance with a trojan on it.  Encrypting communications between the hypervisor and the OS, ipsec, etc., none of that will help.  The only thing that would help with this is a "trusted" virtual appliance - that is, someone certifying that there's no bad mojo embedded in a virtual appliance or VM.

Matt

--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mz...@gridapp.com
http://www.gridapp.com

>> off-topic blog post spam<http://www.elasticvapor.com/2009/04/introducing-virtual-machine-trojan.html>- there's only so many ways one can say "stop").


>>
>> Exactly the same concerns apply to hardware appliances and pretty much
>> every piece of software ever written, and in today's environment the bigger
>> risk comes from trojans installed post-deployment. The only difference with
>> appliances is that having OS cruft doesn't help because it creates many
>> nooks and crannies in which to hide evil. Reducing the size of the workload
>> as much as possible and making what remains open to inspection is arguably
>> the best solution (that's one key advantage of cloud platforms over
>> infrastructure).
>>
>> Another thing to consider is the incentives of the virtual appliance
>> manufacturer... if a company like JumpBox were to have been found to have
>> shipped a trojan (even for "legitimate" support purposes) they'd be unlikely
>> to survive the resulting backlash.
>>
>> In other news dog bites man, film at 11.
>>
>> Sam
>>
>> On Apr 21, 2009, at 8:46 AM, Reuven Cohen wrote:
>>>

>>> Sergio Castro <http://www.infosegura.net/VMTthreat.html> has released a functional,
>>> open source Virtual Machine Trojan called ViMTruder<http://code.google.com/p/vimtruder/>.


>>> I've held off for a few days before posting this news. I wasn't sure if
>>> helping spread the news would do more harm then good but, several other
>>> blogs have picked up the story, so why not.
>>>
>>> So what is a Virtual Machine Trojan? According to Castro virtual machine
>>> trojans are seemingly benign virtual machine you download from the Internet
>>> contains a trojan. The objective of the trojan is to remotely take
>>> control of the machine for nefarious purposes: steal information, send spam,
>>> conduct click fraud, stage denial of service attacks within a botnet, etc.
>>>

>>> ViMtruder is written in <http://www.infosegura.net/vimtruder.html>Python<http://www.infosegura.net/vimtruder.html>andconsists of a client which is installed within a virtual machine, and a

Sam Johnston

unread,
Apr 21, 2009, 3:33:13 PM4/21/09
to cloud...@googlegroups.com
On Tue, Apr 21, 2009 at 9:04 PM, Matthew Zito <mz...@gridapp.com> wrote:
Just to be clear, the issue being discussed originally on this thread isn't someone maliciously controlling a hypervisor from inside a VM, which I agree is a real concern with cloud computing environments. 

It's someone who made a pre-built virtual appliance with a trojan on it.  Encrypting communications between the hypervisor and the OS, ipsec, etc., none of that will help.  The only thing that would help with this is a "trusted" virtual appliance - that is, someone certifying that there's no bad mojo embedded in a virtual appliance or VM.

Right and this is not at all a new problem. It just got a lot harder (people have suggested virus scanners and good luck with that) but that's part of the reason people will quickly move on from infrastructure. It was framed as breaking news but if the concept is actually new to anyone here then we have bigger issues to deal with.

The CCIF was founded to tacke interoperability and has to date achieved little of any consequence towards that goal. I'm all for security talk (I'm a CISSP myself) but there's a perfectly good forum for that over there.

Sam

Pat Wendorf

unread,
Apr 21, 2009, 3:33:17 PM4/21/09
to cloud...@googlegroups.com
I think from this conversation (and a few others previously) we can identify 4 places where VM's can be corrupted in a cloud infrastructure:

@creation time - Vendor or malicious employee puts some sort of malware on the source image.  You'd have to trust the image creator.
@transfer time - The point at which the image is being uploaded or moved between sites.  You'd have to trust the cloud network.
@provision time - The point in time before the disk image is started and the file system can be modified on the host.  You'd have to trust the hosting provider.
@run time - Hypervisor level exploits and traditional sysadmin security issues.  You'd have to trust your admin to properly maintain the image, but again trust your hosting provider that the hypervisor is secured somehow.

You can resolve the first problem by making you own images and appliances, or working with a team that you trust to build these images.  The second and third and fourth problems are mostly cloud service provider issues which you may not have control over, in any way.  Even the traditional sysadmin work can be potentially tricky with 100's of VM's running with various different OS's, packages and patch levels.

I think all of these potential vectors deserve some think-time.

- Pat

Eric Windisch

unread,
Apr 21, 2009, 3:35:20 PM4/21/09
to cloud...@googlegroups.com


It's someone who made a pre-built virtual appliance with a trojan on it.  Encrypting communications between the hypervisor and the OS, ipsec, etc., none of that will help.  The only thing that would help with this is a "trusted" virtual appliance - that is, someone certifying that there's no bad mojo embedded in a virtual appliance or VM.


Essentially, one must trust the source of their software.  Perhaps this is just the Linux/Unix user coming out in me -- but how is this any different than any other software?  You must always trust the source of your software.  Are users that deeply indoctrinated into the anti-virus software propaganda that says not to trust your vendors, or your software, just rely on another source/vendor to "watch your back", that this can in any way be seen as a new problem?

However, moving forward, virtual machine introspection will provide an ability to help provide a level of protection against malware that was unobtainable in pre-virtualization environments.  Projects like XenAccess have already turned this proof of concept into a reality, and I'm certain that such capabilities will eventually become a standard and expected feature of any virtualization platform.

--
Eric Windisch

Eric Windisch

unread,
Apr 21, 2009, 3:52:00 PM4/21/09
to cloud...@googlegroups.com

On Apr 21, 2009, at 3:33 PM, Pat Wendorf wrote:

> I think from this conversation (and a few others previously) we can
> identify 4 places where VM's can be corrupted in a cloud
> infrastructure:

Now, this is something that is more interesting, the risk of
modification of a trusted image in the process of moving it around
after its creation!

There would be a solution here in digitally signing the images.
Hosts should only boot the images that are sent to them if they're
signed by a signatory trusted by the host. That signatory might be a
trusted vendor, or the client. That way, if clients don't
necessarily trust the VM creator, but trust their host, and their host
trusts the VM creator, the image will run. On the other hand, if the
client trusts the VM creator, but the host doesn't, but the host
trusts the client, then the VM can also run. Finally, if neither the
client nor the host trust the VM, it won't run.

This basically solves all the problems except trusting the host. For
that, there isn't a lot you can do other than using encryption on the
VM, and even then you're still quite a bit at their mercy.

--
Eric Windisch

Sam Johnston

unread,
Apr 21, 2009, 5:37:37 PM4/21/09
to cloudforum
On Tue, Apr 21, 2009 at 2:46 PM, Reuven Cohen <r...@enomaly.com> wrote:
Therefore, a VMT can be programmed to do the following:

1) Sniff traffic in the local network
2) Actively scan the local network to detect machines, ports and services
3) Do a vulnerability scan to detect exploitable machines in the local network
4) Execute exploits  in the local network
5) Brute force attacks against services such as ftp and ssh
6) Launch DoS attacks within the local network, or against external hosts
7) And of course, send spam and conduct click fraud

My first thought is imagine something like this embedded into an EC2 AMI and the potential damage it would cause.

Ok so I've reviewed the post again (and again) to see if I was off base before and I'm still having real trouble swallowing it as anything other than complete and utter FUD... substitute "a VMT"(!?!) with "any software" and all of these points still apply just as much as they have since the beginning of [unix] time. I'm glad attention is being drawn to this important (albeit blatantly obvious) issue but I won't accept the way it's being done, by a self-proclaimed thought leader no less.

The thing that really doesn't sit well with me is that Enomaly will shortly (assuming they haven't already) announce product for securely managing virtual machines which will invariably [cl]aim to tackle many of these "issues". This comes right back to my earlier comment about their "pissing in the pool" and I fail to see how this overt FUD is any different. Most of us are working very hard to build trust in cloud computing and the last thing we need is our self-appointed one-man PR department selling us out.

I'm trying to like Enomaly - I really, really am - as I think they have the potential to fill an important void that I have no interest in filling myself. I even recommended them as a company to watch in a call with an analyst today and am working on a blog post about their new strategy as I think their brand new CEO has the potential to turn things around.

However, until Reuven realises that he's just another vendor rather than an independent analyst and starts to act accordingly, me and my sixth sense will be here to keep things on an even keel. Given he clearly has no interest in removing or recusing himself from such conflicts of interest the least he could do is declare them.

Sam

Matthew Zito

unread,
Apr 21, 2009, 5:47:23 PM4/21/09
to cloud...@googlegroups.com

I won’t necessarily agree with the personal slant Sam is taking, but I will agree that this is a silly discussion.  In fact, if anything, Amazon is way ahead of the curve by digitally signing and encrypting AMIs while they reside on S3.  All of the issues are true with any software we download – after all, how many people actually verify the MD5 checksums of the software they download, or read the source code of some random app on github to verify that there’s nothing malicious in the code?

 

The only difference here is that on-demand infrastructures and virtual appliances are new and shiny, and people haven’t started ignoring these issues yet, as they have in other areas.

 

Matt

 


From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Sam Johnston
Sent: Tuesday, April 21, 2009 5:38 PM
To: cloudforum
Subject: Re: The Virtual Machine Trojan

 

On Tue, Apr 21, 2009 at 2:46 PM, Reuven Cohen <r...@enomaly.com> wrote:

Pablo Serber

unread,
Apr 21, 2009, 6:26:59 PM4/21/09
to cloud...@googlegroups.com
Yeap, Sam. I do agree with you. (again). +1.

if you are an IT professional, you must confirm/trust your software sources ( see CIA triangle - Integrity). this is nothing new. It is not even close to be worth a couple of emails. ;-)


Cheers.
Pablo

Eric Windisch

unread,
Apr 21, 2009, 6:31:00 PM4/21/09
to cloud...@googlegroups.com

On Apr 21, 2009, at 5:37 PM, Sam Johnston wrote:

On Tue, Apr 21, 2009 at 2:46 PM, Reuven Cohen <r...@enomaly.com> wrote:
1) Sniff traffic in the local network
2) Actively scan the local network to detect machines, ports and services
3) Do a vulnerability scan to detect exploitable machines in the local network
4) Execute exploits  in the local network
5) Brute force attacks against services such as ftp and ssh
6) Launch DoS attacks within the local network, or against external hosts
7) And of course, send spam and conduct click fraud

This list is most ridiculous thing I've read in a while.  Thanks for the laugh.

Basically, you're saying that those building infrastructure must... build infrastructure.   Systems and network administrators should deploy routed networking, netflow, IDS, etc.   Basically, they have to do the same jobs that they're doing now, or if they're not doing those jobs already, continue to ignore the obvious.  Wow, gee, thanks for the insight!

Then again, this isn't quite as bad as what I heard at CloudCamp@NYC, that Systems Administrators are now taking scripting and programming courses.   If you don't know how to script and don't have programming experience, you're either not a Systems Administrator, or you're a bad one.

--
Eric Windisch

Christofer Hoff

unread,
Apr 30, 2009, 5:57:34 PM4/30/09
to cloud...@googlegroups.com
Sorry for the late comment, but how are any of those issues below "...different than a normal trojan?" All of those functions
can be performed by most automated attack stacks these days.  Many trojans, rootkits and other assorted malware use these
exact techniques.

I fail to see how this is unique at all -- the notion that it's "embedded" in a VM that is downloaded versus an infection vector
such as an infected binary or drive-by is hardly special and the C/C port uses port 80.

Adding the words "Virtual Machine" to the word trojan is the equivalent of screaming "Swine Flu" in a doctor's office.

Bah.
Reply all
Reply to author
Forward
0 new messages