Danger Cloud

by Vince
in Blog
Hits: 299

The benefits of cloud are amazing and I think that is fairly common knowledge at this point but there are also some associated dangers.  I think first and foremost, the most dangerous aspect of cloud is the simplicity in which resources can be stood up.  Let's say you need 10TB of storage quickly.  Gone are the days of ordering a physical server, or even server software, and with a few mouse clicks, you have an endless amount of storage.  It is so simple that regular users create and manage resources. 

Somewhere along the way, those managing said storage containers misunderstood the term "public" on S3 buckets.  That lead to private data being exposed on the Internet and a number of talks were given on the subject.  For a time, S3 buckets had big, bold, text stating the status of the buckets.  Those days have passed and I think most buckets are properly configured but the problems don't end with S3.

Let's say you need to spin up some servers.  You can build an EC2 instance but that's complicated and AWS would like any user to create a server.  That's when Lightsail appeared or at least that's how I imagine this all went down.  Regardless, don't blame the technology, blame the simplicity.  Some understanding is required and that brings us to the image below:



We have a Lightsail instance that is setup as a web server.  By default, only port 22 is open.  For the web server to be visible to the outside world, we need to also open ports 80 and 443.

On the actual server, when we run iptables, we see that no restrictions exist.



When we run an nmap scan from the outside world, what we see is what we expect.



Now here's where the guardrails are missing -- unbeknownst to the creator.



When we ping sweep the entire subnet, we see ALL OF THE HOSTS.  

And when we port scan that same web server, we see an additional port.



Maybe this paints enough of a picture but let me spell it out.  The simplicity of Lightsail could make one believe these are independent and unconnected systems.  They are not.  On more than one occasion, I've seen development servers that are not hardened but are facing the public Internet.  They were setup under the assumption that they are isolated.  But we now know this is not the case.  Based on what I've outlined above, if you compromise one of those development servers, you can now target the other systems on the subnet.  And because we've pivoted to the internal network, we have potentially bypassed some or all security controls.  

Let me be clear -- this is not an argument against cloud.  Cloud is awesome but with the same breath, I will also say that security is hard. 

As an attacker, I will look for, and exploit, these small mistakes.  And as a professional penetration tester, I will help you find these holes in your environment.