In this article I look at level 5 of flAWS.cloud, a
CTF-style cloud security game in teaching you basics of cloud security by
making you break into an AWS account. This level is a particularly interesting
one because it is remarkably similar to a high-profile hack that was big in the
news lately. CapitalOne [lost >100M customer records](https://krebsonsecurity.com/2019/07/capital-one-data-theft-impacts-106m-people/),
stolen from their S3 buckets. Presumably the attacker extracted credentials
from a misconfigured web application firewall (WAF) and then simply downloaded the
material. This is exactly what we will do in this level too.
OK, this is not exactly what we will do. This game focuses on cloud security only and is kept simple. There won’t be complex applications protected by WAFs, just a simple proxy on an EC2 instance serving all the websites you request. From there, the goal is to find out how to make it serve the private IAM credentials that have been configured for this machine. Once you have them, all that is left is to use them to impersonate the EC2 instance and exfiltrate some data.
This is a walkthrough for level 4 of flAWS.cloud, a
CTF-style cloud security game in which you have to find your way in to an AWS
account. This time you find a publicly available web server running on an EC2
machine. Since it hosts a password-protected website there is not much to do
with just that. But given the credentials gained from level 3 of this game you
can use the AWS API to find out plenty of sensitive information about the
machine. The crucial part is the ID of the root volume, which allows to list
corresponding VM snapshots. You notice that there is one snapshot with
misconfigured sharing permissions, making the snapshot publicly available.
Thus you can boot your own EC2 instance, mount a volume based on this snapshot
and get past the password protection that way.
In Level 3 of the game we gained initial foothold and can now move deeper into the account. Level 4 now starts at this page. We are being told there is a web server running on an EC2 machine.
Before you start, make sure you have the credentials from level 3 ready. You can put the into the “~/.aws/credentials” file as a profile and then reference them in all your API calls.
Long time ago I started flAWS.cloud, a CTF-style cloud security
game teaching you about cloud-specific vulnerabilities related to bad
configurations. Now I took it up again and here is a walkthrough of level 3.
Like before we have a public homepage hosted on S3. This time we find a git repository with
IAM credentials in the commit history. Using them we can list the buckets and
find the link to the next level.
The previous level 2 illustrated how ACL misconfiguration can accidentally open up S3 buckets to all AWS users anywhere on the world. This was enough to just get the secret we needed. This time it will not be that easy anymore. Again, the starting point is a public website and we can again just list the bucket. But now the secret is hidden.
EDIT 11th Nov 2019: changed the description of this level.
In a previous post, I covered level 1 of flAWS.cloud, a
CTF-style cloud security game in which you have to find your way in to an AWS
account by abusing common misconfigurations. This walkthrough now covers level
2, in which you discover content in another vulnerable bucket. This time, S3
ACLs are the culprit. The level demonstrates one of the most common mistakes
in S3 access control configuration.
In level 1, we discovered that the homepage http://flaws.cloud is hosted in an S3 bucket with Amazons static page feature. Since the creator of the bucket configured the permissions such that unauthenticated users could list it, we discovered a secret file named “secret-dd02c7c.html”. It lead us to the start page of level 2. Now, the level description says we have to do something similar, but need our own AWS account this time.
flAWS.cloud is a set of CTF-like challenges that teach you common security issues in AWS accounts. This post is the first of a series of walkthroughs for these challenges. It's basically a short writeup on how to solve level 1, followed by a brief explanation of the AWS configuration that leads to this flaw and how to mitigate it. Before reading, go [here](http://flaws.cloud/) and try yourself first! ;)
Adoption of cloud computing is rising rapidly. Studies predict it will soon surpass on-premises hosting also for enterprise workloads. Large corporates are hesitant mostly due to security concerns, which are partly of more general nature (“uploading data to the cloud”), but also due to the myriad of cloud security failures you read about every day in the news. For example, many companies misconfigure AWS S3 bucket permissions and leave sensitive data unprotected.