Category Archives: WordPress

SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services

When it comes to security plugins for WordPress, we don’t think to highly of most of them. But we have continued to be surprised how low things can go with them. Take for example the¬†WP Antivirus Site Protection (by SiteGuarding.com) plugin, which on it’s description page on the Plugin Directory it states near the top:

This plugin will be especially useful for everybody who downloads WP themes and plugins from torrents and websites with free stuff instead of purchase the original copies from the developers. You will be shocked, how many free gifts they have inside ūüôā

Their touting its use for those that pirate WordPress themes and plugins is kind of incredible on its own (note the lack of past tense in terms of downloading that software or lack of suggestion not to do that). But more incredible is the fact that at the same time the plugin is really just a connection for a mostly paid service, so they think you should pay them, but are okay with people not paying the developers of software.

What makes that dichotomy more striking is the comments from the developer on some of the negative reviews of the plugins.

One review reads:

If your website contains a file larger than 25MB, the plugin will abort and ask you to upgrade rather than just skipping it and warning you. The plugin is just a leadgen ploy. Uninstalled. Further more, of all the wordpress hacks I’ve ever seen, files affected are NEVER large or over a few kb.

That seems like reasonable complaint, which gets this response from the developer:

free version has limits. if you are not ready to pay for the security enjoy and live with the viruses.

As part of their response to another review the developer wrote in part:

If you installed it again. It means plugin is good, you just dont want to pay for good plugins and services and want everything for free.

It is also worth noting that there are a lot of rather fake looking reviews for the plugin.

Posted in Bad Security, WordPress Plugins | Tagged , | 1 Comment

The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It

When it comes to improving the security of websites one of the biggest problems we see if the shear amount of bad information, including lots of bad advice, that is being put out there. We frequently see people suggesting using the Wordfence plugin for WordPress, which we have hard time believing somebody who is knowledgable about security would recommend due to a number of issues. Those issues include the fact that broad based security plugins like that are not all that useful against real threats, that more than a few security vulnerabilities have been found in the Wordfence plugin itself, that the developers don’t seem to have a¬†good grasp of security, and that the plugin¬†produces some really bad false positives. Usually you have no way of knowing if somebody giving out that advice has a different opinion in regards to those types of things or they are giving advice without really being informed about the situation.¬†In some cases you can see that advice is being handed out uniformed, though.

As part of keeping track of security issues in WordPress plugins for our¬†Plugin Vulnerabilities service,¬†we monitor the wordpress.org forum for threads¬†related to plugin vulnerabilities. In addition to helping to find some more vulnerabilities to include in our data, we run across threads about other security issues related to WordPress and WordPress plugins. In one of those we saw when the use of Wordfence being suggested as a solution, when that clearly wasn’t helpful¬†advice.

The original poster in the thread described the problem they were having cleaning up a hacked website. After trying numerous things, including reverting to a backup copy, malicious files were continuing to be added to the website. At the end of the post they mentioned that they have three WordPress security plugins installed, but that they hadn’t been any help:

Protections plugins I’m currently using (and which can’t find anything wrong with the website)

Despite that one those plugins was Wordfence, the second and third responses suggested that Wordfence could deal with the issue:

Yes, those are not default files. WordFence is the best for scanning once you are already infected.

and

I had the same issue, so far WordFence has done a great job. Two days and no wp-checking.php has showed up. Yet!

In this type of situation what we would recommend, and did later in the thread, is to see if you can determine if the hacker still has some sort of access to the website, which is allowing them to continue to modify the website, and if that is the case, close off that access.

Incidentally, one of the other plugins they were using, AntiVirus, was one that we found was flagging a fresh install of WordPress as having virus back in 2012.

Posted in Bad Security, WordPress Plugins | Tagged | Leave a comment

iThemes Security Plugin Has “One-Click Secure” Button That Does Nothing Except Claim The Website Has Been “Secured”

We are frequently asked what about various broad based WordPress security plugins and which ones should be used. Our answer to the second¬†part of that¬†is none of them. These plugins generally provide little protection against actual threats and have been found to have security vulnerabilities themselves fairly often. That second part might sound odd, you would think that someone developing a security related plugin would be very careful about the security of their plugin, but people that actually know about security would be unlikely to be involved in developing one of these due to the first part of that, that they don’t provide much protection against actual threats.

So what you are left with is products generally developed by people that don’t have much concern for real security and in a lot of cases seem to be mainly interested in making money by taking advantage of the public that understandably lacks strong security knowledge. That results in lots of plugins and related services that end up scaring people based on bad or false information and that collect information from users under false pretense.

If you are looking for some particular security feature you would be better off finding a plugin that doesn’t also include a kitchen sink of other features¬†with it, since that reduces amount of code that could be harboring security vulnerabilities. The important things you need to do to keep your website secure are listed here.

The iThemes Security Plugin And Trust

That all brings us to something we just ran across with one of those plugins, iThemes Security (formerly Better WP Security), which is listed as having 700,000+ active installs.

One important element of any security product is trust,¬†since the average user can’t verify that a product does what it says, they are trusting the developers in a major way. Any abuse of that trust should be a major¬†red flag. That trust is¬†something the developers of the iThemes Security plugin don’t seem to care about.

When you install and activate the iThemes Security plugin a notice is displayed at the top of the page with a button to “Secure Your Site Now”:

ithemes-security-1

Clicking on that brings up this page:

ithemes-security-2

The most important part of that would seem to be the section Titled “Secure Your Site”:

Use the button below to enable default settings. This feature will enable all settings that cannot conflict with other plugins or themes.

When you click on the One-Click Secure button, you get a message that it is “Working…” for a moment:

ithemes-security-4

Then it will tell you that “Site Secured. Check the dashboard for further suggestions on securing your site.”:

ithemes-security-5

Based on that you would think that the website has been secured in some way after doing that. It turns out that nothing actually has happened, something we found about when ran across a post on a thread on the WordPress.org support forum for the plugin that stated

Please note that since the 5.2.0 release (5.2.1 included) clicking on the One-Click Secure button in the First Important Steps modal window will not do anything despite the fact that it still reports:

Site Secured. Check the dashboard for further suggestions on securing your site.

which is also kind of lame as there is no longer a Security Status section on the Dashboard page …

Note this is not a bug, since iThemes knowingly removed the code that was normally executed behind this button …

If you want to see that for yourself you can see the changes made in version 5.2.o here¬†(doing a search on the page for “Register one-click settings” will take you to parts of the page where that is shown).¬†What makes this even more incredible is how long ago this happened, version 5.2.0 was release on January 18 and the post pointing that out is now two months old, and yet it is still that way now.

When they don’t care about misleading people with something that visible, then you have to wonder what else they might be misleading people about. We already spotted¬†one other thing, but you will have to wait for a future post to hear about that.

Posted in Bad Security, WordPress Plugins | Tagged | Leave a comment

WordPress Leaks Potentially Sensitive Information From Private Posts and Pages

Over at our Plugin Vulnerabilities service we are in the process of trying to help to get a fairly serious security issue with a WordPress plugin fixed. In the process of doing that we have noticed an issue with WordPress that impacts more than this plugin. Without getting into the details of it, since a fix is still in progress, the plugin created WordPress pages which provide access to non-public data. These were accessible by the public, which was a problem. As part of trying to fix this, these pages were intended to be made private (we say intended because that wasn’t done right). This would have worked in private pages were totally private, but it turns on they are not.

Here is how the WordPress documentation describes what the impact of setting¬†a post’s or page’s visibility to private:

Private content is published only for your eyes, or the eyes of only those with authorization permission levels to see private content. Normal users and visitors will not be aware of private content. It will not appear in the article lists. If a visitor were to guess the URL for your private post, they would still not be able to see your content. You will only see the private content when you are logged into your WordPress blog.

Despite the claim that “normal users and visitors will not be aware of private content”, that isn’t totally true. If you have your permalink structure set to include the title of the page in it, which is fairly common set up, then someone can find out the titles of private posts and pages.

You do that by taking advantage of WordPress’ automatic redirection from plain URLs to the chosen permalink structure. Lets say a post with ID number 12 was titled Surprise Party For Julie In Accounting, when accessing

http://example.com/?p=12

WordPress to automatically redirects you to

http://example.com/surprise-party-for-julie-in-accounting/

The page you see though gives no indication that a private page exists, as the documentation suggest:

Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search?  Search for:

By enumerating through potential ID numbers you can see what the titles of all private posts and pages on a website are.

Coming back to the plugin, the title of those pages contains enough information to allow some access the non-public data. While the plugin shouldn’t have you used pages in the way it did, we suspect that in other cases private posts or pages could also contain sensitive information in the title that isn’t meant to be public, as it is now.

After noticing this we thought that we should bring this to the attention of the WordPress developers since it doesn’t seem like this should be this way. It turns out that someone already did that 8 years ago, back around the time of WordPress 2.3.1. But 7 years ago that ticket was closed and marked as “wontfix”. Maybe there was some good reason for that, but the only comment included with that change was “there’s a dup of this one somewhere, and it shoud get wontfixed too.”¬†The fact that a potential security issue was treated in this way is more than a little concerning.

Posted in Website Security, WordPress | Leave a comment

Why Does The WordPress Plugin Directory Have Rules If They Don’t Bother To Enforce Them?

When it comes to distribution platforms for software one of the frequent complaints of developers is uneven enforcement of rules and regulations, which makes¬†it hard to know what is and isn’t acceptable. Recently we came across an example of this with Plugin Directory for WordPress:

While dealing with one of the vulnerabilities we recently discovered through our Plugin Vulnerabilities service, we were have a bit of issue discussing communicating about the issue since it turned out the plugin had two names.

On the Installed Plugins pages in WordPress it is referred to as Spider Event Calendar:

spider-event-calendar-on-installed-plugins-page

On the Plugin Directory its name is WordPress Event Calendar:

wordpress-event-calendar-on-plugin-directory

Okay, actually while the main name is WordPress Event Calendar, you can see that it is referred to by both names in different places:

wordpress-event-calendar-on-plugin-directory-full

It is confusing to say the least and it seems like restricting a plugin to one name would be reasonable thing to do, but what seem to be the bigger issue here was with the fact that using the word WordPress in a plugin’s name is supposed to be against the rules of the Plugin Directory.

On the Detailed Plugin Guidelines page it says:

Don’t violate our trademarks. Don’t use “wordpress” in your domain name. Use “wp” instead, or better yet, come up with your own original branding! People remember names.

On the Developer FAQ page it is put a lot more clearly:

Are there names you don’t permit?

We don’t allow ‘WordPress’ in plugin names as it’s redundant and somewhat obvious that you’re a WordPress plugin.

A little more looking showed that the same developer had six plugins with WordPress in the name:

webdorado-wordpress-plugins

All six of those plugins have associated paid plugins.

A search of the Plugin Directory shows that these are far from the only ones using WordPress in the name of plugins:

plugin-directory-search-results-for-wordpress

It certainly seems like the Plugin Directory is allowing the word WordPress to be used since it is in such wide use and it would be easy to detect its usage in the name of the plugins when getting the name of the plugins from their files to show it in the Plugin Directory. If this is the case then the documentation should be updated, otherwise we have just provided the people running the Plugin Directory with an easy way to find a lot plugins that they need to do something about.

Posted in WordPress Plugins | Leave a comment

Security Company with WordPress Security Plugin Doesn’t Keep Their Own WordPress Installation Up to Date

When it comes to trying to improve the¬†security of websites, one of the problems that we see is that while many people are still not taking basic security measures with their websites¬†there are¬†plenty of companies¬†pushing additional security products and services. In some cases we have seen that the inflated claims of some of those products and services lead people to not take basic measures, since those products and services claim that they will prevent them from being hacked, and because they haven’t taken the basics security measures they end up getting hacked. While we do don’t have much evidence, we are concerned that other people don’t take basic security steps since keeping seems so daunting when they are told they need to being using all of these different products and services to keep their website secure.

A question that underlies this is if these companies actually are all that concerned about security or if they just trying to make a quick buck peddling products and services whose security implications they have little understanding. One way quick check to get an idea of their concern for security is to see if they are¬†keeping the software running their own websites up to date. The results we have seen in the past haven’t been good, like¬†the time we found that all of the companies we looked that were advertising to clean up hacked Joomla websites were all running outdated software (mostly Joomla). This time around we happen to run across the website of a company name Centrora Security, you can see from the results of a Chrome extension we make that they are not keeping the WordPress installation running their website up to date:

The Centrora Security website is Running WordPress Version 4.0.1

Not only have they not updated it for ever over a year and not updated it for the two most recent major versions, 4.1 and 4.2, but they have missed three security updates for 4.0.x series: 4.0.2, 4.0.4, and 4.0.5. Since WordPress 3.7, minor version updates like those security updates would normally be applied automatically, so either Centrora Security unwisely disabled that feature or some bug is stopping that from happening in their case. If it is the later then Centrora Security could actually help to improve the security of WordPress websites by working the WordPress developers to resolve that, so that others impacted by the issue could also start getting updates.

While they don’t take the basic step of keeping WordPress up to date, they produce a WordPress security plugin that they claim is the “MOST POWERFUL WORDPRESS SECURITY PLUGIN”. Probably not all that surprisingly they are not running the latest version of their own plugin on the website (the readme.txt for the plugin¬†on the websites is from¬†version 4.8.4), even though keeping WordPress plugin update to date is also an important security measures.

Posted in Bad Security, Outdated Web Software, WordPress Plugins | Tagged | Leave a comment

This Is Not a Remote File Inclusion Vulnerability in WordPress 4.2.2

As part our effort to improve the security WordPress plugins we monitor new reports of WordPress related vulnerabilities so that we can¬†help to make sure they get fixed¬†(and add them to our Plugin Vulnerabilities plugin). While most reports involve actual vulnerabilities, fairly often we run across reports for¬†vulnerabilities that don’t exist. Today we ran across one really bad report worth discussing since the claimed vulnerability is so severe. The vulnerability report is titled “WordPress 4.2.2 – Remote File Inclusion“. It would be a big deal if the latest version of WordPress had any publicly disclosed vulnerability, but a remote file inclusion vulnerability would be a very big deal since that is type of vulnerability that is highly likely to be exploited by a hacker.

The first part of the advisory clearly indicates the vulnerability in the latest version of WordPress since the Software Link is to https://wordpress.org/latest.zip:

######################
# Exploit Title : WordPress 4.2.2 - Remote File Inclusion
# Exploit Author : amir disconnect
# Vendor Homepage : https://www.wordpress.org/
# Date: 30/6/2015
# Tested On : Linux Kali , Windows 7
# Software Link : https://wordpress.org/latest.zip
# Version : 4.2.2
# CVE: N/A
######################

Then immediately after that it¬†becomes¬†clear the advisory is related to a plugin, since the claimed vulnerable file is a file in the¬†Shortcake (Shortcode UI) plugin, which doesn’t come with WordPress:

# Remote File Inclusion

# Proof

http://site/[path]/wp-content/plugins/shortcode-ui/inc/class-shortcode-ui.php

So right there we can rule this out as being a vulnerability in WordPress, version 4.2.2 or otherwise, but was about it being a vulnerability in the plugin?

What appears to be the claimed vulnerability is mentioned at the end of the advisory:

Note:at the line 172 include apeared without any filter

That refers to the line “include $template;” in the following function:

public function get_view( $template ) {

	if ( ! file_exists( $template ) ) {

		$template_dir = $this->plugin_dir . 'inc/templates/';
		$template     = $template_dir . $template . '.tpl.php';

		if ( ! file_exists( $template ) ) {
			return '';
		}
	}

	ob_start();
	include $template;

	return ob_get_clean();
}

For it to be possible for this to be a vulnerability the value of $template would need to be something that is user assignable, which it isn’t. The variable value is assigned¬†when calling the function get_view.¬†The plugins calls that function in three instances¬†and all of them use pre-assigned values:

echo $this->get_view( 'media-frame' ); // WPCS: xss ok
echo $this->get_view( 'list-item' ); // WPCS: xss ok
echo $this->get_view( 'edit-form' ); // WPCS: xss ok

So there doesn’t appear to be any security issue here.

Posted in Bad Security, WordPress | Leave a comment

The Slow Pace of WordPress Plugin Vulnerabilities Getting Fixed

Since we have been reviewing publicly disclosed security vulnerabilities in WordPress plugins to add them to our Plugin Vulnerabilities plugin, one of the things that has stood out to us is how long it can take for vulnerabilities to get fixed. Part of what makes this stand out is that in many of the cases fixing the vulnerability is quite easy, so it seems that many developers are just not too concerned about keeping their plugins are secure.

Let’s take a look at recent example of this. Back in March¬†g0blin Research discovered an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin¬†AddThis Sharing Buttons¬†(formerly¬†Smart Website Tools by AddThis). This plugin currently has over 200,000 active installs according to WordPress.org, has 12 listed authors, and is developed a private corporation of the same name. The vulnerability was caused by an Ajax function that should only be accessible to Administrator level users being accessible to any registered user. That severely limits the potential danger of the vulnerability since most WordPress based websites do not allow the public to create accounts, so someone relatively trusted with malicious intent would be required for the vulnerability to be exploited. It also should make it quite easy to fix, but as the timeline included with advisory (show below) shows it took the developers over two months to fix the issue:

2015-03-19: Discovered
2015-03-19: Vendor notified
2015-03-19: Vendor responded ‚Äď link to report provided
2015-03-20: Version 4.0.7 released ‚Äď issue still present
2015-03-26: Vendor responded with intent to fix
2015-03-31: Update requested from Vendor
2015-04-07: Vendor responded stating that a fix is in progress
2015-04-13: Update requested from Vendor
2015-04-16: Vendor states that fix is undergoing QA
2015-05-04: Update requested from  Vendor
2015-05-11: Update requested from Vendor
2015-05-12: Vendor states that fix was rejected by QA, has been redeveloped and has been passed back to QA for re testing.
2015-06-01: Notified vendor of intention to contact WordPress Plugins team
2015-06-03: Version 5.0.4 released ‚Äď issue resolved
2015-06-10: Advisory released

So what does it take to get this type of issue fixed?

There are two functions that are often used to check if someone is Administrator level user. The more widely used is to check if the user has the capability to manage_options:

current_user_can( ‘manage_options’ )

That capability is normally only provided to Administrator level and above users, and allows access to WordPress settings pages. That would be particular relevant for fixing this vulnerability as the vulnerable Ajax function is something that would have normally be accessed from a settings page.

The second function checks if a user is a Super Admin or Administrator:

is_super_admin()

With that function if network mode is enabled (WordPress MutliSite) it will return true¬†if the user is a Super Admin¬†and when network is not enabled it will return true if the user is an Administrator. Beyond the implications that this has with MultiSite websites, there is a potential that someone will accidentally use is_admin when they meant to user is_super_admin. That would be a security problem of its own, as¬†is_admin¬†only checks if an administrative page is being requested and “does not check if the user is logged in, nor if the user even has access to the page being requested”.

So what did the AddThis Developers come up after months and having a fix rejected by quality assurance?

First up is the relevant function before being fixed:

public function addthisAsyncLoading()
{
if ($this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
}
die; //exit from the ajax request
}

Here is the fixed version (fix bolded):

public function addthisAsyncLoading()
{
if (current_user_can( ‘manage_options’ ) && $this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
}
die; //exit from the ajax request
}

Why it two months to add less than a line of code is something we don’t understand. It could have been worse, in another case¬†with the same failure to check on a user level, it to¬† the plugin being¬†pulled the plugin from the Plugin Directory for the vulnerability to be fixed (following us reporting it to Plugin Directory).

Posted in Bad Security, WordPress Plugins | Leave a comment

44.7 Percent of Plugins in the WordPress.org Plugin Directory Haven’t Been Updated in Over Two Years

Plugins play an important part in the success of WordPress, but they also introduce their own issues. Security issues obviously get a lot of attention, but there are other issues like the fact that not all plugins continue to be supported long term.¬†One measure of how many plugins continue to be supported is to look at when plugins were last updated, as even plugins that have not needed any changes should have been updated periodically to indicate that they are compatible with new versions of WordPress.¬†On the WordPress.org¬†Plugin Directory, plugins that have not been updated in over two years have a banner at the top of the page that states ‚ÄúThis plugin¬†hasn‚Äôt been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.‚ÄĚ:

Warning shown in the WordPress.org Plugin Directory when plugin hasn't been updated in over two years.

Last year, following a suggestion for our No Longer in Directory plugin,¬†we added the functionality to list installed plugins that had not been updated in over two years in addition to its listing of plugins that have been removed from the Plugin Directory. We also put up a post looking at how many plugins that met that criteria at the time. Now, a¬†little over year later we thought it would be a good time see again how many plugins haven’t been updated in over two years.

As of earlier¬†today¬†a total of 16,935 listed plugins¬†had not been updated in over two years. That is 44.7 percent of all 37,905 of listed plugins. (Last year’s percentage¬†isn’t equivalent since we included all plugins that¬†entries in the Subversion Repository for the Plugin Directory, even if the plugin wasn’t currently or possibly ever in the Plugin Directory.)

Below we have charted what year these plugins were last updated. The number for 2013 is lower as plugins last updated after May 18 of 2013 would still be under two years out of date.

Number of WordPress Plugins That Have Not Been Updated in Over Two Years: 2004 7, 2005 146, 2006 61, 2007 435, 2008 1287, 2009 2426, 2010 3241, 2011 3408, 2012 4127, 2013 1797

Warnings Missing in WordPress

While the WordPress.org Plugin Directory website displays¬†a warning banner at the top of a plugin’s pages, inside WordPress a similar warning is not provided. Here is what is shown on the Add Plugins page in WordPress for the same plugin shown in the screenshot above:

add-plugins-no-warning-1

Here is what you see if click the More Details link on that page:add-plugins-no-warning-2

Also if you have one of these plugins installed you don’t get shown any notice on the Installed Plugins page:

installed-plugins-no-warning

Posted in WordPress Plugins | Leave a comment

Does the Vulnerability Fixed in WordPress 4.2.1 Also Impact WordPress 3.7, 3.8, and 3.9?

Update (May 7, 2015): WordPress has now released versions 3.7.8, 3.8.8, and 3.9.6 that fix the vulnerability described below.

 

Last week a vulnerability in WordPress was disclosed and fixed in version 4.2.1. While WordPress only officials supports one version at a time, since the introduction of automatic updates in WordPress 3.7 they have been releasing security updates for all older releases that include the automatic updates feature. This time though only updates for 4.0 and 4.1 were released.

An update for 3.9 has a Codex entry, which indicates that the version, 3.9.6, was released to deal with this. But that version doesn’t appear to exist. Updates for 3.7 and 3.8 also had Codex entries, but those entries were deleted last Friday.

We were curious as to what was going on (as are¬†others) since knowing the full implications of vulnerabilities that impact WordPress is important when we are cleaning up hacked WordPress websites. So we decided¬†to do some testing to see if the vulnerabilities actually impacted¬†versions¬†3.7-3.9 and they haven’t been fixed or if those versions are not vulnerable.

When using the sample exploit code provided for the vulnerability we found that vulnerability is not exploitable in versions 3.7-3.9 in the form given. The reason for this is that in WordPress 4.0-4.2 a character near the beginning of the malicious comment is encoded:

<a title=&#8217;x onmouseover=alert(unescape(/hello%20world/.source))

That allows the malicious code that begins¬†“onmouseover” to be executed. In 3.7-3.9 that encoding doesn’t occur:

<a title='x onmouseover=alert(unescape(/hello%20world/.source))

So the “onmouseover” is treated as part of the title attribute instead of as code that should be executed, so no malicious code is run.

The underlying problem that leads to all of this, that WordPress didn’t properly check to make sure that comments longer then could be stored are properly handled also does exist in these versions, so it is possible somebody could figure out another way to exploit this in versions 3.7-3.9. If you are still running 3.7-3.9 we would recommend you upgrade to at least 4.0.4 as soon as possible. Though, it would be best that anyone still running a version below 4.2.1 to upgrade to that version.

Posted in Website Security, WordPress | Leave a comment