When it comes to improving the security of WordPress plugins the two things that stand out that are of most need and have been for years, are warning people when they are using vulnerable plugins and for serious vulnerabilities, which are likely to be exploited, putting out fixes if the developer doesn’t. The reason that hasn’t happened isn’t because of say a lack of resources, before we suspended doing it last year due to continued bad behavior by people on the WordPress side of things, we were to a large degree single handedly making sure that plugins in the Plugin Directory with public disclosed unfixed vulnerabilities didn’t remain in it (when we stopped they started piling up in it). We easily could provide fixes for the vulnerabilities that are likely to be exploited as well. Instead, the reason for the lack of doing those things is that the people on the WordPress side, for reasons that don’t make sense, are blocking those things from happening.

When we say they don’t make sense take the head of team running the Plugin Directory Mika Epstein claimed that you shouldn’t even warn about unfixed vulnerabilities even if they are being exploited:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

If an exploit exists, hackers will be targeting the vulnerability en-mass.

That’s exactly the issue. If we make it known there is an exploit, the hackers attack everyone :/

If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.

So their solution to people being hacked is to allow it to continue. They could release a patch in those instances as well but they usually don’t do that and don’t even want to have a discussion about the lack of doing that. Like we already said, we could provide those for them, so it would require very little work on their end, but it would have a big impact.

Just a week ago Mika Epstein made another claim that seems equally odd or, well, to be blunt, stupid:

In general we don’t comment on why plugins are closed to prevent disclosure (and in turn to prevent stupid hackers from targeting you). The version on .org is waiting on some final security and guideline fixes, and will be opened as soon as they submit a final fixed version.

There are quite a few issues with that, which are probably worth discussing in more detail separately, but let’s focus on the claim about hackers. The reality here is that by closing the plugin they are actually paint a target on the plugin that would interest hackers.

More advanced hackers are not likely going to have much problem quickly checking over the plugins to see if they have an exploitable plugin even if it is not identified that there is a security issue in the plugin. What seems the best approach would to either not paint a target on the plugin by closing it or move to quickly get a fixed version out (which is not what is going on now). When we notified the Plugin Directory about unfixed vulnerabilities we always tried to work with the developer first to get it fixed, in part because of how things were handled if the Plugin Directory team got involved were problematic.

What about “stupid” hackers? Well the lowest rung ones seem to be unaware that you can, for example, see how many websites are using plugins, so warning about insecure plugins seems to not be something that would directly impact them. With slightly higher ones though, something we just saw yesterday afternoon indicates that closing plugins without any information also isn’t stopping them from trying to exploit security issues, even if there doesn’t seem to be much that can be done with them.

Yesterday we had a couple of failed requests on this website for a file that would be located at /wp-content/plugins/wp-yet-another-related-posts-plugin/includes/yarpp_pro_set_display_types.php. There isn’t a plugin with that slug (directory) on the WordPress Plugin Directory, but there is a popular plugin that we had been actively using on our website until a few days ago with the slug yet-another-related-posts-plugin. That plugin Yet Another Related Posts Plugin (YARPP) has 200,000+ active installations according to wordpress.org and it was removed from the Plugin Directory just over a week ago:

There is a copy of the plugin on GitHub that uses the wp-yet-another-related-posts-plugins slug, which might explain the alternate directory being used.

That plugin has a file at that location that looks like this in the most recent version:

2
3
4
5
6
7
8
9
10
11

if (!isset($_GET['ypsdt']) || $_GET['ypsdt'] === true) die();
$types  = (isset($_GET['types']) && is_array($_GET['types'])) ? $_GET['types'] : array();
 
include_once(realpath('../../../../').'/wp-config.php');
$yarppPro = get_option('yarpp_pro');
$yarppPro['auto_display_post_types'] = $types;
update_option('yarpp_pro',$yarppPro);
 
header('Content-Type: text/plain');
die('ok');

That code will take user input sent with a request to the file and change a WordPress option (setting) “yarpp_pro”. That is certainly a security issue since people not even logged in to WordPress should be able to change a plugin’s settings.

In our looking at this though we couldn’t figure out something really malicious that you could do with this. It looks like that setting is accessed in two files, /includes/phtmls/yarpp_pro_options.phtml:

63

$post_types = $yarpp->yarppPro['auto_display_post_types'];

and /classes/YARPP_Core.php:

1009

if (!in_array(get_post_type(), $this->yarppPro['auto_display_post_types'])) return null;

In both cases it looks like the value is only used to compare to another and isn’t used in a way that could cause something malicious to happen, but we certainly could have missed something.

Since no reason was given as to why the plugin was closed we have no idea if there was a non-security related issue for that and it might make sense then to release a fixed version of the plugin, even if it isn’t going to be available for new installs anymore. We have added monitoring to see what anyone might try to do with requests to that file on our websites.

There doesn’t seem to be any disclosure of this issue, so it would seem that “stupid” hackers are not being deterred by handling things in way that isn’t helpful to people using plugins. That would be something a smart person running the Plugin Directory would take in to account  and likely change how things are handled, but based on past behavior Mika Epstein is likely to keep acting stupidly instead, to detriment to the WordPress community that relies on them and the rest of the Plugin Directory team to not do stupid stuff.

Making the behavior on the WordPress side of things worse here, since they removed the companion plugin for our service from the Plugin Directory we can’t warn people not using our service, but using the companion plugin, if they are using a vulnerable version of this plugin. (The people behind WordPress really seem to have a focus on making people using it less secure, which shouldn’t be something that should be happening at all.)

In the meantime we found another more serious security issue that could be exploitable in the future, which we will discuss in a follow up post.

Proof of Concept

The following proof of concept will set the value of the “auto_display_post_types” setting in the “yarpp_pro” option (which can been seen in the wp_options table) to PluginVulnerabilities.

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

http://[path to WordPress]/wp-content/plugins/yet-another-related-posts-plugin/includes/yarpp_pro_set_display_types.php?ypsdt=true&types[]=PluginVulnerabilities

Concerned About The Security of the Plugins You Use?