Subdomain Takeover via Abandoned Amazon S3 Bucket
On June 15th, 2021 our COO David Sopas presented at C- DAYS 2021 “Taking Over Your Subdomain 101”, which you can watch on YouTube. In his talk, David explains with great detail what subdomain takeover is, how to exploit and prevent it, as well as several recent Char49 findings. In this article, we will focus solely on a specific subdomain takeover “type” which we frequently find out there: those accomplished due to abandoned AWS S3 buckets.
What is a Subdomain Takeover
First things, first: char49.com is an Internet domain name (or simply, domain), and blog.char49.com a subdomain. Organizations or individuals can register a domain with a domain name Registrar (or simply, Registrar): a company that manages domains’ reservations. Registration of a domain establishes a set of name server records pointing to a DNS service where domain owners manage DNS records associated with their domain. In general, a DNS record is a mapping between the domain/subdomain name and the target server IP address or domain name, responsible to satisfy client requests e.g. serving web pages. Subdomain takover happens when attackers manage to control the content delivered by a subdomain. To do that, attackers don’t have to compromise DNS service accounts to configure the DNS record to point to a server controlled by them, nor the server the DNS record points to. Instead, attackers notice that the DNS record associated with the subdomain points to an unavailable server or service and manage to create it. AWS S3 (buckets) can be that service.
What is an Amazon S3 Bucket
Amazon S3 or Amazon Simple Storage Service is a service provided by Amazon Web Services (AWS) to store and retrieve any amount of data, with availability and replication guarantees. Buckets work like containers to store objects. They can be managed using Amazon S3 APIs or the Amazon S3 console (web application) and their content can be retrieved over HTTP. Buckets have a globally unique name: “after a bucket is created, the name of that bucket cannot be used by another AWS account in any AWS Region until the bucket is deleted”.
How does it happen
Since Amazon S3 buckets’ contents can be retrieved over HTTP, they can be used to store and serve static assets such as images, videos, stylesheets, user upload content, or complete static websites. In such cases, Amazon S3 buckets receive an HTTP address like http://[bucket-name].s3-website-us-east-1.amazonaws.com. Organizations tend to create custom subdomains and point them to the bucket’s address using a DNS CNAME record like the one below:
Type | Name | Content | TTL | |
---|---|---|---|---|
CNAME | blog | blog.char49.com.s3-website-us-east-1.amazonaws.com | 3000 | |
If we gave up on our static blog, probably the first thing to do is to remove its contents from the Amazon S3 bucket and delete the bucket: this way we won’t be charged any additional fees. But we still have the DNS record pointing blog.char49.com to the bucket HTTP address: since it wasn’t removed, it now points to a bucket that doesn’t exist anymore. In such a case, pointing the browser to blog.char49.com would return a page like the one below:
What if someone else creates a new bucket with the same name? Then, that person will be in control of what content is served by our subdomain, thus we’re victims of subdomain takeover.
What are the risks
Controlling what content is served by a third-party subdomain may have a huge impact on the target organization’s reputation. It can be exploited to deliver inappropriate or malicious content either to cause reputation damages or to abuse target organization users/customers. You can watch our Segway Subdomain Takeover proof-of-concept video to see how subdomain takeovers can be successfully used for phishing campaigns. In some cases, if browser cookies were not properly configured, for the subdomain or the top-level domain, account takeover may be possible via session hijacking.
How to prevent
Managing infrastructure as code (IaC) should definitely help to avoid situations where a bucket is removed but the associated DNS record is left behind: probably such a scenario wouldn’t pass unnoticed on a code view. Keep application assets under active monitoring for unexpected content delivery, domain expiration or ownership changes will allow early detection and remediation.
Conclusions
We frequently find exploitable subdomain takeovers in the wild or on our penetration testing assessments. Since the attack complexity is low and no special privileges are required, this is something that bad actors will certainly pay attention to in order to accomplish their goals. On the other hand, preventing this issue might be just a matter of adopting and following DevOps best practices. You can learn more about Subdomain Takeover watching the “ Taking Over Your Subdomain 101” talk or reading our previous article Segway Subdomain Takeover or the technical report.