Subdomain takeover — protect your website against it!

Subdomains underpin the structure of the modern internet. They allow business owners to organize and integrate specific services within a website. However, the vast adoption of subdomains has made them a prime target of cybercriminals looking to exploit subdomain takeover vulnerabilities.

Weaknesses in DNS implementation and a lack of proper termination for third party services significantly contribute to the risk of subdomain takeover. This exposure highlights the critical role of robust security measures and proactive subdomain management in safeguardingyour online presence.

In this comprehensive guide to subdomain hijacking, we explore the nature of attacks, exploring vulnerabilities and exploits. You will learn what aspects of subdomain configuration can manifest as potential vulnerabilities and understand how to protect your website from subdomain takeover.

Key points

Learn about the various aspects of subdomain takeover prevention, including:

• The role of subdomains in your website's content organization
• What makes subdomains vulnerable to hijacking
• Vulnerability regarding weaknesses in your DNS configuration
• Use cases that involving bad actors that exploit SaaS platforms, CNAME records, and custom nameservers
• How to protect your website against subdomain takeover — 3 important considerations
  

The role of subdomains in your website's content organization

Subdomains play a pivotal role in organizing content within a website. Many website owners opt to separate certain content and services from the main website through subdomains, enhancing navigation and overall user experience. Additionally, using subdomains enables business owners to leverage various website-building frameworks and technologies, and even host subdomains on different hosting platforms.

For example, you may take advantage of the various software-as-a-service (SaaS) platforms to power additional services such as a blog or an online store. This approach allows for complete separation of the subdomains from the main domain in terms of hosting infrastructure.

The ability to create subdomains independent of the website hosted under the main domain name makes subdomains an invaluable tool for every business owner. However, the increased complexity associated with this approach can significantly expand the attack surface, presenting more opportunities for potential subdomain takeover.

The ability to make subdomains independent of the website hosted under the main domain name positions subdomains as an invaluable tool for every business owner. However, the increased complexity associated with this approach can significantly expand the attack surface, presenting more opportunities for potential subdomain takeover.

Subdomain takeover — what makes subdomains vulnerable to hijacking?

Subdomain takeover happens when an attacker is able to seize control of a specific subdomain by exploiting a subdomain takeover vulnerability. At its core, subdomain hijacking may seem similar to other cyberattacks aimed at providing malicious actors control over the target website. What distinguishes it is that the attacker doesn't gain access to the website's files — instead, they acquire control over the domain name.

This capability enables the attacker to redirect incoming requests to the legitimate subdomain toward a malicious resource, which would otherwise only be achievable using domain spoofing techniques. In the event of subdomain hijacking, website visitors won't notice any danger as they will still be using the domain name that previously directed them to a legitimate website.

Before delving into real subdomain takeover examples, it's crucial to understand the factors that manifest as potential weaknesses in subdomain configuration, giving rise to subdomain takeover vulnerabilities. It's important to note, however, that none of the factors discussed below can be considered a subdomain takeover vulnerability in itself. Instead, it's a combination of multiple factors that make subdomain takeover possible.

Subdomain takeover vulnerability regarding weaknesses in your DNS configuration

Making subdomains independent of the main domain in terms of hosting infrastructure requires a tailored configuration of the domain name system (DNS). To ensure proper resolution and guide visitors to the specific platform they are hosted on, subdomains require their own DNS records in the DNS zone created for the main domain name. Let's review some common considerations when setting up DNS for a subdomain hosted independently of the main domain, highlighting potential weaknesses in DNS configuration in the process.

Weakness #1. Using custom DNS nameservers

One of the most notable features of using subdomains in terms of DNS is the ability to utilize a distinct set of authoritative nameservers for them. This capability allows for independent DNS management for each subdomain, effectively separating the DNS zones for the main domain and each respective subdomain.

Specifying a different set of authoritative nameservers for a subdomain involves the configuration of separate nameserver (NS) records that will point the resolvers to the DNS zone for it. This way, the DNS zone of the main domain name would only contain the NS records for the subdomain, which would guide the resolution process for it to other authoritative nameservers. All other DNS records for the subdomain will be configured in a separate DNS zone.

One potential weakness of this setup is that often, website owners configure custom nameservers for subdomains, which are not exclusively dedicated to just DNS resolution but may also host other services. As a result, utilizing custom nameservers provides weaker security for DNS than hosting DNS on nameservers offered by domain registrars and hosting providers.

Furthermore, if an attacker gains unauthorized administrative access to a custom nameserver configured as authoritative for a website, the potential for harm is immense. The scope of attack could encompass more than just the possibility of subdomain takeover itself. However, for the sake of our discussion, let's concentrate exclusively on subdomain takeover.

Gaining access to the DNS nameservers enables attackers to manipulate DNS zones for websites relying on these nameservers as authoritative. This gives attackers the ability to redirect website visitors to malicious resources and facilitate other cyberattacks such as phishing, clickjacking, and cross-site scripting (XSS), among others.

Weakness #2. Using CNAME records to configure DNS resolution for a subdomain

While subdomains can be assigned separate A DNS records directing them to the IP address of the web server, many website owners opt to configure DNS resolution for subdomains using CNAME records. If a subdomain is hosted on the same server as the main website, using the domain name of the main website as the CNAME target offers a straightforward method for configuring DNS.

Potential challenges may emerge when a website owner employs a SaaS solution to drive the functionality of the subdomain. For example, you may want to create an online store under the shop.yourwebsite.com subdomain by taking advantage of one of the popular SaaS ecommerce solutions. Most SaaS solutions streamline the website creation process by automatically assigning domain names for the websites built on their platforms. This automated assignment simplifies the setup, enabling users to create a web presence smoothly in a minimal amount of time.

However, If you aim to make the newly created online store accessible to your customers using shop.yourwebsite.com, you'll need to link it to the SaaS platform by configuring a DNS CNAME record for it. The target of the CNAME record would be a specific endpoint defined by the SaaS provider. In some cases, the target of the CNAME record may be identical for all users of a particular SaaS platform, potentially introducing another subdomain takeover vulnerability.

Suppose you cancel the online store at some point but fail to remove the DNS CNAME record you previously set up for shop.yourwebsite.com. In that case, an attacker can attach shop.yourwebsite.com to a new store within that SaaS platform and direct your customers to malicious content.

Subdomain hijacking — 3 real world use cases

Now that we have explored what potential weaknesses in subdomain configuration can transform into subdomain takeover vulnerabilities, let's review three real scenarios of subdomain takeover attacks. In the scenarios below, mywebsite.com and myotherwebsite.com will act as the domain names you registered that are used for websites you own.

Subdomain takeover example #1. Using a SaaS platform

The subdomain takeover scenario involving a SaaS hosting provider is the most common.

1.1. You create a website on a SaaS platform

You create an online store on one of the SaaS ecommerce platforms. The store you created is assigned the mystore.ecommerceplatform.com domain name by the SaaS provider.

1.2. You connect a subdomain to the website hosted on the SaaS platform

You wish to make your store accessible using a subdomain such as shop.mywebsite.com. In order to achieve this, you connect the subdomain to your store in the settings of your ecommerce platform account and add a CNAME record for shop.mywebsite.com pointing to the endpoint specified by the SaaS provider, such as shops.ecommerceplatfrom.com. The same endpoint allows all users of the ecommerce platform to use an alternate domain name for their stores.

Connecting your subdomain shop.myeebsite.com to your online store mystore.ecommerceplatform.com enables your customers to enter the shop subdomain in their browser to visit your online store.

1.3. You cancel an online store with the SaaS provider

At some point you decide to rebuild your online store using open source store building platforms such as WooCommerce built on WordPress and move it to another hosting platform. You cancel your account with the SaaS provider and start working on developing a new store.

1.4. The attacker performs a subdomain takeover

Although you have removed the old store and canceled your account, you have forgotten to remove the CNAME DNS record that still points the shop subdomain to the ecommerce platform. This cleanup task omission for an old store leaves your subdomain shop.mywebsite.com vulnerable to subdomain takeover.

The attacker registers an account with the SaaS ecommerce platform that you previously used, creates a malicious website disguised as an online store, and connects your subdomain shop.mywebsite.com to it. The malicious actor has performed a subdomain takeover attack and is now in control of your subdomain, ready to defraud your customers and steal their payment information.

The attack is possible due to the fact that the old CNAME record for your subdomain is still present in the DNS zone, which serves as the verification of domain ownership for the ecommerce platform. Most of the time, if a subdomain is not connected to any other store within the platform, the SaaS provider does not require any additional verification from the user other than the presence of a CNAME DNS record pointing to a specific endpoint.

Subdomain takeover example #2. Using a CNAME record to redirect a subdomain to another website

2.1. You set up a redirect using a CNAME record

You wish to use subdomain.mywebsite.com as an alternate domain name for another website you own, granting your customers the ability to use multiple domain names to open it. To achieve this, you point subdomain.mywebsite.com to myotherwebsite.com using a CNAME record. Now, every time you enter subdomain.mywebsite.com in the browser, you will be directed to the content of myotherwebsite.com.

2.2. You fail to renew a domain name

At some point, you fail to renew the domain name myotherwebsite.com, and it becomes available for purchase. You wish to register a different domain name to use instead of the old one. However, you don't immediately do so and leave the existing CNAME record for subdomain.mywebsite.com in the DNS zone.

2.3. The attacker performs a subdomain takeover

Seeing that you failed to renew myotherwebsite.com, the attacker registers this domain name and builds a malicious website that will be available under it. As the CNAME record you previously created is still present in the DNS zone, the cybercriminal is now able to direct your customers to the malicious website to distribute malware and steal their personal information. This situation is another example of successful subdomain takeover.

Subdomain takeover example #3. Using custom nameservers vulnerable to attack

3.1. You set up poorly secured custom nameservers

You register custom nameservers that will act as authoritative for your subdomain. However, the nameservers lack sufficient security measures, which makes them vulnerable to attack.

3.2. An attacker identifies a vulnerability in DNS resolution

The attacker discovers that the custom nameservers are poorly secured by taking advantage of network reconnaissance techniques. Exploiting a severe vulnerability, the cybercriminal gains unauthorized access to the server hosting the DNS zone for subdomain.mywebsite.com.

3.3. The attacker performs subdomain takeover

The attacker modifies the existing DNS records, which allows them to point the subdomain to a server they control, performing a full subdomain takeover.

Depending on the level of access the attacker acquired, the attack may go far beyond just subdomain hijacking. With sufficient user privileges, the malicious actor may be able to take advantage of the server's resources to launch further attacks such as denial of service (DoS), steal sensitive data, or even wipe the whole server from existence.

How to protect your website against subdomain takeover — 3 important considerations

The key to protecting your website against subdomain takeover lies in mitigating all potential subdomain takeover vulnerabilities that may arise from specific weaknesses in DNS and hosting configuration. Taking a vigilant approach to domain management and the website security aspects involved is truly invaluable in safeguarding your online presence.

1. Take a proactive approach to domain management

Unlike root domains, subdomains do not require additional registration. Once you purchase a domain name, you can configure as many subdomains as you wish. However, if a substantial number of domain names are configured, maintaining comprehensive oversight of all elements of your online presence may become a challenging task.

Adopt a proactive approach to domain management, ensuring that all domain names under your ownership undergo timely renewals and are mapped to an existing website if DNS records are configured for them. If you intend to retire or rebuild a website and migrate it to another hosting platform, begin by removing its DNS records.

Avoid using wildcard DNS records. Wildcard DNS records allow for many-to-many mapping, enabling you to point all subdomains to a specific location. Although initially appearing convenient, using wildcards in domain name resolution can significantly increase the attack surface, rendering your subdomains vulnerable to malicious exploitation. Opting for setting up specific DNS records for each subdomain minimizes the potential for subdomain takeover and provides better control over your digital resources.

2. Choose a trusted provider

Selecting a reliable web hosting provider is a must for ensuring high security of your server infrastructure. Whether you opt for shared hosting solutions or wish to set up your website in a private cloud environment, your hosting provider is responsible for making the platform secure and reliable.

Poor website isolation, outdated technology, and other substantial security flaws pose a major risk to your website, leaving it vulnerable to a vast array of cyberattacks, including subdomain takeover. Ensure that your hosting provider implements all the necessary security measures and mitigates all potential threats in a timely manner. These precautionary actions should include rapid patching of critical vulnerabilities and making consistent efforts to improve the security of all hosted environments.

3. Ensure DNS zone security

Unless you can ensure a high level of security for your DNS implementation, avoid setting up custom nameservers for your websites. Most of the time, when website owners opt to use custom nameservers, the servers used for that purpose also host other critical services that their websites rely on. This approach in general, and the lack of sufficient security measures in particular, often leads to a wide range of security concerns, leaving the infrastructure vulnerable to a multitude of cyberattacks.

Authorized domain registrars and DNS providers, including Liquid Web, maintain a robust infrastructure of DNS nameservers. Restricting all incoming requests solely to DNS resolution, ensuring high availability and disaster recovery, and employing additional protective measures allow them to ensure top-notch security for all hosted DNS zones and provide reliable DNS resolution.

Protect your digital assets with Liquid Web

In today's sophisticated digital environment, you must have more than one defense level. Relying on a single layer of protection is no longer sufficient to harden your online presence against hackers. Despite continuous efforts of hosting providers to ensure a high level of security for all hosted environments, certain weaknesses in DNS configuration may still leave your websites vulnerable to subdomain takeover and other vicious cyberattacks. This fact makes it critical for website owners to adopt a proactive approach to website security.

Liquid Web is dedicated to ensuring enterprise-grade security for all hosted environments. A robust suite of security features, comprehensive monitoring, and unwavering commitment to compliance standards makes Liquid Web a reliable choice for businesses seeking secure and compliant hosting solutions. Whether you opt for dedicated hosting to maintain complete control of your server environment or select our cloud hosting solutions for added flexibility, Liquid Web ensures a seamless hosting experience with an emphasis on security and performance.