AWS Security: A series of common mistakes
AWS Security: A series of common mistakes
I have decided to take initiative and learn AWS security given the wide adoption of the cloud. Last year I sat for the AWS Cloud Pactitioner exam and passed, and I am hoping I can do another one. I’ve been contemplating doing the Solutions Architect but I am not really sure I need it. My goal is to pass the AWS Certified Security, since it is specialized. But I’m not sure if I can jump the steps like that. I’m gonna be using the flAWS project by Scot Piper.
In his own words, “Through a series of levels you’ll learn about common mistakes and gotchas when using Amazon Web Services (AWS). There are no SQL injection, XSS, buffer overflows, or many of the other vulnerabilities you might have seen before. As much as possible, these are AWS specific issues.” That is the flAWS project. I’ll be doing more research into the mistakes and providing more details.
Level 1
This level is **buckets** of fun. See if you can find the first sub-domain.
Common Mistake Explanation: Exposed S3 buckets
Amazon Simple Storage Service is an object storage service that stores data as objects inside buckets. An object is a file and any metadata that describes the file. Amazon S3 provides the ability to store an serve static content from Amazon’s Cloud. Businesses use S3 to store all types of data in S3 buckets: data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics. Access controls can be applied to both the bucket itself and to individual objects(files and directories) stored within the bucket.
A bucket is typically considered “public” if any user can list the contents of the bucket, and “private” if the bucket’s contents can only be listed or written by certain S3 users. A public bucket will list all of it’s files and directories to any user that asks. Checking if a bucket is public or private is easy. All buckets have a predictable and publicly accessible URL. By default this URL will be either of the following:
http://s3.amazonaws.com/[bucket_name]/
http://[bucket_name].s3.amazonaws.com/
To test the openness of the bucket a user can just enter the URL in their web browser. A private bucket will respond with “Access Denied”. A public bucket will list the first 1,000 objects that have been stored. The security risk from a public bucket is simple, and similar to the common Directory Listing Vulnerability. A list of files and the files themselves - if available for download - can reveal sensitive information. The worst case scenario is that a bucket has been marked as “public”, exposes a list of sensitive files, and no access controls have been placed on those files. In situations where the bucket is public, but the files are locked down, sensitive information can still be exposed through the file names themselves, such as the names of customers or how frequently a particular application is backed up.
And according to Amazon themselves in regard to this issue: “Bucket public “READ” access: This is sometimes referred to as “list” access. It allows anyone to get a complete list of your bucket content. It does not grant permissions to read content of an object. However, a list of object names can often provide more information than necessary to the public.”
More research
Hint 1
In the first hint we are told that the site is hosted in S3 buckets as it is a great way to host static sites. Let’s do a DNS lookup on the domain to confirm this:
dig +nocmd flaws.cloud any +multiline +noall +answer
Returns:
flaws.cloud 5 IN A 52.92.177.3
Next, we do an nslookup on the IP:
nslookup 52.92.177.3
Returns:
3.177.92.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
So we know we have an S3 bucket hosted in the AWS region us-west-2. All S3 buckets, when configured for web hosting, are given an AWS domain you can use to browse to it without setting up your own DNS. In this case, flaws.cloud can also be visited by going to http://flaws.cloud.s3-website-us-west-2.amazonaws.com/. At this point you can just visit http://flaws.cloud.s3.amazonaws.com which lists the files in the directory and you will be able to view the secret html file, browse to it and see the link to the next level. Or you can use the AWS CLI to view the directory listing:
aws s3 ls s3://flaws.cloud/ --no-sign-request --region us-west-2
This returns:
2017-03-14 05:00:38 2575 hint1.html
2017-03-03 06:05:17 1707 hint2.html
2017-03-03 06:05:11 1101 hint3.html
2020-05-22 20:16:45 3162 index.html
2018-07-10 18:47:16 15979 logo.png
2017-02-27 03:59:28 46 robots.txt
2017-02-27 03:59:30 1051 secret-dd02c7c.html
To view the secret file:
aws s3 cp s3://flaws.cloud/secret-dd02c7c.html - --no-sign-request --region us-west-2
And the link will be displayed for you. Visit the link because the first part of level 2 explains how to avoid S3 bucket exposure.
Level 2
Common Mistake: Loose permissions on S3 bucket
This mistake is similar to the one we demonstrated in the first level. It is slighly different in that a user has to be authenticated in oredr to view the contents of the S3 bucket. This is a common misconfiguration where administrators give access to “Any authenticated AWS user” thinking that it refers to users in their account when it refers to anyone who has an AWS account. This leads to exposure of confidential information to unauthorized parties.
Hint 1
For this level I needed to create a Free Tier account on Amazon Web Services. This will grant me an access key that I need to access the bucket. This is the authentication required. After creating an account, you can create an access key, and store it somewhere safe then configure your environment with the key.
aws configure
Enter details for the prompts. It should look something like this:
AWS Access Key ID: <random string>
AWS Secret Access Key: <access key string>
Default region name: us-west-2
Default output format:
After you configure that you can run the command to list the S3 bucket contents:
aws s3 --profile default ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
This returns:
2017-02-27 04:02:15 80751 everyone.png
2017-03-03 05:47:17 1433 hint1.html
2017-02-27 04:04:39 1035 hint2.html
2017-02-27 04:02:14 2786 index.html
2017-02-27 04:02:14 26 robots.txt
2017-02-27 04:02:15 1051 secret-e4443fc.html
And you can print the contents of the secret file to stdout:
aws s3 --profile default cp s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-4443fc.html -
And there you will see the link for the next level. When you visit the level 3 page you will see details about how you can avoid this mistake, which is by opening permissions to specific AWS users.
This article is not finished yet. But you can read what’s there right now if you want :)