Yesterday we looked at what happened when a popular plugin, Display Widgets, was purchased by someone (or someones) with malicious intent and people on the WordPress side of things handle things poorly. In a link included in one of the comments on that post we found another piece of the what happened that makes WordPress’ handling of this seem worse, while also providing yet another reminder of how even basic improvements are not happening to the process of handling vulnerabilities in plugins.

Part of one of the comments reads:

highly recommend scanning the installation for remaining MySQL data : https://core.trac.wordpress.org/ticket/41414 then switch to other plugin alternative.

What is written there is very interesting:

This plusgin
https://wordpress.org/plugins/display-widgets/

creates undetectedable pages with spammy links.
I believe the code can be found in their geolocation.php

https://www.google.com/search?q=geckoandfly.com+payday&ie=utf-8&oe=utf-8&client=firefox-b

I’ve removed the secret page, but after going thru my MySQL, i found a few codes that related back to the said plugin. things like 3371_last_checked_3771 and displaywidgets_ids, all created by the plugin and inserted in wp-options.

the article and pages cannot be search via post/page, only can be found in wp-options.

ever since it was sold to the new owner, it comes with many funny codes.

That lays out not only how the malicious code in the plugin was being used, but also where to look in to the code to find it, as looking through the instances of “displaywidgets_ids” and “3371_last_checked_3771″ in the code would lead to the malicious code we discussed in the previous post.

Reporting Security Issues Needs to Easier

What was problematic was that this information was filed as a bug in WordPress, which it isn’t. The response to it reads in part:

For future reference, it’s best to contact the plugin team for plugin-related issues, at plugins@…. I’ve closed the plugin and contacted the team, for them to review it.

So it would appear that Plugin Directory team was provided the information, which we will get back to in a moment. But first, what is worth mentioning is a problem that we and it turns out others have been raising about the handling of reporting information on security issues in plugins. The follow up to the above response from the original poster was:

Hi, I understand, but I tried searching for a way to contact wordpress but failed to do so, maybe it is a good idea to have a ‘report’ button on every plugin? The new guy behind Display Widget is up to now good.

They certainly are not alone in not being able to find where to report a security issue with a plugin. We have seen this repeatedly, and brought it up a couple of times last year. In one we suggested either adding a link to plugin pages or text to the new thread text for the support forum (the original poster had posted on the Support Forum, so they could have seen the information if it was shown there).

In response it turns out that this on the “todo list”

Adding a direct link to report a plugin is on the todo list, it just hasn’t been tackled, yet. See #meta1598.

Looking at what is linked to, there were questions raised about doing, but there is no indication that any action is being taken. From that we also found that idea was previously brought up four years ago.

Malicious Code Remains in the Plugin

Getting back to the malicious code in this plugin, the reporting of the malicious code occurred on July 23. We don’t know all of what happened after that, but looking at the changes to the plugin and the fact that plugin had returned (it looks to have been recently there, at least from September 5-8, based on Google caching) shows something went very wrong.

There were two subsequent updates to the plugin by the malicious owners. Version 2.6.3 was submitted on September 2 and made a minor change to the plugin. As we discussed yesterday, the vulnerability that version was supposed to have fixed didn’t actually exist. With more than a quick glance at the claimed vulnerability anyone that should be involved in the handling of security issues in plugins on the WordPress side, should have seen that. What we don’t know is if the plugin was restored before that was released. If it was restored before then, what would have been the explanation the developer could have possible given to the Plugin Directory that would have allowed it back? If it was restored due to that, we don’t see how that change should have cleared concern there should have been about the malicious code.

One September 8 the final version they released, 2.6.3.1, makes a more significant change. What seems most relevant is that in this version it no longer uses options named “displaywidgets_ids” and “3371_last_checked_3771″ to store spam posts and if they exist, they are removed. In its place is new code that generates a unique value for each installation used for the name of the option where spam content is stored, using the code shown below:

$unique_id = substr( md5( get_site_url() . 'unique' ), 0, 10 );
$encoded = get_option( $unique_id, 'undefined' );

That would make it harder to spot what is going on, since in each website it would have a different name.

A Full Accounting Needed

There are a lot of things that are handled in less than ideal fashion when it comes to the handling of security issues with WordPress plugins, but the ability for anyone on the outside to make suggestions to improve those is limited due to the opaque nature of just about everything that is done. For example, while there are a number of issue related to the handling of security reviews that are done before plugins are returned to the Plugin Directory after a security issue is identified, we are not even aware of any mention that these reviews take place, much less what they might involve or what type of people are doing them

What this situation really calls for is a full accounting of what happened on the WordPress side, because the bits and pieces we have so far seem to indicate things went very wrong. Without knowing want went wrong it seems unlikely the problems will get fixed, so that when another plugin gets taken over by someone with malicious intent the damage caused does not go on like it did with this for several months.