Subdomain takeover continues to be a major security threat for organizations using cloud to deliver public services. Learn how they happen—and how you can keep your organizations’ cloud environments secure.
What are subdomain takeovers?
Hostile subdomain takeovers are when attackers gain control over a subdomain of a target domain. There are a variety of means for attackers to enact these takeovers, but it most often occurs due to vulnerabilities from a lack of oversight of cloud environments.
How Subdomain Takeovers Occur
Cloud infrastructure allows organizations to quickly deploy environments and tear them down on-demand. After setup, however, organizations often overlook removing the domain name system (DNS) Aliases(A record) and canonical names(CNAME record). This leads to a dangling domain (also known as an “orphaned domain”) record that is no longer associated with an active website or an online resource. This dangling domain becomes a vulnerability that is an easy target for attackers.
For example, with AWS, a dangling domain could refer to a domain that was previously associated with an Amazon S3 bucket, CloudFront distribution or on ElasticBeanstalk, but is no longer being used or is misconfigured or mismatched. A similar case can exist in Azure Storage, Azure DNS, Google Storage, and Google Cloud DNS.
The threats of subdomain takeover explained:
When attackers succeed in a hostile subdomain takeover, they potentially can:
- Provide their own virtual host to post content on the hijacked domain
- Read private cookies set from the main domain
- Perform cross-site scripting between domains
- Bypass content security policies
- Access protected information (including private data and logins)
- Share malicious content and malware
Why are dangling domains a potent attack vector?
Dangling domains can be a security risk because they may be vulnerable to subdomain takeovers or other types of attacks. In this scenario, an attacker can take control of a subdomain (e.g., “blog.normalyze.ai”) that was configured to point to a cloud service that is no longer in use or has otherwise been misconfigured. This vulnerability allows the attacker to host malicious content on the subdomain and potentially compromise the security of the main domain (e.g., “normalyze.ai”). We’ve previously explored subdomain takeover as one of the major attack vectors of cloud-borne threat actors in our recent talk at Black Hat. We also highlighted use-cases where Alias records can be a vector for subdomain takeover in misconfigured Route53 records in AWS.
Figure 1: High level representation of pointing a subdomain to an object in S3
The attack usually begins by enumerating through a standard list of subdomain names for any organization. Once the subdomains are identified, the attacker can run a simple dig query to identify the CNAME or Alias record associated with the subdomain. In the example below, the CNAME points to an S3 bucket containing a static index.html file. In the case of Azure, this would be a blob storage link or a Google storage link for GCP. With this configuration in place, anyone visiting test.normalyze-security.link will be served the static index.html page on the S3 bucket defined in the CNAME(Figure 1).
If the bucket is deleted later on and the DNS Route53 entry still exists, this means that the subdomain is now pointing to a non-existent resource. An attacker can now leverage this mis-configuration to register a new bucket with the same name in their account (Figure 2).
Figure 2: Bucket deletion leading to a Dangling subdomain entry.
Since Bucket names are globally unique, the DNS setting will route the traffic from the subdomain to the index.html file hosted in the attacker’s cloud account(Figure 3).
DSPM’s role as a subdomain takeover scanner
Normalyze generates a graph that continuously monitors the changes in cloud provider-based services mentioned above. Any change is updated in our graph incrementally. Consider an example of AWS Route53. The Normalyze platform queries required metadata information about DNS Hosted Zones, DNS records, Elastic IP addresses etc. Each entity metadata is later monitored to establish its relationships with other entities. In the example, DNS records have DNS host names registered with the CNAME records.
Once Normalyze has all the entity metadata (continuously updated), it queries to check if any record could be traced to any other resource within that account through a series of relationships in the graph. In the example, A CNAME record value from AWS Route53 is queried to see if it is linked to any of the other resources like S3 Bucket, EC2 Instance, etc within that account. If such a relationship does not exist in Normalyze graph, it is deemed to be a risk with a publicly exposed CNAME record without a valid backend. A records, AAAA records, NS record are scouted regularly for a similar relationship with a valid backend entity of that cloud provider account in the Normalyze graph.
Figure 4: Normalyze Risk Dashboard highlighting subdomain takeover risk
Once a risk is identified, customers are alerted about the dangling entry in the DNS setting, along with details like the Record name, Record Type, Owner and possible Remediation actions.
Figure 5: Risk detail for the DNS record with missing resource
Automated action can be taken on the risk like creating a Jira issue, sending an email alert or even sending a Slack notification about the identified risk.
Figure 6: Normalyze Risk automation
Already using Normalyze? Click here to go directly to a report of your exposure to subdomain takeover!
How to Prevent Subdomain Takeover
The following steps can help security teams minimize the risk of subdomain takeover and resulting threats to cloud data.
1. Reorder cleanup process
The usual order of clean up or deletion should begin from the DNS service like Route53, Azure DNS or Google Cloud DNS; followed by the CDN entry and then finally the deletion of the resource. This is the exact reverse order in which the services are created in the first place.
2. Review DNS procedures
Regularly review and update the configuration of your cloud DNS service to ensure that the use private DNS routing or hosted zone setting when creating DNS routing for internal testing and routing. Unless the service is not required to be hosted on the internet, avoid using the public hosted zone setting. This can prevent unnecessary exposure of internal services through DNS records.
3. Use a cloud data security tool
Use a continuous cloud data security scanning solution like Normalyze to gain complete visibility into your infrastructure across all cloud environments.See for yourself and try Normalyze for free.
Resources
- Prevent dangling DNS entries and avoid subdomain takeover (Microsoft)
- Working with Route53 Records (Amazon)
- Corelight transforms data security with Normalyze (Normalyze)
