Date: Wed, 3 Feb 2010 08:36:15 +0100
From: Sam Johnston <samj@...j.net>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Private cloud security is no security at all

Private cloud security is no security at
all<http://samj.net/2010/02/private-cloud-security-is-no-security.html>

It's ironic that the purveyors of "Private Cloud" sell their wares on the
premise of enhanced privacy and security - a totally unjustified claim which
is too often accepted without question - and that they are quick to dismiss
the huge benefit of the armies of security boffins employed by "public"
cloud vendors (whose future is largely dependent on keeping customer data
safe). It's also very convenient for them that the term itself is
disparaging of "public" cloud in the same way that "Blog With
Integrity<http://www.blogwithintegrity.com/badge.php>"
badges imply that the rest of us are somehow unethical (one of the main
reasons I personally have and will always dislike[d] it).

It is with that in mind that I was intrigued by Reuven
Cohen<http://twitter.com/ruv>
's announcement
today<http://www.elasticvapor.com/2010/02/enomaly-intel-participate-in-new-cloud.html>
 regarding Enomaly, Inc. <http://www.enomaly.com/> having recently joined
the Intel Cloud Builder Program
<http://communities.intel.com/docs/DOC-4292> (whatever
that is). It was these two quotes that I found particularly questionable
regarding their Enomaly ECP product:

   1. *Intel was among the first to full(sic) understand the opportunity in
   enabling a truly secure virtualized cloud computing environments(sic) for
   service providers and Telco's.*
   2. *Our work with the Intel Cloud Builder Program will help to accelerate
   our efforts to deliver a massively-scalable, highly-available,
   high-security cloud platform to our customers.*

The reason I'm naturally suspicious of such claims is that I've already
discovered a handful of critical security vulnerabilities in this product
(and that's without even having to look beyond the startup script - a
secure-by-default turbogears component that was made insecure through
inexplicable modifications):

   1. CVE-2008-4990 Enomaly ECP/Enomalism: Insecure temporary file creation
   vulnerabilities<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4990>
   2. CVE-2009-0390: Argument injection vulnerability in Enomaly Elastic
   Computing Platform
(ECP)<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0390>
   3. Enomaly ECP/Enomalism: Multiple vulnerabilities in enomalism2.sh
   (redux) <http://seclists.org/bugtraq/2009/Feb/142>

I had to dig a little (but not much) deeper for the silent update remote
command execution vulnerability <http://seclists.org/bugtraq/2009/Feb/123>.
I also inadvertently discovered another serious security
vulnerability<http://samj.net/2009/08/twitter-pro-best-buys-twelpforce-is.html>
(sending
corporate BestBuy credentials in the clear over the Internet to a 3rd party
service <http://bbyconnect.appspot.com/>), which as it turns out was also
developed by Enomaly, Inc. It's only natural that I would be suspicious of
any future security claims made by this company.

It doesn't help my sentiment either that every last trace of the Open
Source ECP Community Edition <http://sourceforge.net/projects/enomalism/> was
recently scrubbed from the Internet without notice,
leaving<http://groups.google.com/group/enomalism/msg/6146263e5c089b8d>
 angry <http://groups.google.com/group/enomalism/msg/15644b997198af41>
customers <http://groups.google.com/group/enomalism/msg/bfc55878ee3786a3>
high <http://groups.google.com/group/enomalism/msg/99984bfeab33afc2>
and<http://groups.google.com/group/enomalism/msg/5796df922d2583f5>
 dry <http://groups.google.com/group/enomalism/msg/894231c4f8c5cfeb>,
purportedly pending the "rejigging [of their] OSS strategy". While my
previous attempts to fork the product as
Freenomalism<http://sourceforge.net/projects/freenomalism/> failed
when we were unable to get the daemon to start, having the code in any
condition is better than not having it at all. In my opinion this is little
more than blatantly (and successfully I might add) taking advantage of the Open
Source <http://opensource.org/> community for as long as necessary to get
the product into the limelight. Had they not filled this void others would
certainly have done so, and the Open
Cloud<http://opencloud.googlecode.com/svn/trunk/oci/ocp/open-cloud-principles.html>
would
be better off today as a result.

As part of cloud standards work I was interested in taking a look at the
"secure" mechanism they developed for distributing virtual machines:

*VMcasting <http://www.vmcasting.org/> is an automatic virtual machine
deployment mechanism based on RSS2.0 whereby virtual machine images are
transferred from a server to a client which securely delivers files
containing a technical specification and virtual disk image.*

Another bold claim that initially appeared justified by a simple but
relatively sensible embedding of crytpographically strong checksums into
descriptor and manifest files that were in turn digitally signed using GPG.
Unfortunately no consideration was given to the secure retrieval of the
archive itself (nor the RSS feed listing the archives for that matter), nor
were signatures actually required by the specification, meaning that it
would be trivial for an attacker to insert their own unsigned packages
and/or replace existing signed packages with modified, unsigned ones.

Fortunately an attacker need not even go to these lengths as despite
acknowledging the need for digital signatures in the VMcasting
specification<http://www.vmcasting.org/vmcastingspec/>,
none of the security features appear to have been implemented in Enomaly ECP
itself. Worse still, it won't even let you use SSL if you're sensible enough
to try:

if url[0].lower not in ("http", "ftp"):
  raise E2UndefinedError(_("Unknown scheme in package URL."))

Think you're safe if you keep everything on your own network (that's the
whole point, right?). Don't be so sure, as the vmfeed module quietly
registers these HTTP URLs for you:

   - http://enomalism.com/vmcast_appliances.php [archived
copy<http://samj.pastebin.com/fb87b349>
   ]
   - http://enomalism.com/vmcast_modules.php [archived
copy<http://samj.pastebin.com/f7c015faa>
   ]

Sure enough if you retrieve the first URL you'll get a feed of "virtual
appliances" like this
one<http://s3.amazonaws.com/VM_Images/265e0596-8341-11dd-920d-1a1321b1d5ec.xvm2>
(delivered
over HTTP from Amazon S3 no less) and as expected, if you untar it you'll
see that there's no signatures. Don't get me started on the myriad
vulnerabilities no doubt present within the appliances themselves given
their age.

But wait, there's more - being able to run workloads of your choice (e.g.
trojan horses, network scanners, etc.) within your victim's network is one
thing, and being able to obtain and reverse engineer their existing
workloads (given there's no catering for authentication) another, but taking
over the management system itself is where there's real fun to be had.
Fortunately all you need to do is set the MIME type to
application/python-eggrather than application/enomalism2-xvm2 and this
little chestnut gets invoked, quietly unzipping and forcibly installing the
supplied python module:

elif self.get_mime()==EGG_MIME:
  tx.update("Installing Python egg.", 90)
  target=os.path.join(settings.repodir,\
    self.get_uuid().replace("-","_")+".egg")
  shutil.move(filename, target)
  self.install_python_egg(target)

The vmcast_modules feed currently advertises the
e2_drivemounter<http://enomaly.com/fileadmin/eggs/e2_drivemounter-1.0.0ecp_2.1-py2.5.egg>
, e2_exception<http://enomaly.com/fileadmin/eggs/e2_exception-1.0.0ecp_2.1-py2.5.egg>
 and e2_phone_home<http://enomaly.com/fileadmin/eggs/e2_phone_home-1.0.0ecp_2.1-py2.5.egg>
modules
which are all available for download, again over HTTP, from
http://enomaly.com/fileadmin/eggs/.

Anyway I'm sure there'll be
backpedalling<http://groups.google.com/group/enomalism/msg/83a8c3c4c3abe033>
, downplaying<http://groups.google.com/group/enomalism/browse_thread/thread/ae94ac7cb5fa7683>
, shooting-the-messenger<http://www.elasticvapor.com/2008/11/v-for-vendetta.html>,
etc. which is why you're reading this here rather than in a vulnerability
announcement. While the bugs are obviously unconfirmed this still
illustrates my point nicely - don't take it for granted that private cloud
offerings are secure, and in the unlikely event that the systems themselves
are secure, don't assume you or your provider can run them in a more secure
fashion than a "public" cloud provider could. Incidents like this go a long
way towards realising one of my
predictions<http://www.crn.com/hardware/222500171?pgno=10> for
2010 (or should I say @philww <http://twitter.com/philww>'s "considered
prediction <http://twitter.com/philww/status/7720391351>") in that *Private
clouds will be discredited by year end*.

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists