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 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 regular security controls. Obviously, this creates an appealing opportunity for cyber criminals and attacking groups, like Magecart, to conduct silent attacks that can remain undetected for long periods.
An average company may suddenly be using over 100 remote domains communicating with its users. Well, that’s part of the new challenge of using third-parties on websites organizations face today. These third-parties could bypass the regular security controls in place, 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 $89, a gift for hackers. If it would have been exposed, any attacker would take advantage of this bargain in seconds. Luckily (for our client) our platform detected the expired domain on the very first day of us working together.
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 an old inactive 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 while others are only available on the darknet. Consequently, these active connections can create two types of devastating 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 receives 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 site 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 to Solve Your Expired Domain Reuse Issue?
To understand how serious it could be, we should look at the regular security procedures in such cases. Usually the process refers to code developed in-house during pre-production. But what happen when your website is live and running?
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?
How should you avoid Ex-Domain re-use risks?
According to our cyber-security experts, site owners should implement a minimum-requirement methodology
- Keep the required scripts and minimize the number of remote domains. You can pre-approve any remote domain by using a variety of available tools (also including Reflectiz).
- 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.
- Make sure you use an effective third-party application security monitoring method.
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 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 required, we only need a URL!
* The particular risk is based on real events and relates to a specific site 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.
The post The Risks of Ex-Domain Re-use on Websites and How to Stay Protected Against It appeared first on Reflectiz.
*** This is a Security Bloggers Network syndicated blog from Blog – Reflectiz authored by Reflectiz Team. Read the original post at: https://www.reflectiz.com/the-risks-of-ex-domain-re-use-on-websites-and-how-to-stay-protected-against-it/