09 May

WPScan Vulnerability Database Includes Fake Vulnerability, Claims It Was Fixed

Last month there was report of a remote code execution vulnerability in the plugin Robo Gallery, as we discussed at the time the vulnerability didn’t actual exist (though another vulnerability did exist in the relevant code). Despite the fact that it didn’t exist and couldn’t possibly have been exploited as shown in the included proof of concept, that hasn’t stopped people from trying to exploit. We had one attempt on our website the week after the report and a recent thread on wordpress.org indicates that attempts are continuing to happen. Based on what request were sent in those two situations, those were done by different people, with the second one being from someone who was less aware of the problems with the advisory, considering they sent a GET request when that couldn’t possibly work.

While doing some more looking around on this we found it is not only hackers that didn’t bother to actually look at the vulnerability report. The fake vulnerability is also listed in the WPScan Vulnerability Database, which is a database of vulnerabilities related to WordPress. That database is used in a number of plugins for alerting to vulnerable plugins.

What is rather strange about the listing it states that “This is potentially a False Positive. Needs further investigation.”, while at the same time claiming that it has been fixed:


How they know it has been fixed, but not being sure if it actually exists in the first place, is curious at best.

What makes this more problematic is that it looks like many of the tools that use their data just display the title of the vulnerability, so the disclaimer in the description would not be shown.

This is great reminder of the importance of testing out vulnerabilities before including them in data sets of vulnerabilities, which we do, but others, including the WPScan Vulnerability Database don’t do. That lack of testing leads to other problems like the WPScan Vulnerability Database claiming that vulnerabilities that haven’t been fixed were in fact fixed, which leaves users of their data falsely believing they are secure against publicly disclosed vulnerabilities.

20 Apr

A Vulnerability Being Fake Doesn’t Stop Hackers From Trying To Exploit It

When it comes to threat of websites being hacked, it is a real threat, but is also worth noting that it easy to overstate the threat. The reality is that vast majority of hacking attempts on websites have zero chance of being of successful. For less scrupulous security companies that fact can be used to do things like making it seem like their product is protecting a website from many threats that were in fact not actually any threat to the website.

One reason this is the case is that many hackers don’t have much clue what they are doing, as an example when just ran across shows.

One of the ways we keep on top of vulnerabilities in plugins, so that we can make sure your website remains protected against them, is to monitor attempts to hack our websites. Yesterday one of the attempts on this website involved sending a POST request to the file /wp-content/plugins/robo-gallery/includes/rbs_gallery_ajax.php. This was attempt to exploit a claimed vulnerability in the plugin Robo Gallery. We don’t have that plugin installed so there is no chance it could have been exploited.

But even if we did have the plugin installed, it would not have had any chance of being successful since, as we discussed last week, the claimed vulnerability doesn’t actually exist. As we noted then one of the problems with this being a real vulnerability is that you can’t access the supposedly vulnerable file, /includes/rbs_gallery_ajax.php, directly due to the second line of code in the file:

if ( ! defined( 'WPINC' ) )  die;

That code checks WPINC is defined, which it won’t be if you access the file directly, and if isn’t the rest of the file doesn’t get executed. If the file is loaded by WordPress, WPINC will be defined, since it gets defined in the /wp-settings.php, which is loaded at the end of the file /wp-config.php.

What is somewhat interesting about this is the hacker didn’t just follow the proof of concept provided with the advisory, since they would have done a GET request instead of a POST request if that were the case. The correct request type would be a POST, so clearly the understood part of the advisory was wrong, but they missed the larger problem with it, that you can’t get to the part of the file where that matters due to the previous issue.

12 Apr

Privilege Escalation Vulnerability in Robo Gallery

While reviewing a false report of a vulnerability in the Robo Gallery plugin today we noticed the plugin actually had a privilege escalation vulnerability in the code mentioned in that other report. In version 2.0.15, and some prior versions, the function rbs_gallery_ajax_callback in the file /includes/rbs_gallery_ajax.php allows anyone logged in to WordPress to access the functions in the file /includes/extensions/rbs_create_post_ajax.php, which not all levels of users should have access to.

In version 2.0.15 an attempt was made to stop this by restricting access to the function rbs_gallery_ajax_callback to administrators using the the function is_admin(). The problem with that is that the function doesn’t actually doesn’t check if a user is an administrator. Instead it checks if “if the Dashboard or the administration panel is attempting to be displayed”. Since it “will return true when trying to make an ajax request (both front-end and back-end requests)”, this had no impact in this situation since it involves an ajax request.

Proof of Concept

The following proof of concept will reset a gallery’s view count to 0.

Make sure you are logged in to WordPress, ideally as a subscriber since they have the least capabilities. Also, make sure to replace “[path to WordPress]” with the location of WordPress and “[id of gallery]” with the ID of the gallery you are resetting the view count of.

<form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=rbs_gallery" method="post">
<input type="hidden" name="function" value="reset_views" />
<input type="hidden" name="galleryid" value="[id of gallery]" />
<input type="submit" value="Submit" />


  • 4/12/2016 – Developer notified the issue has not been resolved.
  • 4/12/2016 – Developer responds that fix forthcoming.
  • 4/16/2016 – Version 2.0.17 released, which fixes vulnerability.
12 Apr

When A False Vulnerability Report Leads To a Real Security Vulnerability

Today a report claiming that there was remote code execution vulnerability in version 2.0.14 of the Robo Gallery plugin was released. With such a serious vulnerability and one that was claimed to be in the most recent version of the plugin, we quickly started checking on the report to include the vulnerability in our service’s data. What we quickly noticed was the claimed vulnerability didn’t actually exist, but that that a less serious vulnerability in code mentioned in the false report does exist in the plugin. We have notified the developer that there apparent attempt to fix that vulnerability in the subsequently released version 2.0.15 was not successful. All of this highlights the importance the kind of the testing we do before adding vulnerabilities to our service’s data (and highlights the limited value of other services that don’t do that testing).

The threat of the claimed vulnerability is describe as

A remote php code execution vulnerability has been discovered in the official Robo Gallery v2.0.14 WordPress Plugin web-application. The vulnerability allows remote attackers to execute own malicious php commands to compromise the web-application or connected dbms.


The security risk of the code execution vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 8.9. Exploitation of the php code execution vulnerability requires no privileged web-application user account and low or medium user interaction. Successful exploitation of the vulnerability results in computer system, web-server or database management system -compromise.

The report looks rather professional, but once you look at the details of the claimed vulnerability in becomes clear that that the person that put it together didn’t understand what they were talking about at all.

The proof of concept provided for exploiting the vulnerability is:

http://localhost:8080/wp-content/plugins/robo-gallery/includes/rbs_gallery_ajax.php?function=phpinfo();[CODE EXECUTION VULNERABILITY!]

Right after the code for the file the request is supposed to be sent to, /includes/rbs_gallery_ajax.php, is included:

if ( ! defined( 'WPINC' ) )  die;

    add_action( 'wp_ajax_rbs_gallery', 'rbs_gallery_ajax_callback' );
    function rbs_gallery_ajax_callback(){
        if(isset($_POST['function']) && $_POST['function']){
            $functionName = 'rbs_ajax_'.$_POST['function'];
            if( function_exists( $functionName ) ) $functionName();

The first obvious problem is that the code in the file will not run directly, as the proof of concept requires. The second line of the file, “if ( ! defined( ‘WPINC’ ) ) die;”, checks if the file is being loaded directly and then stops it from running if it has. The rest of the code only runs if the file is loaded through WordPress.

The next problem is that the proof of concept shows passing the value of input named “function” via a URL parameter. That would be accessible via PHP using $_GET[‘function’], but the code only access the “function” input through a POST, $_POST[‘function’].

So based on that clearly the proof of concept is wrong, but that doesn’t necessarily mean that there isn’t an issue, which meant we still had to dig deeper to fully check this out.

Next we saw that only some one logged into to WordPress is allowed to access the function included in the file due to this line:

add_action( 'wp_ajax_rbs_gallery', 'rbs_gallery_ajax_callback' );

So the claim that this “requires no privileged web-application user account” is also false.

The portion of the code where the code execution is supposed to happen is here:

$functionName = 'rbs_ajax_'.$_POST['function'];
if( function_exists( $functionName ) ) $functionName();

The code first takes the  value of “function” input and appends it to the string “rbs_ajax”. That means that only a function that starts “rbs_ajax” can possibly run.

Unless another plugin was installed that had functions that started”rbs_ajax”, then all of the functions that would meet that requirement are stored in the file /includes/extensions/rbs_create_post_ajax.php. Based on what the functions do it didn’t look like these were meant to be accessible to all levels of users, which would indicate that there is actually a privilege escalation vulnerability in the plugin.

While we were looking into this, version 2.0.15 of the plugin was released, in which the developer tried to restrict access to the function rbs_gallery_ajax_callback in the file /includes/rbs_gallery_ajax.php to admins. We say tried, because they used the function is_admin(), which doesn’t actually doesn’t check if a user is an administrator. Instead it checks if “if the Dashboard or the administration panel is attempting to be displayed”. Since it “will return true when trying to make an ajax request (both front-end and back-end requests)”, this had no impact in this situation since it involves an ajax request. The attempt to restrict access to the functions seems to confirm that a privilege escalation vulnerability exists in the plugin.

We have informed the developer of the problem with using is_admin() and hopefully a fix will be released soon.