Last week we had requests from the IP address 185.100.222.127 to our website that looked like they might be a hacker probing for usage of the plugins SendinBlue Subscribe Form And WP SMTP and Table Maker. After seeing that, we checked over the plugins to try find if there was a vulnerability in them that a hacker would be interested in.

With SendinBlue we found a SQL injection vulnerability that might be able to be used to cause PHP object injection to occur. PHP object injection is a type of issue that is highly likely to be exploited if it exists. That vulnerability has yet to be fixed.

With Table Maker we found multiple vulnerabilities, including a SQL injection vulnerability that we confirmed could lead to PHP object injection. Those have now been fixed.

The other day we had a couple of requests from the same IP address for the file /wp-content/plugins/pretty-link/readme.txt, which is a file from the plugin Pretty Links.

In looking into that IP address we found that we are not the only ones receiving the requests for a file in those three plugins, as someone reported to abuseipdb.com that they had received the same requests.

When it comes to Pretty Links, we were already aware of two publicly disclosed reflected cross-site scripting (XSS) vulnerabilities that exist in the most recent version of the plugin. For one of those we notified the developer of the plugin about the disclosure at the beginning of October. They responded shortly after that “This will be fixed very soon.”, but it hasn’t so far. (For the other vulnerability we don’t know if the discloser notified the developer and we were planning to notify the developer about it if when they put out version that fixed the vulnerability we had notified them, the other had not been fixed as well.) That the vulnerability still hasn’t been fixed raises the possibility that there may be other vulnerabilities that the developer has been informed about, but they have yet to fix. That type of vulnerability is not likely to be exploited on the average website, so it seems unlikely one of those vulnerabilities would be what a hacker might be interested in the plugin for.

After noticing the probing for the plugin we started looking over the plugin to see if we could find some security issue that a hacker might be interested in exploiting. Seeing as the other two plugins had security issues connected to PHP object injection that was obviously an issue to check for, but it would be anyway due to how often type of vulnerability is being exploited in plugins these days.

We found one instance of the unserialize() function, which is a critical piece of PHP object injection, in the plugin. In the file /app/models/PrliOptions.ph the function get_options() will pass the value of the WordPress option “prli_options” through that function:

300
301
302
303
304
305

public static function get_options() {
  $prli_options = get_option('prli_options');
 
  if($prli_options) {
    if(is_string($prli_options))
      $prli_options = unserialize($prli_options);

In looking over the plugin we couldn’t find any way for an attacker to get a value need to cause PHP object injection in to that option. Maybe someone else will see something we missed, though.

As we were looking into how saving of the plugin’s options was handled, as that is what is stored in the WordPress option “prli_options”, we found that plugin had multiple security issues. The protection against cross-site request forgery (CSRF), which allows an attacker from causing someone to take an action they didn’t intend, is only partially implemented in some locations. On at least the Options page and Add Pretty Link pages in the admin area of the plugin there is nonce included with requests to make changes, but the code that makes the changes doesn’t check if it is included or that it is valid. That makes it appear the protection is in place without actually doing anything. We also found that the Options page has a reflected cross-site scripting (XSS) vulnerability that is separate from the two previously disclosed ones.

While those things sound concerning, the threat from them on the average website is likely very small to non-existent, so they would be highly unlikely to be what a hacker might be interested in exploiting.

A problem caused by a plugin being so inseucres is that it makes it harder to zero in what a hacker might be interested in, since there so many paths you could follow looking for that.

One of the other areas we took a look at, since it frequently a source of security issues, is handling of plugin functions accessible through WordPress’ AJAX functionality. Not surprisingly there are security issues with those as well, starting with the fact that a number of them don’t included restriction on who can access them beyond limiting access to them to those logged in WordPress.

Normally the popularity of a plugin makes little difference in whether a hacker will target a vulnerability in it, instead what seems to be the main determination is the type of vulnerability. We suspect that some of that might be due to not all hackers being aware that you can see how popular plugins that are in the Plugin Directory are. An exception to lack of importance of the popularity of plugins is for vulnerabilities that require the attacker to be logged in to WordPress to exploit, often referred to as authenticated vulnerabilities. It isn’t clear what level of usage would be enough for hackers to try to exploit that type of issue, but last year that occurred with a plugin with 100,000+ active installations at the time. This plugin has 200,000+ active installations, so it would seem to be reasonable to believe that a hacker might target a vulnerability that is only accessible to those logged in.

Popularity Doesn’t Equal Security

Before we get to into AJAX accessible functionality that hackers might be interested in targeting, it’s worth taking a moment to take in the fact that a plugin with 200,000+ active installations contain numerous security vulnerabilities. That is out of line what you likely would believe if you were to listen to security advice on WordPress plugins, even from security companies. For example, just last month Wordfence wrote a post titled “Ask Wordfence: How to Limit Security Risks From Plugins” with this information on choosing “reputable plugins”:

Choose Reputable Plugins

The WordPress.org plugin directory makes it really easy to evaluate plugins by providing a nice summary that gives you almost everything you need. Here’s what we suggest you pay attention to:

• The more recent the last update, the better.
• Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers, but you should still examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.
• It should be compatible with the current version of WordPress, though please note that immediately after a WordPress core release, a lot of reputable plugins will show a “Test up to:” value that is behind, as authors finish testing their plugin with the latest WordPress version.
• The average plugin rating should be high enough to instill confidence. The higher the rating, the better, obviously.

You should also periodically review your installed plugins to make sure they have maintained their good standing.

The number of active installs just indicates that something is popular, not that is reputable or otherwise secure (considering that Wordfence Security is the most popular WordPress security plugin, the company behind may have a vested interested in believing that popularity is an indication of things it isn’t). In the case of Pretty Links, it would seem to fit all of Wordfence’s criteria:

Those criteria are just not all that meaningful from a security perspective, something you would hope the maker the maker of the most popular WordPress plugin to know. That they are handing out advice on something that they don’t understand speaks the really poor state of security surrounding WordPress, especially the poor state of security companies.

Authenticated Short Link Creation

In looking over the functions available through AJAX, one immediately stood out to us a something that a hacker might be interested in. That being the function to create a pretty link, which is the plugin’s name for a short link:

11

add_action('wp_ajax_prli_create_pretty_link', array($this, 'create_pretty_link'));

That function, located in the file /app/controllers/PrliPostsController.php, doesn’t contain any restrictions on who can create those new short links:

85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

public function create_pretty_link() {
  $valid_vars = array('target', 'slug', 'redirect', 'nofollow', 'tracking');
 
  if(!isset($_POST) || !($valid_vars == array_intersect($valid_vars, array_keys($_POST)))) {
    echo "invalid_inputs";
    die();
  }
 
  //Using the local API Yo
  $id = prli_create_pretty_link(
          stripslashes($_POST['target']),
          stripslashes($_POST['slug']),
          '', //Name
          '', //Desc
          0, //Group ID
          (int)($_POST['tracking'] == 'enabled'),
          (int)($_POST['nofollow'] == 'enabled'),
          $_POST['redirect']
        );
 
  if((int)$id > 0) {
    echo "true";
    die();
  }
 
  echo "link_failed_to_create";
  die();
}

By comparison, the admin page for creating a new one is restricted to Administrator users (in the file /app/controllers/PrliAppController.php):

31

$role = 'administrator';

51
52
53
54
55
56
57

$prli_add_links_menu_hook = add_submenu_page(
  'pretty-link',
  __('Pretty Links | Add New Link', 'pretty-link'),
  __('Add New Link', 'pretty-link'),
  $role, 'add-new-pretty-link',
  'PrliLinksController::new_link'
);

What access to that function means in simpler terms is that if a website allows public to create WordPress accounts, whether directly through WordPress or through a plugin, they can then create new short links. As an example of that, if your website was example.com and someone used the proof of concept at the end of the post, visiting http://example.com/pluginvulns would redirect to our website’s homepage.

So what would a hacker be interested in that for? A quick perusal of the Google search results for “spammers abuse URL shorteners” shows that they use those with spam since the website being linked to disguises the final destination.

Due to the fact that the developer still hasn’t fixed the previous issue we notified of them in the plugin we are not notifying them of this issue or the other issues we ran across at this time. Someone else is welcome to do that, though.

We would say that this plugin is really in need of a security review, but considering the developer isn’t addressing in a timely manner previously disclosed security issues, it seems like the time, effort, and or cost of doing that might be wasted.

If you see some other issue that hacker would target in this plugin, we would love to hear about it.

Wider Warning

Due to the fact that this issue or something else might be being targeted by hackers we are adding the vulnerability to the free data that comes with our service’s companion plugin, so that even those not using our service yet can be warned if they are using the plugin.

Proof of Concept

The following proof of concept will create a short link that redirects from /pluginvulns to our website’s homepage, when logged in to WordPress.

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

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="prli_create_pretty_link" />
<input type="hidden" name="target" value="https://www.pluginvulnerabilities.com" />
<input type="hidden" name="slug" value="pluginvulns" />
<input type="hidden" name="tracking" value="true" />
<input type="hidden" name="nofollow" value="true" />
<input type="hidden" name="redirect" value="301" />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?

Plugin Security Scorecard Grade for Pretty Links

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