What the CleanTalk Vulnerability Revealed About Virtual Patching

Last week, we were helping a new MalCare customer with their site. 

To secure sites and prevent reinfection, you need to plug all the backdoors and resolve vulnerabilities. Otherwise sites often get reinfected as soon as they are cleaned.  

We saw that the site had CleanTalk installed, but it wasn’t up to date. In the light of the recent critical CleanTalk vulnerabilities, it was the most probable culprit. After a thorough sweep, we were reasonably confident it was the entry point for the malware. 

However, the site had Patchstack. There was also a virtual patch for the specific vulnerability. The surprising thing is that it did not work. 

We dug deeper to find out how the malware had gotten past the firewall.

Context part 1: A primer on the vulnerability

To understand what happened and how, we will have to get into the tech just a little. 

CleanTalk was using a reverse DNS lookup to authenticate their access on sites. While this is not good practice, security-wise, it is not an offence. However, the check used to do this was not secure, and left sites open to attacks. This has been well documented by WordFence in their original vulnerability disclosure.

Important: If you haven’t already, please update this plugin on priority. And scan your site immediately. 

Context part 2: How firewalls block attacks

Firewalls block attacks by examining all incoming requests to a site. Each request is put through a set of predefined rules, which identify the request as good or bad. 

Good requests are let through, and bad requests are blocked. 

The predefined rules block many categories of attacks. Special rules are sometimes created for specific vulnerabilities, preventing opportunistic bad actors from exploiting them.

Where the virtual patch fell short

A reverse DNS lookup involves sending out an IP address, and getting a  domain in return. For example, 192.159.1.32 in exchange for thisisyoursite.com. 

The virtual patch looked for “cleantalk.org” in certain headers and variables. The problem is that the domain will never be found in these fields. Therefore, it would be bypassed.  

In the customer site we were fixing, the rule had not prevented exploits of the vulnerability. 

As soon as we discovered the flawed rule, we disclosed it to them privately. Patchstack were very responsive, and fixed it immediately.

Virtual patching has limits

As a security mechanism, virtual patching has limitations. By its nature, it focuses on fixing the symptoms, not fortifying the foundation. There are many reasons why it should be only a part of a larger defence strategy.

1. Vulnerabilities exist for years before discovery

This vulnerability in Cleantalk is a textbook case. 

Hackers and researchers are both actively looking for vulnerabilities. It is anyone’s guess who finds them first. Hence, virtual patches are important, but have limitations. 

A robust security strategy is a blend of prevention (firewall), detection (scanner), and resolution (cleaner). Leaving even one out is a problem. You need the best malware scanner and remediation solution possible.

2. Reactive security protects against known vulnerabilities only

Since the vulnerabilities exist for such a long time, we need a proactive approach to security.

This is why we developed Atomic Security. It protects against many critical vulnerabilities even before they happen.

3. Even with the best intentions, some patches will fail

Certain vulnerabilities are really difficult to patch through a firewall, like in this case. 

There is no way to check the reverse DNS lookup results for CleanTalk requests. 

Therefore, the firewall rules of WordFence, Patchstack and MalCare, will not only block malicious requests but also valid requests being made by CleanTalk. We have seen this happen multiple times, where virtual patches tend to be a lot broader because of limitations.

4. Human error

Just like with vulnerabilities, virtual patches are prone to human error. 

Virtual patches can be ineffective, like we saw in this case. We do not see these happen often, but equally we do not (cannot) spend the energy validating them thoroughly. 

Note to self: Maybe this becomes an impetus to put in more energy into our WP-Radar open source tool.

Stronger together

Vulnerability discoveries rely heavily on security researchers. They randomly try to discern holes in code. While researchers fulfil an important need, the system isn’t perfect. 

Rather, we should be looking at making defences stronger, more tightly coupled with WordPress itself. Like we have done with Atomic Security.