Amazon Simple Storage Service (Amazon S3) is a scalable, high-speed, low-cost, web-based cloud storage service designed for online backup and archiving of data and application programs. It is probably the most popular of the AWS services and provides a scalable solution for object storage via WEB APIs. In fact, S3 buckets offer far more versatile solutions than that.Consider the case of a web application that needs a staging area to house content that is to be served to users or maybe hosting of videos, music or other downloadables or maybe you just want to store a backup on the web. AWS S3 has you covered. The image illustrates how a web application makes use of AWS S3 to store media files like pictures uploaded by users or content like JavaScript and CSS that is employed by the application itself.
S3 buckets can be used to store and serve static websites or other AWS services. Which means that if a snapshot of an AWS EC2 instance is stored in an S3 bucket then sensitive information contained within the EC2 instance and maybe even the keys that grant access to an alternative EC2 instance or service are also housed on the S3 bucket. This makes proper configuration of S3 buckets a necessity.
AWS S3 provides different access permissions that, if misconfigured can leave the door open for unauthorized access potentially leading to malicious attacks. Over the past few years, AWS S3 buckets have come to be known as the primary source of leakage at companies that suffered data breaches.
S3 buckets are spawned out of storage requirement and are bound to a particular domain. Sometimes these buckets are not deleted after they have served their purpose which may escalate to a complete take over of a subdomain of the host. Consider the following example:
An S3 bucket may be created and its URL (http://storage.example.com.s3-website.ap-south-1.amazonaws.com) may be bound to a subdomain(Eg: “https://storage.example.net”.) belonging to the organization to obfuscate the AWS S3 URL. This is done by adding an alternate domain name(CNAMEs).
Later when this bucket is deleted from AWS S3, but the CNAMEs record in the Route53 is not removed, an attacker may create an AWS S3 bucket with the same name and the malicious contents of this bucket will be served on the victim's domain(eg: storage.example.net), Hence taking over the subdomain.
The first step in identifying this vulnerability is looking for an error page which has the message “404 Not Found” and has the message “NosuchBucket”.
As an attacker, the first step is to enumerate the subdomains of a particular host and try to identify error pages which says bucket not found as shown in the image below.
Image-1: The evidence shows that the image.example.net subdomain is vulnerable.
While I was testing a popular E-commerce application, I found that their “images.example.net” subdomain was vulnerable as I got an error page with the message “NoSuchBucket”, and also had the bucket name. This means the S3 bucket which was bound to the “ image.example.net” subdomain has been deleted, but the CNAME record in the route53 has not been removed.
As an attacker, I created an S3 bucket with the same name and in the same region which had the URL “http://images.example.net.s3-website.ap-south-1.amazonaws.com”
While creating the S3 bucket one need to specify the same region which was used by the victim. The region can be obtained by performing a CNAME lookup as shown in the below image.
Image-3: here is the example to fetch S3 bucket region using CNAME lookup.
When any users of the site try to access “image.example.net”, Since the Route53 has a record which maps the CNAME to S3 bucket created by the attacker, Malicious content from the attacker's bucket is rendered on the victim's site.
An attacker can serve malware to the users by hosting malicious content in images.example.net or fetch sensitive information from another subdomain which belongs to the host.
It is my recommendation that developers or IT engineers scrutinize their organization’s DNS records every time there is a termination of a S3 bucket. This will ensure there are no DNS/CNAME entries that point to non-existent S3 buckets which could potentially be exploited.
