When it comes to false reports of vulnerabilities in WordPress plugins one popular source of them that is claimed vulnerabilities that can only be exploited by an Administrator level users, which is the highest level user (unless you are using WordPress Multisite). Apparently it isn’t common sense to a lot of people that someone that is Administrator would have wide ranging access, so for them to take almost activity is not a vulnerability. Their access would normally allow them the ability to install other plugins, which in some cases explicitly allows doing what is being claimed to be a vulnerability, and allow them to edit existing plugins, so even if you place security restrictions in the plugin an Administrator would normally be able to remove them. There is an exception to actions taken by an Administrator not being vulnerabilities when it is possible to cause a logged in Administrator to take an action they didn’t intend to, which we will get to a bit later.
This source of false reports came up with a report of an authenticated denial of service (DoS) vulnerability and an authenticated remote code execution (RCE) vulnerability in XCloner released earlier this week. With both claimed the first step in exploiting them was “Authenticate to wordpress with an administrator”, so there isn’t really a vulnerability as claimed, but they could possibly be a bug.
For the first claimed vulnerability described as an authenticated DoS, which was really a file deletion vulnerability (the claim that it DoS was that you could delete the WordPress configuration file taking the website offline), the report actually identified a less serious vulnerability in the plugin. The second step for was this:
Access to XCloner to the following URL:
That URL requests that that the WordPress configuration be deleted, but it you need to be logged in as Administrator to do it. But what if could trick a logged in Administrator to visit that URL, say by placing a link to it in a comment, then an action that they didn’t intend to make would occur. This is referred to as a cross-site request forgery (CSRF) vulnerability. The way you protect against is by including a nonce with any request like this and then checking to make sure it is valid. If done properly no one else would know what a valid nonce for a particular Administrator would be and the file deletion could not happen if the Administrator doesn’t intend it.
After we notified the developer of the issue they changed the deletion code so that only files in the directory /wp-content/plugins/xcloner-backup-and-restore/configs/ can deleted, by running the user input, “fconfig”, that specifies the file to be deleted through the basename() function:
$fconfig = basename($_REQUEST['fconfig']);
That function stop path traversal (the “../” portion in the example above) from being included. That version number was not changed, so if you are already using version 3.1.5, you will need to replace the files with the current version available for download.
Proof of Concept
The following proof of concept will delete the file test.txt in the root directory, when logged in as an Administrator.
Make sure to replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]/wp-admin/plugins.php?page=xcloner_show&option=xcloner&task=cron_delete&fconfig=../../../../test.txt
- November 9, 2016 – Developer notified.
- November 9, 2016 – New version of 3.1.5, which fixes the vulnerability, is released.