Home > Cloud Computing, Cloud Security, Web Application Security > AMI Secure? (Or: Shared AMIs/Virtual Appliances – Bot or Not?)

AMI Secure? (Or: Shared AMIs/Virtual Appliances – Bot or Not?)

angel-devilTo some of you, this is going to sound like obvious and remedial advice that you would consider common sense.  This post is not for you.

Some of you — and you know who you are — are going to walk away from this post with a scratching sound coming from inside your skull.

The convenience of pre-built virtual appliances offered up for use in virtualized environments such as VMware’s Virtual Appliance marketplace or shared/community AMIs on AWS EC2 make for a tempting reduction of time spent getting your virtualized/cloud environments up to speed; the images are there just waiting for a a quick download and then a point and click activation.  These juicy marketplaces will continue to sprout up with offerings of bundled virtual machines for every conceivable need: LAMP stacks, databases, web servers, firewalls…you name it.  Some are free, some cost money.

There’s a darkside to this convenience. You have no idea as to the trustworthiness of the underlying operating systems or applications contained within these tidy bundles of cloudy joy.  The same could be said for much of the software in use today, but cloud simply exacerbates this situation by adding abstraction, scale and the elastic version of the snuggie that convinces people nothing goes wrong in the cloud…until it does

While trust in mankind is noble, trust in software is a palm-head-slapper.  Amazon even tells you so:

AMIs are launched at the user’s own risk. Amazon cannot vouch for the integrity or security of AMIs shared by other users. Therefore, you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence.

Ideally, you should get the AMI ID from a trusted source (a web site, another user, etc). If you do not know the source of an AMI, we recommended that you search the forums for comments on the AMI before launching it. Conversely, if you have questions or observations about a shared AMI, feel free to use the AWS forums to ask or comment.

Remember that in IaaS-based service offerings, YOU are responsible for the security of your instances.  Do you really know where an AMI/VM/VA came from, what’s running on it and why?  Do you have the skills to be able to answer this question?  How would you detect if something was wrong? Are you using hardening tools?  Logging tools?  Does any of this matter if the “box” is rooted anyway?

As I talk about in my Frogs and Cloudifornication presentations — and as the guys from Sensepost have shown — there’s very little to stop someone from introducing a trojaned/rootkitted AMI or virtual appliance that gets utilized by potentially thousands of people.  Instead of having to compromise clients on the Internet, why not just pwn system images that have the use of elastic cloud resources instead?

Imagine someone using auto-scaling and using a common image to spool up hundreds (more?) instances — infected instances.  Two words: instant Botnet.

There’s no outbound filtering (via security groups) via AWS, so exfiltrating your data would be easy. Registering C&C botnet channels would be trivial, especially over common ports.  Oh, don’t forget that in most IaaS offerings, resource consumption is charged incrementally, so the “owner” gets to pay doubly for the fun — CPU, storage and network traffic could be driven sky high.  Another form of EDoS (economic denial of sustainability.)

Given the fact that we’ve seen even basic DDoS attacks go undetected by these large providers despite their claims, the potential is frightening.

As the AWS admonishment above suggests, apply the same (more, actually) common sense regarding using these shared AMIs and virtual machines as you would were you to download and execute applications on your workstation or visit a website, or…oh, man…this is just a losing proposition. ;(

If you can avoid it, please build your own AMIs or virtual machines or consider trusted sources that can be vetted and for which the provenance and relative integrity can be derived. Please don’t use shared images if you can avoid it.  Please ensure that you know what you’re getting yourself into.

Play safe.


* P.S. William Vambenepe (@vambenepe) reminded me of the other half of this problem when he said (on Twitter) “…it’s not just using someone’s AMI that’s risky. Sharing your AMI can be too http://bit.ly/1qMxgN ” < A great post on what happens when people build AMIs/VMs/VAs with, um, unintended residue left over…check out his great post.

  1. October 8th, 2009 at 18:23 | #1

    There is a business opportunity in here somewhere…any takers?

  2. October 8th, 2009 at 19:08 | #2

    I recommend the public Ubuntu AMIs published by Canonical and alestic.com as great starting points for building your own AMIs. For the truly paranoid, alestic publishes the script with which these AMIs are created, allowing you to do the same by yourself and verify it before trusting it.

  3. October 9th, 2009 at 04:03 | #3

    @James Urquhart

    http://elasticserver.com by CohesiveFT (disclosure: I work at CohesiveFT).

  4. October 9th, 2009 at 06:29 | #4

    I imagine that Amazon will offer certificated AMIs one day. Until then you need to rely on the reputation of big vendors – like you accept to install any Microsoft software on your PC.

    Another solution: AMI virus detection and scanning tools. Don't know what's out there in the market…?

    @Dmitriy: in what sense does elasticserver deal with the problem of potential malware on AMIs?

  5. October 9th, 2009 at 09:06 | #5


    Elastic Server lets you create your own AMIs from scratch (Z2V – zero-to-virtual). Base OS gets instantiated from packages that reside in our mirrors of upstream package repositories – such as those for Debian, Ubuntu, Fedora. These are all official packages.

    As a result, instead of starting with someone else's AMI, you can create your own AMI as your base install. This considerably reduces the probability of you getting a "trojaned/rootkitted AMI or virtual appliance" as your base image.

    This may not be the main use case for Elastic Server (there are many) but it's a side effect that I thought was applicable to this blog post. This is an alternative to low-level approach suggested by @Shlomo of using alestic scripts – each of these approaches has its audience I think.



  6. Gabrie
    October 11th, 2009 at 18:53 | #6

    I think appliances on VMware's marketplace have been checked by them although not sure how thoroughly.

  1. October 15th, 2009 at 00:03 | #1