The Risks of Ex-Domain Re-use on Websites and How to Stay Protected Against It
This article seeks to address a serious issue that has been detected by our platform, including in major enterprises. It concerns the risk of using an undetected “Ex-Domain” (expired domain) on websites, demonstrating the many threats that lurk as a result of this situation.
The Challenges of Using Third-Party Domains
Today’s businesses are highly collaborative at a digital level. One of the main effects of it, is the growing dependency of any online business on external technology vendors, i.e., third-party scripts. Running scripts belonging to third-party domains cannot be avoided, as your website visitors are bound to be linked to various third-party services. Subsequently, their browsers communicate with these third-party domains (i.e., remote domains) to provide needed data and get enhanced browsing experience.
Since all of them are running on the client-side, most changes will remain unnoticed and undetected by your web security controls. Obviously, this creates an appealing opportunity for cyber criminals and attacking groups to conduct silent attacks that can remain undetected for long periods.
An average company for example, may suddenly be using over 100 remote domains communicating with its end-users. Well, that’s part of the new challenge that organizations face today while using third-parties on their websites. These third-parties are requiring additional monitoring ability to understand the new and undetected risk clearly. In your security development life-cycle, you might be able to approve the script itself, but quite often, the remote domain hosted by the vendor will be left unchecked.
What happens when remote domains become inactive or expired? The vendor no longer uses them, meaning, your website should not be using them as well. However, since they are not managed as an organization asset, they still have active connection to your website and your users. Now, if hackers gain control over these domains, they will gain direct access to your website. The consequences can be devastating!
A use-case example: To demonstrate how risky expired domains can be, let’s look at a recent case we 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 in seconds. Luckily, our platform detected the expired domain on the very first scan.
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 domain became inactive. As 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, only if 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, 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 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 can easily be accessible. Consequently, these active connections can create two types of risks: sensitive data leakage and malicious script injection.
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 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, e.g., GDPR and CCPA, it can also result in data privacy violations, legal sanctions and fines.
Malicious script risks
The more serious scenario, that CiSOs should prevent in advance, involves intended malicious activity. In such a case, 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” is expired, the request to load the script will still be sent to this site, providing it with the ability for an attacker to replace the script, with his or her own. By doing so, the attacker gains almost full access to the website which can be referred to as persistent XSS; Data theft; phishing attacks. When a malicious script is running on your website, undetected, the risks are endless and hidden.
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.
As part of phishing attacks, hackers try to add maliciously crafted submission forms onto 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 (SSN) and other types of sensitive information. The website users won’t be able to notice anything abnormal, and the script will remain undetectable, doing what it is “supposed” to do.
An installed code on a website can easily alter or change the page to its own malicious goals. The classic scenario is a defacement attack, destroying the website for criminal and political agendas. Such a change can be conducted when the remote domain that streams the information is out of control. The Nagich attack we mentioned in early 2019, demonstrates not only the reputational damage, but also a destructive potential that can be unleashed through such an attack, and could have even turned 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 afterward, say after few months or years? And the more important question is, who is in charge of verifying and validating it?
According to our cyber-security experts, website owners should implement a minimum-requirement methodology:
- 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.
- Try to host as many scripts as you can on your own servers. This is essential to ensure the reduction of the number of domains used. Note, that locally stored scripts can still have active communications with a remote domain.
- 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 recommend with additional supporting tools.
- For sensitive untrusted scripts we recommend using Subresource Integrity (SRI).
- You should use a monitoring tool to locate the various domains that are active and validate the security level for each. This should be done on ongoing basis.
In this case, the modus-operandi is quite different to the usual security controls, mainly because the real “action” occurs on the client-side, where commonly used security perimeters don’t look. A proper solution needs to provide an ongoing dynamic assessment of all the used and unused third-party scripts and remote-domains, to ensure that none of them creates a risk for the website.
Want to check if your website uses expired domains? Use our contact form.
No installation is required, we only need a URL!
* The particular risk is based on several real events that is being monitored by us as part of our ongoing activities. For obvious reasons, the involved party remains confidential and anonymous, and any identification details were omitted.