Last week in discussing a couple of examples of things that are not actually ways you can determine if you should use WordPress plugin from a security perspective, we mentioned that the only good way to determine if a plugin is secure is to have a security review done. While that isn’t something that seems like it could really be automated at this time (or does it seem that it would be any time soon), based on some of the work we do as part of our service we know it is possible to identify the possibility of some security issues in plugins in an automated fashion, which can help to identify if a plugins is in greater need of a proper security review.

Recently we have been working on a tool that provides the public with the results of checks for some possible issues and that can now be found here.

The tool currently contains two parts. The first just checks if the current version of the plugin is listed as containing a vulnerability in our data set. The details of the vulnerability are not provided, since that is major piece of what is provided through our service.

Possible Security Issues

The second part involves doing a number of checks for possible security issues. What is very important to note is that the tool only checks if there is the possibility of the issue and some of the things it will detect in plugins are not always security issues. That is a concern in providing a tool like this because while we see value in it, we also often see people making inaccurate claims about the security of plugins based on misreading information being provided, including instances where we have clearly written a post about a vulnerability having been fixed in a plugin and then someone immediately contacts the developer to find out if they are aware of a claim that the plugin is currently vulnerable.

Correctly used, this tool indicates if there should be further checking to see if there is a vulnerability and only after that should the developer be contacted.

To better explain both the limits of the checks, but also why is makes sense to check for things that are not always an indication of a security issue, let’s take a look at a couple of plugins we recently were checking over.

Unused File

Two weeks ago code in the plugin WCP OpenWeather was flagged during our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. The line of code that caused that was the following:

$cookie = unserialize(stripslashes($_COOKIE[$this->name]));

In that line you have user input, in the form of a cookie, that is passed through the unserialize() function, which could allow PHP object injection to occur.

That occurs in the function _getCookie(), which is a part of the class Agp_CookieAbstract and is in the file /agp-core/classes/persistence/session/Agp_CookieAbstract.class.php:

23
24
25

private function _getCookie ($key = NULL) {
	if (!empty($_COOKIE[$this->name])) {
		$cookie = unserialize(stripslashes($_COOKIE[$this->name]));

When we went to look to see how that function could be accessed we found that it was utilized in a number of the other functions in that class, but the class appears to not be used in the most recent version of the plugin or older versions, going back to the original version. Since the only thing in the file is that class, it doesn’t appear the file has ever been used in the plugin. We also found that the same file is included in the developer’s two other plugins and also not used. It looks like the developer includes a number of files even if they are not being used in particular plugin, which seems like it isn’t the best idea.  We contacted the developer about this more than a week ago, but we haven’t heard back.

So in this case there isn’t a vulnerability, but at the same time you don’t want vulnerable code in a plugin even it isn’t normally accessible. One of the reason for that is if there was a local file inclusion (LFI) vulnerability somewhere on a website that could be used to load files that are otherwise not used, though in this case that wouldn’t allow exploitation.

Unintended Access

Last week we looked into the details of a recent security fix made to the plugin PluginOps Page Builder. We will be releasing those once the developer of the plugin has a chance to fix a connected vulnerability we noticed still existed in the plugin. Without getting in to all the details of the security fix, part of the change involved adding a check to some functions to check make sure that only users with the Editor and Administrator roles have access to the functions.

One of those is the function ulpb_admin_ajax(), which you can see that in version 1.4.2 the first thing done in the function is that check:

304
305
306
307

function ulpb_admin_ajax(){
 
 
	if( current_user_can('editor') || current_user_can('administrator') ) {

Above that in file /admin/admin.php are the following two lines:

26
27

add_action( 'wp_ajax_nopriv_ulpb_admin_data', array( $this,'ulpb_admin_ajax')  );
add_action( 'wp_ajax_ulpb_admin_data', array( $this,'ulpb_admin_ajax') );

The first line there makes the function available through WordPress’ AJAX functionally to those not logged in to WordPress. The second one makes the function available through WordPress’ AJAX functionally to those that are logged in to WordPress. Seeing as the function is actually only intended to be accessed to subset of logged in users, that first line shouldn’t be there and before that role check was added those not logged in had access to the function. That allowed them to access a fairly serious vulnerability, though not one that is likely to be exploited on the average website.

That brings us to one of the checks we do, which is to check if there are AJAX registrations like the one above, that allows access for both those logged in as well as those not logged in. That will identify instance where that is intended and is perfectly safe, but it will also identify situation like this where it isn’t intended and expands the scope of a security vulnerability that would have otherwise only been accessible by to those logged in. Based on how often we see the incorrect usage like has been in this plugin and how easy it is for someone that knows what they are doing to check on this type of situation we feel that it makes sense to be raising this as part of the checking.

Currently we don’t provide the details of what code is the cause of a possible issue being identified as the tool as we see this as a public friendly tool and those that should be doing the further checking shouldn’t have a problem finding the relevant code.

Feedback

The tool is very much a work in progress at this time and may change significantly as we continue to work on it.

We are continuing to look at more things we can add checks for. One area where we likely to expand it is by adding more the checks that are utilized with our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities.

One of the things we are considering adding is providing the customer of our service the ability to see the details of the underlying code causing us to identify a possible issue. We also are considering the possibility of adding the capability to get results on plugins in WordPress’ admin area through our service’s companion plugin.

If you have suggestions, say any additional check that we should include (you can see what we currently includes checks on the tool’s page), or other feedback please leave a comment below or contact us.