Sub-Domain Take Over — AWS S3 Bucket
In this article, we are going to understand and know how a small vulnerability can cause havoc and result in a subdomain takeover.
Firstly we will discuss some basic terminologies so that it would pave our path easier for the follow-up journey, so if you are already familiar with these terms and their working you can skip the below part and directly jump to the ‘takeover’ part.
WHAT IS A SUBDOMAIN?
A subdomain is an additional part of your main domain name. They are organized in a way to easily navigate different parts of the website. You can create multiple subdomain and child domains.
For eg.
store.mydomain.com
In the example ‘store’ is the subdomain, ‘mydomain’ is the primary domain and ‘.com’ is a top-level domain (TLD). You can learn more about this here.
AMAZON S3 —
Amazon S3 stands for the ‘Simple Storage Service’. It is used to store the data as objects within buckets, an object is a file or any optional metadata that describes the files. One can upload it to buckets and set the desired permission to it and modify it according to need.
Buckets are the storage places that are used to upload our data. Amazon S3 provides various APIs to manage them. Amazon S3 creates the buckets in a Region that is close to the user and the naming convention should be globally unique until one is deleted in that region.
Objects uses unique-key value pair to store and each bucket can store up to 5 TB in size.
Key -> Name assigned to objects
Version ID -> Key and UID unique value to find bucket
Value -> Content that is stored
Metadata -> Name-value pair which one can store information regarding
Subresources -> Control objects to store
Acces Control Info -> Control Access of Objects
Takeover
To understand this attack vector properly and be cleared to know the root cause and concept we are going to use an analogy for the further part.
We are going to pick fictional characters from our beloved show MrRobot. Suppose the manager(Gideon) of Allsafe asked their DevOps engineer to migrate the CDN (Content Delivery Network) of ECORP to the more effective one.
So the task given by Gideon is done and the following command was fired (We are going to analyze these to understand the work)
- ‘aws s3 mb s3://cdn.ecorp.net’
This is used to create a new S3 bucket called cdn.ecorp.net.
NOTE: In AWS the bucket should follow the same naming nomenclature of the domain and the subdomain.
2. ‘aws s3 sync s3://assets.ecorp.net s3://cdn.ecorp.net — quiet’
It is used to copy the assets from the existing S3 bucket called ‘assets.ecorp.net’ to the new S3 bucket ‘cdn.ecorp.net’. Sync is used to recursively copies all files and folders.
3. ‘aws s3 rb s3://assets.ecorp.net — force’
The older non-used S3 bucket will be deleted using the above-defined command. According to the official documentation of AWS, old unused buckets should be deleted and it is considered a good practice.
Now the required work is done, but still, Gideon is worried about the extensive changes that are being made to the Infrastructure, to be sure everything is in the place he called his best Penetration Tester/Hacker ‘Elliot Alderson’ for the rescue.
Now Elliot starts doing things in which he is best, first, he began to assess the external-facing network of Ecorp to find any potential gap in security posture. To increase his chance he uses a custom-made wordlist that consists of regularly used subdomains and starts the process of enumeration to find the possible subdomain for ecorp.net (Which could be done either by already existing tool or making a new script).
During enumeration, he finds multiple subdomains one of them is ‘https://assets.ecorp.net’. Interesting result starting to arrive as soon as Elliot tried to access this domain using the browser, the URL raises a ‘404 NOT FOUND’, with some additional information such as
Code: NoSuchBucket
Message: The specified bucket does not exist
BucketName: assets.ecorp.net
The above error string ‘NoSuchBucket’ indicates that the bucket assets.ecorp.net which was previously mapped to the ecorp domain is no longer present or deleted. This harmless-looking message reveals a vulnerability flaw in Ecorp AWS Infrastructure.
Since this error message indicates that there is no S3 bucket. Elliot can reuse/reclaim this by creating a new S3 bucket from his personal AWS account and name it assets.ecorp.net. According to official AWS documentation once a bucket is deleted its name is available to reuse again by another user.
Elliot did this by using the following commands :
- ‘aws s3api create-bucket -bucket assets.ecorp.net -region eu-west-2 -create-bucket-configuration LocationConstraint=eu-west-2’
Elliot run this to create an s3 bucket from his personal AWS account and name it assets.ecorp.net.
2. ‘aws s3api put-bucket-policy — bucket assets.ecorp.net -policy file://malicious_policy.json’
After creation, he applied a policy to the bucket which will allow him to serve static content from this.
Now the takeover bucket is up and ready to use, Elliot decided to showcase the harm it can do to the organization. So he uploaded a fake login page that resembles Ecorp SSO.
‘aws s3 sync ./static/ s3://assets.ecorp.net’
Note: /static is the local directory that consists of the malicious login page.
‘aws s3 website s3://assets.ecorp.net/ — index-document index.html — error-document index.html’
The above-defined command will enable public access for the S3 bucket https://assets.ecorp.net
On accessing one can see the login page of ECORP, this webpage is being served from the ecorp owned domain name. Since Elliot controls the S3 bucket he can perform several malicious attacks such as :
- Hosting Phishing websites
- Hosting Malware
- Bypassing CSP policies
- Stealing Cookie’s
- Man-in-the-browser attacks
This ability for a malicious actor to take control of a domain that was previously associated with a deprovisoned AWS resource is also known as a Subdomain Takeover vulnerability.
Analysis
Now let’s further analyze the root cause of the issue and understand why Elliot could serve the fake login SSO from the ecorp domain name.
During the de-provisioning of the old S3 bucket, the engineer deleted the bucket aligned to good policy rules, but he accidentally forgot to remove the S3 corresponding subdomain entry within AWS-hosted DNS services.
This can be prevented by removing the DNS entry record, a JSON file can be used to remove the corresponding entries identified by the hostzoneID and other methods.
To mitigate this, regularly organization DNS records should be reviewed, stale and unused DNS entries should be identified and removed. The review must further be incorporated when discontinuing or terminating service and ensuring all associated DNS entries, hostnames, and subdomains are removed for the service.
So, this is an inspired version of the original vulnerability that is been found and reported in the AWS s3 bucket.
