Flexible Checkout Fields – what we can learn from this plugin vulnerability?

In this article, we will analyse the vulnerability of the Polish plugin Flexible Checkout Fields from WP Desk, which appeared in February 2020.

Let’s check the following vulnerability elements:

Permissions check, sanitation, and validation.

This was the same as in the case of ThemeGrill Demo Importer, and this time the cause of the confusion is mundane – the authors of the plugin forgot about the good practices of creating safe code and error in the same way as the ThemeGrill team.

What was the reason for this vulnerability?

If we look at the classes / settings.php file of the plugin version 2.3.1, near line 269, we will see the following code:

Note that there is no permission checking anywhere in this code. If $_POST is not empty and contains the specified fields, the function will execute and update the plugin settings. Sounds familiar? I want to add that this method is connected to the admin_init hook. So, as we already know from the ThemeGrill error description, an attacker can relatively easily spoof a request and cause this piece of code to be executed.

How hackers used it to attack sites?

From the description provided by WP Desk on their website, we know that this is exactly how the attack proceeded. In the first phase, the attacker, using the above vulnerability, injected malicious JS code onto the website. This is where the second bug comes out of the plugin – it did not provide sufficient sanitation and validation of user data. The plugin should not allow any code to be inserted into the base and displayed on the page.

With the JS code published on the website, the attacker gained virtually unlimited access to the page. Using this code, he could perform any action on behalf of the user who logged in to the website, directly from the user’s browser and with his authorisation credentials. So, for example, after the administrator logged in, it was possible to create new accounts, install additional plugins, etc.

That is why, in the context of website security, it is so important to limit the possibility of placing all kinds of JS scripts on the page, or horrifyingly, PHP code. So if you use plugins such as Code Snippets or Insert Headers and Footers on your website, you have to consider that they can inject malicious code into your website and attack the website with it.

The excellent reaction of the WP Board

While it is difficult to praise the WP Desk team for the very existence of this vulnerability, the reaction is worth praising. Customers reported the first signals about problems on February 26, and the team immediately started tracking them. Version 2.3.2, containing a fix for this vulnerability, was released within hours, followed by another two versions with additional security improvements.

An article was also published on the WP Desk website informing about the vulnerability, explaining the threat it caused and calling for urgent updates.

Delayed reactions from users.

The reaction of users or website owners and people responsible for their maintenance was a little worse. We received reports of “strange website behaviour” or “strange users appearing” all the time, and hardly anyone connected these problems with the vulnerability described here. Unfortunately, these are the cases of this attack.

We often hear that users try not to update plugins too often because “there may be problems” or they don’t have time for it. 

Even if an external team provides website maintenance, the situation may happen when the maintenance agreement has planned plugin updates every two weeks.

The above update approach is extremely insufficient when it comes to critical security patches. That is why it is crucial to keep a website up to date with any updates and react as needed. You can postpone some updates, but some need to run urgently due to security vulnerabilities.

My website has been hacked. What to do next?

Your website is hacked – what does it mean? Third parties may have embedded their PHP code on the website or created users. The entire website should be considered compromised. It is impossible to state what operations the attacker performed and what information about the page they have. It is also not easy to determine when the site was infected, meaning restoring a backup may be troublesome.

If you’re inexperienced and don’t have a dedicated malware-removal specialist, we strongly advise engaging our 360WebRescue services.