World Map Security Thumbnail Image
09 October 2020

Cloud Exploits: The Risk From Subdomain Takeovers and How to Prevent Them From Happening

Andy Condliffe

Thirty three billion records were exposed in 2018 and 2019 as a result of improper cloud security. Since 2019, Synack has seen an increase of over 300% in the number of penetration tests performed against cloud environments. During cloud penetration tests, Synack often finds configuration errors that result in, or could lead to, serious problems, such as misconfigured publicly visible AWS S3 storage buckets. It is estimated that cloud misconfigurations cost companies worldwide nearly $5 trillion in 2018 and 2019 alone.

While misconfigurations are a widely known cloud vulnerability category, subdomain takeovers, a particularly severe issue, are an area Synack is commonly seeing during cloud focused penetration tests. Cloud infrastructure allows organizations to quickly deploy environments and tear them down when unneeded. However, when organizations are finished they often overlook removing the domain name system (DNS) aliases configured during the setup (this is known as leaving a dangling pointer). This mistake could result in unknowingly hosting malware and phishing sites. Phishing campaigns that hijack websites within the domain of the company are less suspicious and customers and employees are more likely to fall prey to these attacks. Once an attacker is in control of a subdomain, they can gain chain-of-trust credibility beyond web assets resulting in customer’s or employees logging into an attacker’s own infrastructure. The reputational damage from a breach like this could be huge and result in loss of revenue and expenses from lawsuits. 

Why do subdomains get created? 

While many environments include DNS names for objects, the names themselves are usually part of the cloud provider’s domain. Development teams will create aliases using their own domain for a better, more trusting user experience. For example, when organizations launch new micro sites as part of marketing and brand campaigns, the site is accessed via a content delivery network (CDN) in the cloud to ensure a fast response and good customer experience. An example of a default CDN address could be something like “cdnhost.azureedge.net”, which could be confusing for a user. In order to maintain a cohesive customer experience the organization will create their own alias, such as “campaign.companyname.com”, that points to and hides away the underlying cloud infrastructure.

How do malicious actors exploit subdomain misconfigurations?

Below is an example using the “dig” DNS utility. This example can be used to demonstrate a test domain that has a cloud server alias. Figure 1 is an example of a working alias as demonstrated through the “NOERROR” status and has a valid IP address.

Figure 1.

In Figure 2, the Microsoft Azure endpoint has been removed, but the DNS information has not been updated. The status of the request has changed from “NOERROR” to “NXDOMAIN” because the actual endpoint (and the IP addresses associated to it) no longer exists, but from the adversary’s perspective the alias “demo2.axiant.net” is still configured.

Figure 2.

At this point an attacker can now create their own endpoint named, “cdnabc123.azureedge.net”. In our example this is accomplished within Microsoft’s popular Azure cloud.

When a user visits “demo.axiant.net” they would now instead be interacting with the server owned by the malicious actor. This allows an attacker to create a phishing campaign using a trusted domain name. A phishing campaign using a recognizable domain name with a valid SSL certificate is far more convincing and it is much more likely that customers and employees would inherently trust it. 

How to remediate subdomain misconfigurations

The good news is that remediating this issue is not that difficult. A best practice is to continuously clean up DNS records especially whenever there is a change. You can do this by using your internal security team and a standard DNS automated API based service or by regularly leveraging a platform like Synack to verify that your cloud assets do not have any subdomain misconfigurations. Having a regular protocol in place for the creation and removal of DNS entries, through either an automated tool or having a regular cadence of testing with Synack, reduces the risk of leaving dangling pointers behind after the environment has been removed.

 

  1. DivyCloud:2020 Cloud Misconfigurations Report
  2. Subdomain takeovers are not limited to the Azure cloud, many other hosts are susceptible to attack such as S3, WordPress, Zendesk, and Github (this list is not exhaustive).