Recently it was claimed that the WordPress plugin RD Station had led to a website’s database being replaced:

when are you going to fix the problem, a couple of weeks ago a site was attacked by this vulnerability, the entire database was replaced, we contacted you and this was the response

What was claimed to be the vulnerability referenced in that seemed unlikely to explain that, but it turns out the source of the vulnerability, Patchstack, had provided inaccurate information. The real vulnerabilities are more serious than they made them out to be. The developer also made them out to be less serious as well.

Pathstack’s self-described “details” of the vulnerabilities lack any details:

Multiple Cross-Site Request Forgery (CSRF) vulnerabilities were discovered by Rasi Afeef (Patchstack Alliance) in the WordPress RD Station plugin (versions <= 5.2.0).

Not only is that not enough information to confirm if there really were vulnerabilities, they don’t seem to have a great grasp of security, as the issue is more serious.

Cross-site request forgery (CSRF) involves causing someone to take an action they are allowed to do, but they didn’t intend to do. They do not appear to be much of a concern with WordPress plugins at this time, as hackers are not trying to exploit these at any scale as far as we are aware.

While Patchstack didn’t fill in details there, according to comments apparently from the developer, those CSRF vulnerabilities involved a log file and didn’t involve customer data.

Looking at the changes made in the latest version of the plugin, 5.2.1, tell a different story.

CSRF Protection Added

One of the files with a change made is /includes/events/rdsm_settings_page_loaded.php. In the previous version, the function check_authorization() is registered to be accessible by anyone who is logged in WordPress, through its AJAX functionality:

7

add_action('wp_ajax_rdsm-authorization-check',  array($this, 'check_authorization'));

That function would display an access token stored in WordPress’ database without doing any security checks first:

10
11
12
13

  public function check_authorization() {
    $response = array('token' => get_option('rdsm_access_token'));
    wp_send_json($response);
  }

In the new version, a nonce check, which protects against CSRF, has been added:

10
11
12
13
14
15
16

  public function check_authorization() {
    if (!isset($_POST['rd_form_nonce']) || !wp_verify_nonce($_POST['rd_form_nonce'],'rd-form-nonce')) {
      wp_die( '0', 400 );
    }
    $response = array('token' => get_option('rdsm_access_token'));
    wp_send_json($response);
  }

The same change was made to other AJAX accessible functionality, including functionality that allowed changing user credentials to connect to Red Station.

Patchstack Misses Missing Capabilities Check

What is still missing in the function shown above and the others is a capabilities check to limit what users have access to those things. The nonce check would, in normal circumstances, do the equivalent of that, but it isn’t intended to do that.

So previously the issue wasn’t limited to CSRF, but also allowed low-level WordPress users access to various functionality. That is much more likely to be exploited than the CSRF issues. Patchstack appears to have missed this and likely didn’t even look too closely as to what was going on. That is more of an issue when they don’t provide basic details for others to check on their claims.

Could This Have Led to Replaced Database?

Coming back to where we started this post, the claim that a vulnerability in the plugin led to a database being replaced. Is that true?

Looking at the functionality that has had security added, we didn’t find anything that could directly cause that to have happened. It doesn’t look like the plugin has code that allows direct changes to the database, only indirect changes through WordPress functionality.

It might be possible that through the vulnerabilities that existed, a hacker might have been able to get part way to doing what was mentioned. At the same time, it seems more likely that it is hack was unrelated to the plugin at all. People often conflate a claim that a plugin has a vulnerability with that being the cause of a hack. No evidence was presented that the plugin was the source, the person didn’t seem to be aware the vulnerability was more serious (which it seems like they would be aware if there was evidence that the plugin was the cause of the attack), and there are not others complaining about being hacked despite 20,000+ installs.

Better Information Needed

What this situation highlights is the need for better information on plugin vulnerabilities and the source of hacks.

Patchstack isn’t a reliable source for information, as this again shows. There is at least one source that verifies the information in their data set, while others don’t. Some of them even copy data from Patchstack and then say they don’t review the data, as Patchstack or others have, which this again shows isn’t the case.

Many people dealing with hacked websites don’t do a basic part of the cleanup, which is trying to determine how the website was hacked. That can lead to plugins being blamed for hacks they had nothing to do with. If the real source isn’t found and addressed, then the hacker possibly still has access and could do more damage.

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade