The Virtual Machine Trojan
Reuven Cohen
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.
Geir Magnusson Jr.
Jorge Oliveira
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
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
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.
Reuven Cohen
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
Regards,
Alex Esterkin
Matthew Zito
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
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.
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
@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
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.
Eric Windisch
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
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.
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
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
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
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
Christofer Hoff
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.