A central point for collection of information that relates to computer security. Including, but not limited to, security advisories from the major vendors, major data breaches, “phishing” alerts, commentary regarding staffing levels. etc. etc.
Private Cloud Security Rant
February 3, 2010 at 12:57 pm #91100
FYI: If you have interest in this issue and have some technical skills would suggest that a visit to the blog MIGHT be in order…
From Sam Johnston’s blog
03 February 2010
Private cloud security is no security at all
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” 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’s announcement today regarding Enomaly, Inc. having recently joined the Intel Cloud Builder Program (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):
I had to dig a little (but not much) deeper for the silent update remote command execution vulnerability. I also inadvertently discovered another serious security vulnerability (sending corporate BestBuy credentials in the clear over the Internet to a 3rd party service), 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 was recently scrubbed from the Internet without notice, leaving angry customers high and dry, purportedly pending the “rejigging [of their] OSS strategy”. While my previous attempts to fork the product as 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 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 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 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. Or replaying an older, signed version of an insecure workload for that matter.
Fortunately an attacker need not even go to these lengths as despite acknowledging the need for digital signatures in the VMcasting specification, 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:
Sure enough if you retrieve the first URL you’ll get a feed of “virtual appliances” like this one (delivered over HTTP from Amazon S3 no less) and as expected, if you untar it you’ll see that there’s no signatures whatsoever. Don’t get me started on the myriad vulnerabilities no doubt present within the appliances themselves given their age – packaging applications as virtual machines is a notoriously bad idea and one that I hope will be overrun by containers/platforms in the not too distant future.
Anyway I’m sure there’ll be backpedalling, downplaying, shooting-the-messenger, 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 for 2010 (or should I say @philww’s “considered prediction”) in that Private clouds will be discredited by year end.
You must be logged in to reply to this topic.