Subdomain Takeover: Detecting and Mitigating with Prisma Cloud

With the adoption of cloud services for hosted content and domain registrations, subdomain takeover exploitations have become a common attack vector in the cloud. Subdomain takeover is a common vulnerability that allows an attacker to gain control over a subdomain of a target domain and redirect users intended for an organization's domain to a website that performs malicious activities, such as phishing campaigns, stealing user cookies, etc.

In this post, I’ll explain one of the scenarios for subdomain takeover in AWS Route53 that uses a non-existing AWS S3 bucket. I’ll also show you how Prisma Cloud can be used to detect vulnerable subdomain domain entries.

Technical Details of Subdomain Takeovers

Cloud providers allow organizations to quickly deploy environments and shut them down when unneeded. After a user creates a new cloud service, the cloud provider usually generates a unique domain name, which is used to access the resource created.

The URL identifying unique cloud resources comes in the format of customer-provided-name.cloudprovider.com, where cloudprovider.com is a base domain owned by the cloud provider.

If the cloud service registered by an organization is meant to be public (ex: e-commerce store, public web pages), the organization might want to have it present as a part of their domain. This is because of branding and user convenience (e.g., shop.organization.com looks better than organizationshopping.cloudproivider.com). In this case, the organization can follow two approaches.

1. HTTP 301/302 redirects: 301 and 302 are HTTP response codes that redirect the browser from the current URL to another URL. In the context of cloud services, the first request is made to a domain name of an organization (e.g., shop.organization.com) and then a redirect is made to a domain name of cloud providers (e.g., organizationshopping.cloudprovider.com).

2. CNAME record: CNAME is a record type that is being used by the DNS resolver to resolve the domain names to their respective servers or domains. When a CNAME record is present for a sub-domain, then a call to the sub-domain will be resolved into its CNAME record.

For Example shop.organization.com is a subdomain of organization.com. If the subdomain has organizationshopping.cloudprovider.com as it’s CNAME, then a DNS will ultimately resolve shop.organization.com to address organizationshopping.cloudprovider.com

As cloud providers realize that customers request such behavior, cloud providers support the CNAME record delegation.

If the CNAME record method is used, the possibility of subdomain takeovers comes into play. Even though the cloud provider owns the base domain of the canonical domain name, subdomain takeover is still possible.

When an organization is operating with different cloud providers, the top level domain (TLD) of the cloud resource endpoint URL will be different for different cloud providers. For example:

• Amazon: .cloudfront.net, .s3.amazonaws.com, .awsptr.com, .elasticbeanstalk.com
• Azure: .azurewebsites.net, .cloudapp.net, .azure-api.net, .trafficmanager.net, .azureedge.net, .cloudapp.azure.com
• Google: ghs.google.com, ghs.googlehosted.com, .ghs-ssl.googlehosted.com

When the cloud resource has been deleted, but the DNS information has not been updated, the canonical domain name (alias of that cloud resource) attached with the subdomain’s CNAME record entry will still be present, At this point, an attacker or an anonymous cloud user can now create their own endpoint with the same resource name to hijack/exploit the actual subdomain.

Detecting Subdomain Takeover Opportunities

Detecting possible subdomain takeover opportunities isn't complicated. Consider an example where a company had AWS Route 53 managing the company’s domain DNS entries. If a subdomain is pointing towards a non-existing cloud resource (say an AWS S3 bucket) through its CNAME records, the subdomain will ultimately resolve the S3 bucket endpoint URL and there will be a 404 status code with a generic error message from AWS because the bucket does not exist.

This is because the DNS entries were not updated when the bucket was deleted and the CNAME record is still present.

In this situation, a subdomain takeover can be exploited by creating an S3 bucket with the same name and same region. In this way, the “Route Traffic To” value in the CNAME record will be again pointing to an existing s3 bucket. The difference is the bucket is now owned by an anonymous cloud user (attacker) and not the company itself.

If the anonymous cloud user has malicious intent, they can take over the subdomain until the company realizes the event and remove the CNAME entry pointing to that resource.

Exploitation of Subdomain

In the event of an AWS S3 Subdomain takeover, the website hosting format for the subdomain identifying the unique cloud resource (bucket) is bucket-name.s3-website.region-name.amazonaws.com. The CNAME record shopping.organization.com (source domain) redirects to shopping.organization.s3-website.ap-south-1.amazonaws.com (resource).

When shopping.organization.com (bucket name) is already in existence, then AWS will show an error, and exploitation will not be possible.

This subdomain takeover is complete if the bucket is successfully created. The attacker can configure the S3 bucket to host a static website and use the vulnerable subdomain to run phishing campaigns and fulfill other malicious intents.

Misuse & Impact

After an attacker takes over a legitimate domain name, it’s almost impossible for a user to tell whether the content on the domain is provided by a legitimate party or an attacker. Users are then unaware of malicious activity. Spam filters and other security measurements are also less likely to trigger the email as spam because it contains trusted domain names. The reputational damage from a breach like this could be significant and result in loss of revenue and expenses from lawsuits.

Attacker-controlled domain names make a perfect scenario for phishing campaigns because browsers performing the DNS resolution on affected or vulnerable resources will show whatever is received, thinking that it’s legitimate.

This attack can be enhanced by generating a valid SSL certificate. Certificate authorities, such as Let’s Encrypt, allow automatic verification of domain ownership by content verification. That is, if there is specific content placed on a specific URL path, Let’s Encrypt will approve the issuance of a certificate for a given domain.

With some takeovers, the attacker can also leverage the attack by stealing cookies. One of those scenarios may occur when the cookies of the primary domain are issued for wildcard domains where the primary domain is using a cookie-based Single Sign On (SSO) system. In this scenario, any user can log onto the domain and use the same session cookie across a wide range of subdomains.

Suppose, for instance, that a domain is using session cookies for a wildcard domain. If one subdomain is vulnerable to subdomain takeover, the only thing for gathering a user's session cookie is to trick them into visiting the vulnerable subdomain. If this happens, the session cookie is automatically sent with the HTTP request and an attacker can extract the session cookies of the users for that primary domain. Again, this is because the primary domain is using a cookie-based SSO system where cookies are shared across the wildcard domain. The attacker can then return and use those session cookies to log into its primary domain as other users.

Mitigations

The mitigation strategy for domain names already vulnerable to cloud-based subdomain takeover attacks is straightforward:

• Remove the affected DNS record. To prevent subdomain takeover in the future, organizations should change the process of creating and destructing resources in their cloud infrastructure.

In the case of resource creation, the DNS record creation has to be the last step in this process. Doing so will prevent DNS records from pointing to a non-existing domain.

For resource destruction, DNS records need to be removed as the first step in this process.

Prisma Cloud Detection Capabilities

Prisma Cloud provides visibility and security across cloud environments, helping organizations identify and remediate potential vulnerabilities and threats.

We can use Prisma Cloud to verify that assets do not have any subdomain misconfigurations for subdomain takeover events. In the image below, we are releasing a policy for discussed AWS events leading to subdomain takeovers.

Policy Name:

AWS Route 53 Hosted Zone having dangling DNS record with subdomain takeover risk

Prisma Cloud users can find affected subdomains in their Route53 using the RQL investigative query.

If any of the domain’s DNS records from AWS Route53 are pointing to a non-existing AWS S3 Bucket, Prisma Cloud will detect the event and immediately raise an alert for the domain.

Testing with Prisma Cloud reduces the risk of leaving dangling pointers behind after the cloud resource has been removed.

Learn More

Prisma Cloud’s Cloud Security Posture Management (CSPM) solution reduces risk across multicloud environments by proactively identifying and remediating critical threats and misconfigurations. For an independent market review to discover how Prisma Cloud stacks up against other CSPM solutions, read the GigaOm Radar for Cloud Security Posture Management Report.