Confidential Information in the Cloud

This is another special blog written by Matt Gardenghi!

My boss passed around a document about database security in the cloud.  It raised issues about proper monitoring of the DB, but offered no solutions.

This got me thinking.  I hate it when that happens.  Its like an automatic "boss button" that I can't switch off.  /gah

For the sake of argument, let's assume we are discussing VMs hosted on some provider's (Amazon) VMWare ESX cluster.  This could really apply to any VM on any company's specific VM host, but VMWare is big, popular, and a good basis to work from.  Let's say, some marketing exec bought a package that would hold data on a machine in the cloud.  (You may shoot him later; right now, you have to deal with the issues of integration into your secure environment.)

Now let's suppose that you do not have enough machines to warrant a private cluster.  You will be sharing a cluster with unknown parties.  Fun!  (Ant-acid is found in aisle 5.)

After reading this document, my mind immediately ran to the story of Kevin Mitnick's hacked website.  You may recall that the headlines proclaimed that Mitnick was hacked, when that is only true in the strictest sense.  In reality, it was a shared host, and one of the other sites was running old code and was hacked.  That hack granted the attacker access to modify Mitnick's site.

OK, but are you really at risk this way?  We're talking about VMs here not shared hosting on a poorly configured LAMP stack.   But, surely you've heard of Guest -> Host exploits?  And since this is publicly obtainable software, one *could* setup a duplicate environment and fuzz away at it....  (Not that any entity would do that, of course.)

So theoretically, one of the other unknown/untrusted Guests could use a zero day exploit to compromise the Host.  Then they could compromise all of the co-located Guests on the box.  Cheery thought....  How would you know?  Since they are essentially performing a "man in the middle," the attacker could just watch your traffic and never touch your machine.  All of those techniques for modifying data on the wire come trudging depressingly back to mind.  You couldn't trust the data coming from the user or going to the user.

Further, if the ESX host is compromised, every machine that VMotioned over to it could be compromised.  Every machine that VMotioned off could then run the zero day against a new host.  This would get an entire cluster and possibly migrate to other clusters (though much less likely).

Now one might ask "how" a malicious user/competitor/etc would locate your server in Amazon's cloud and target your machine.  Cue stage right: a paper on doing that very thing (pdf).

So now we are looking at 1) an attacker can find your machine, 2) an attacker could instigate Guest -> Host exploits.  Are you still certain you want to put your data in the cloud?  Ugh.  I can't think of one good reason to do this on a public cloud hosting service.

I know that this is more of a theoretical post and not like Ron's usual posts detailing specific exploitation or research, but I'm interested in your comments.  Am I off base in this reasoning (has happened once or twice before - according to my wife anyway).  What are your thoughts?  Is it worse than I suspect or am I over-reacting?

7 thoughts on “Confidential Information in the Cloud

  1. Reply


    You are not over-reacting at all. Cloud computing has a huge number of security issues, not only virtualization related : XSS/CSRF attacks on the administration webpages, security policies in the hand of a third person (the provider), etc.

    I recommend reading the book, "Hacking : the next generation" from O'Reilly, which shows a good few examples of that.

    1. Reply

      Matt Gardenghi Post author

      I'll have to look into that. Thanks.

  2. Reply

    Ron Bowes

    I don't know much about EC2, but do you get root on their boxes? Or, failing that, is there anything to stop you from obtaining root on one of their virtual machines?

    Once you have root on a virtual machine, depending on how their network is set up, it might be possible to do other interesting attacks, such as ARP poisoning (I'm sure we all remember when Metasploit's site was "hacked", even though it turned out to be ARP poisoning).

    I've had nothing but bad experiences with shared servers, in terms of security, logs, and incident response. It'll be interesting to see how the 'cloud' stuff pans out -- at least you have proper access to your own logs! :)

    My 2 (Canadian) cents.

  3. Reply

    Matt Gardenghi Post author

    and we all know how much Canadian cents are worth....

    (nearly as much as US cents lately.)

    I *think* you get root on those boxes. Not sure A) why you wouldn't and B) how they could stop you. :-D

    Theoretically, they could prevent you from migrating around via virtual IPS and VLANs but they don't. Or don't appear to do that (according to the paper I linked to in the post).

    1. Reply

      Ron Bowes

      Yeah, the same amount as American cents. :P

  4. Reply

    Xavier Ashe

    Have you looked at any of the add-on security for VM hosts? Like IBM's Virtual Server Protection written by the old ISS team? I'd be interested in your opinion if this could mitigate some of your concerns? Note, I do work for IBM, in Tivoli Services.

  5. Reply

    Matt Gardenghi Post author


    I have not seen that yet. We do utilize some Tivoli products, but that's not one of them. I'll attempt to look into it in the near future.

Leave a Reply to Matt Gardenghi Cancel reply

Your email address will not be published.