The Risks of Ex-Domain Re-use on Websites and How to Stay Protected Against it

This article seeks to address a serious security risk of using an expired domain on websites, demonstrating the many threats that arise as a result of this situation.

The Challenges of Using Third-Party Domains

Today’s businesses are highly collaborative on the digital level. One of the main results is the growing dependency on external third-party scripts. Running scripts belonging to third-party domains cannot be avoided, as website visitors are also linked to various third-party services. Businesses are now creating active communication between a users’ browser with the third-party domains (i.e., remote domains) to access the needed data and get enhanced browsing experience.

For example, an average company may suddenly be using over 100 remote domains while communicating with its end-users. What happens when remote domains become inactive or expire? The vendor no longer uses them, which means that your website should not be using them as well. However, since they are probably not managed as an organization asset, they still have an active connection to the users. Now, if hackers gain control over these domains, they gain direct access to your website.

A use-case example: To demonstrate how risky expired domains can be, let’s look at a recent case I came across. This instance involved an active script that kept on loading information from an inactive domain. That expired domain was available for purchase for only $79. A gift for hackers. If it would have been exposed, any attacker would take advantage of this “bargain” within seconds.

Ex-domains: Be Alerted When It’s No Longer Active!

Here’s a scenario that many of us are familiar with: your website has been using a third-party script over the last few years and for some reason, the related third-party domain became inactive. As it often happens, the digital team didn’t remove the third-party code from the website. Due to this, the installed technology is still sending requests to this remote domain. No harm so far. Well, this is assuming you are lucky.

There are a few reasons to be worried. The first reason is that information is still being delivered to a vendor you no longer work with. This raises confidentiality issues as well as serious privacy challenges. The second reason, and probably the most alarming one, is the possibility of being breached. In this case, the scenario is simple: Over a period of time, this domain will be available for purchase again, meaning that whoever buys the domain, will automatically gain an active connection to your website. As you know, this is exactly what hackers are looking for. Unsurprisingly, attackers use many tools to detect such ex-domains, some easily accessible. These active connections can create two types of risks: sensitive data leakage and malicious script injection.

Data leakages

The less serious scenario refers to an expired external domain that keeps on getting the information “innocently”, even though it shouldn’t. In this case, sensitive data, like the user’s location, personal details, cookies and other types of confidential information, may be delivered to unwanted or irrelevant entities. This can result in data leakage and privacy breaches. With new privacy regulations like GDPR and CCPA now being enforced strictly, it can also result in hefty fines with serious legal and business implications.

Malicious script risks

The more serious scenario involves intentional malicious activity. In such cases, the external domain in question doesn’t only receive the sensitive data, it also gets requests referring to the script that should be running.

Let’s explain how it works: when you want to add a tag or a script to your website, you add a line to your source page along with the link to get the actual script.

<script src="very.goodsite.com" />

If “goodsite.com” has expired, the request to load the script will still be sent to this site, allowing the attacker to replace the script with a malicious one. By doing so, the attacker gains almost complete access to the website which can be referred to as persistent XSS. When a malicious script is running on your website, undetected, the risks are endless. A few of them are listed below:

Keylogging and Form-jacking

As an attacking method, cyber criminals use keylogging and form-jacking to record every keystroke made by users and steal sensitive information from any given value. Such instances are utilized by installed malicious third-parties, in order to steal the user’s data. Magecart is one of the most notorious threat actors, known for this kind of modus operandi.

Phishing Attacks

As part of phishing attacks, hackers try to add maliciously crafted submission forms to a website and then they entice the end-users by requesting them to enter their most valuable information, (i.e., financial data, medical records, social security numbers, and other types of sensitive information). The website users won’t be able to notice anything abnormal, and the script will remain undetected, doing what it is “supposed” to do.

Defacement Attacks

An installed malicious code on a website can easily alter or change the page. The classic scenario is a defacement attack, destroying the website to promote criminal or political agendas. Such changes can be conducted when the remote domain that streams the information is out of control. The Nagich attack in early 2019 demonstrates not only the reputational damage, but also destructive potential that can be unleashed through such an attack. This could have easily been escalated into a threatening ransom attack.

How should you avoid Ex-Domain re-use risks?

The regular security controls might verify that the script and the domains are adequately secured on launch day, but the question is, how would you know if it is still working as expected and is not compromised after a few months or years?

1. Keep the required scripts and minimize the number of remote domains. You can pre-approve or disapprove any of the remote domains. There are few tools available that can help you determine the validity of each remote domain.
2. Try to host as many scripts as you can on your own servers. This is essential to ensure the reduction of the number of used domains. Note, that locally stored scripts can still have active communications with a remote domain.
3. Use strict content security policies (CSP) to limit risk exposure. CSP is a great browser tool, but it can block unplanned requests. It also requires heavy maintenance. CSP tools are only recommended with additional supporting tools. Please check out my article about CSP pros and cons.
4. For sensitive untrusted scripts we recommend using Subresource Integrity (SRI).
5. You should use a monitoring tool to locate the various domains that are active and validate the security level for each one of them. This should be done on an ongoing basis.

The article presents my personal overview. If you are looking for a less technical version, please visit the lighter version, published by Reflectiz. We hope you find it useful. For more cybersecurity insights and briefings on third-party application security on websites, please visit the Reflectiz blog.