Introduction

While scanning our client’s networks for vulnerabilities, we’ve seen a trend of stale DNS records and SaaS solutions. This can lead to subdomain takeovers of external assets. This vulnerability occurs when a previously configured DNS record points to a non-existent third-party resource. The DNS record remains active since the host has been most likely deleted, allowing an attacker to claim the hosted service.

This gives the attacker complete control over the subdomain. When attackers gain access to the hosted service, they can conduct phishing attacks, bypass single-sign-on (SSO) protections, and perform other malicious redirects. Brand reputation can also be damaged using the attack.

In this article, we will look at a few different takeover methods, detail how we find them, show how they are exploited, and the easy solution to fixing this potentially severe vulnerability.

Takeover Tools

When testing for subdomain takeover vulnerabilities, it is essential to leverage the proper tools for scanning before continuing with the attack. Luckily, quite a few open-source tools are handy for this attack path. Nuclei from Project Discovery has a template for takeovers that can be useful in the initial scanning process. The takeover.py script was used in the following examples but has since been removed from GitHub. We have found that Subzy, a tool from PentestPad on GitHub, is another reliable subdomain takeover scanning tool. It is vital to utilize all available tools to determine the vulnerability before continuing on the exploitation path.

Help Scout Takeovers

During the reconnaissance phase of continuous penetration testing, we noticed many clients utilizing Help Scout. Help Scout is a platform that allows for collaboration with companies and their clients. You can use it for shared email inboxes, document sharing, live chats, etc.

In this particular instance, the client had used Help Scout in the past, and the DNS records for it were still valid. Let’s pretend this client is named Acme. In our initial scans, we noticed a URL titled “docs.acme.com” that we wanted to investigate further. Running the following command, we were able to verify that the Help Scout service was in use:

dig (URL) cname

When running the tool “takeover.py”, we were able to find that the specific subdomain was vulnerable to takeover:

Once we knew that the vulnerability was present, research on the hosting provider was done to understand how this takeover could take place. To perform this takeover, we had to execute the following steps:

Create our own fake Help Scout account:

Register the vulnerable subdomain under our own Help Scout account and customize the appearance of the site:

Once this was done, we navigated to the affected subdomain to see that our takeover was successful

Pantheon Takeovers

Pantheon is another standard provider susceptible to this type of attack in the vast network of services that are vulnerable to subdomain takeovers. Pantheon is a platform that allows users to build, host, and manage WordPress, Drupal, & NextJS sites. This platform allows for an all-in-one environment to create, make changes, and publish your site.

Sprocket often discovers clients vulnerable to Pantheon-based subdomain takeovers. A scan similar to the one previously shown was executed using the tool “takeover”:

Once the results of the script were examined, we visited the affected URL as further proof that the vulnerability existed. Specifically, the 404 error indicated the issue was present.

With further research to gain knowledge of the Pantheon platform, we determined that an attacker could follow the steps below to successfully takeover the affected DNS record.

Create an account with the hosting provider mentioned above (Pantheon subscription necessary)

Register the vulnerable domain/subdomain under its own Pantheon account (add custom domain under "Domain/HTTPS" menu).

Customize the appearance of the site and publish.

icon-info:

Note that Pantheon subscription prices were rather expensive for a single attack.


Wix Takeovers

Most folks who have created a website at least once are familiar with Wix. Creating and hosting a website with Wix is easy and an excellent option for anyone, regardless of web design knowledge. That does not, however, mean that Wix isn’t still vulnerable to subdomain takeovers like many other providers out there.

Scanning a client’s assets with tools like nuclei gave us an indication that one particular URL was vulnerable to takeover. When we tried visiting the URL, this is what we found:

This screenshot illustrates that the URL is not yet connected to a website. An attacker could then use Wix to claim the URL as their own and create a custom website, taking over the subdomain and using it for malicious purposes.

After a bit of research on Wix, it was determined that an attacker could follow the steps below to take over the affected URL successfully:

Create an account with the hosting provider mentioned above (Wix Premium account necessary)

Register the vulnerable domain/subdomain under its own Wix account ("Connect your own customized domain" button before publishing)

Customize the appearance of the site and publish

Remediation

While the risks associated with subdomain takeover are significant, the silver lining lies in the relatively straightforward nature of its remediation. The adage, "It’s always DNS," rings particularly true in this scenario. At Sprocket, we’ve formulated a comprehensive approach to address this vulnerability, encompassing both preventative and corrective measures:

  1. Audit and Clean-up DNS Records: Regularly review DNS records and promptly remove unused ones. For those still in use, ensure they point to IPs managed by the company. This proactive housekeeping minimizes the risk of subdomain hijacking.
  2. Policy Implementation for DNS Record Management: Develop and enforce policies that include rigorous checks to eliminate stale DNS records post-project completion. This step ensures that once a project is dismantled, its associated DNS records don't linger and become potential vulnerabilities.
  3. Monitoring and Alerting: Utilize tools like Google Search Console or AWS monitoring services to monitor traffic patterns associated with your apex domain. Anomalies in traffic can be early indicators of a subdomain takeover attempt, and prompt alerts enable swift response.
  4. Automated DNS Management: Integrate DNS entry updates into your infrastructure deployment and management pipelines. Using automation tools, you can ensure that DNS entries are dynamically updated in line with the changes in your infrastructure, reducing the likelihood of outdated records.
  5. Regular Security Training and Awareness: Educate your IT and development teams about the risks associated with DNS management. Regular training sessions can keep everyone informed about best practices and the importance of DNS record hygiene.
  6. Utilize Subdomain Verification Tools: Specialized tools can scan for and identify potential subdomain takeover vulnerabilities. Regular use of these tools can be a part of routine security audits.

By diligently following these remediation steps, any vulnerabilities related to stale DNS records can be effectively mitigated. It’s crucial to understand that subdomain takeover isn't just a technical issue but also a process and policy challenge. Therefore, a holistic approach combining technology, policy, and education is vital for robust protection against this threat.

Conclusion

Although subdomain takeovers are a high-severity vulnerability, the one good thing is that the remediation steps are relatively straightforward. If this vulnerability goes undetected for long, attackers can cause severe damage after taking over a subdomain. Attackers are getting super creative and thorough in their attacks, which can be chained together to deal serious damage to companies in many ways.

One saving grace for these organizations is that they continuously monitor and test their attack surface to prevent issues like this from lingering for too long. Continuous penetration testing is the best way to solidify that vulnerabilities are constantly being tested for and can be remediated much quicker than legacy testing methods.

Companies should stay on top of monitoring their DNS records to prevent issues like this from hurting them in the future. Of course, something silly like this can translate into a severe vulnerability. It’s always DNS, right?

References

Tools Used