Sucuri Security Uses Bad Data to Try to Scare People into Using Their Service

When it comes to security companies most of what we see is quite bad. Most of them don’t have a good understanding of security, sell products and services that can’t do what they claim they can, or are some combination of both of those things. Sucuri Security is one of the worst companies we have seen and would fall in to that last category. We have been hired on quite a few occasions to re-clean websites they previously hired to clean, for which they failed to basic parts of the cleanup – like determining how the website was hacked – that if done, should have prevented the website from being re-hacked in the first place. Among things we have seen, there was the recent situation we came across where we found that they were helping to put WordPress websites at greater risk of being hacked.

That isn’t just our perspective, last week someone contacted us wanted to know if we knew a good alternative to Sucuri due to this litany problems they had with them:

I’ve been using Sucuri for about 5-6 months and it’s been the worst experience I’ve had with a service provider that I can remember. CloudProxy throws false positives all the time, and I explicitly asked them to remove it from one of our 5 sites multiple times and support ignored the request. The support has been bad from day one–beyond belief bad–not just in this instance but with nearly all the tickets I’ve opened.

Three years ago we discussed their SiteCheck security scanner’s poor quality and something we ran across the other day shows that it hasn’t gotten better, but in the meantime they have turned up the fear factor to try to scare people into using their service.

While we were looking too see if anyone else had discussed a false report of a vulnerability in WordPress 4.2.2, we can across a mention that a security company was running a vulnerable version of the Apache HTTP server on their website. That would be interesting if it was true. Following the link on that post brought us to this page on Sucuri’s SiteCheck:

sucuri-sitecheck-bad-warnings

A quick check showed that Sucuri was providing misleading information, we’ll explain that in second, but first let’s look at their rather scary warnings that came along with that bad information. First they warn “Outdated Software detected. Immediate Action is Recommended.”:

sucuri-sitecheck-bad-warnings-small-1

Then they warn of a “High” severity issue due to the website being outdated. and recommend to “PATCH AND PROTECT With Sucuri Firewall”:

sucuri-sitecheck-bad-warnings-small-2

Then they warn that an “Outdated Web Server Apache Found”:

sucuri-sitecheck-bad-warnings-small-3

They are a couple of major problems with this, first if the Apache HTTP Server version was actually outdated the solution would be to update it, not buy some security service they provide. Only in small text at the bottom do they suggest that “You can contact your host about it and ask them to update for you”:

sucuri-sitecheck-bad-warnings-disclaimer

Their claim that their CloudProxy service can automatically update the software is simply untrue.

The bigger problem is that Sucuri has no idea if the Apache HTTP server is in fact outdated in this instance and therefore if the “High” severity issue actually exists. To explain this let’s start by taking a look at a second screenshot, this time of our Server Details extension for Chrome on the same website:

fortiguard-server-details-screenshot

You can see it also identifies the website as using version 2.2.3 of the Apache HTTP Server, but it doesn’t label it as being outdated (despite that being a capability of the extension). The reason it doesn’t label it as being outdated is due to the second piece of information, that the server is running CentOS 5. The CentOS operating system is based on Red Hat Enterprise Linux (RHEL), which means that instead of introducing new versions of included software when a security fix is released they backport the security fix to the existing version. That means that while that server is using an outdated version of the Apache HTTP Server, it isn’t necessarily outdated in a security sense. If Sucuri Security did in fact have the security expertise they claim to have, they would know about this and properly handled this situation.

Now you might be wondering how hard it would have been for them to check for this type of situation before showing such dire warnings. They way we get the information for our extension and how Sucuri probably get their data is to look at the Server HTTP header. For this website it is this:

Apache/2.2.3 (CentOS)

CentOS is one of three words in it, so it isn’t hard to detect. (We are able to say the website is running version 5 of CentOS based on the Apache HTTP Server version identified in that.)

Posted in Bad Security, Sucuri Security | 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

SiteLock Also Managed to Break a Website

When it comes to improving the security of websites one of the biggest impediments we see is the many companies selling security services. The services they sell generally don’t do much too actually fix the underlying security issues that exist (and could be fixed), while at the same time they spread a lot of bad information making it harder to actually improve security. The general sense we get is that these companies neither care nor know much about security.

One such company we have discussed several times before is SiteLock. In the past we have mentioned how they continue to fail to do a basic security check and don’t do proper hack cleanups. In another post we looked at how GoDaddy was distributing software to clients with known security vulnerabilities while trying to sell an additional service in partnership with SiteLock to “Defend your website against hackers” and “Keep your site clean and secure.”. If SiteLock cared about security you would think they would have insured that GoDaddy resolved that situation before they partnered with them.

A recent situation we were brought in on showed yet more problems with SiteLock. A Joomla website hosted with GoDaddy was hacked and GoDaddy recommend to the website’s owner that they sign up SiteLock’s service to clean it up. SiteLock then did what they describe as 95 percent of the cleanup, but then told the website’s owner that rest of the work would need to be done manually and would incur an additional fee. In the meantime the work SiteLock had done had managed to break the website, with only the homepage loading anymore. The website’s owner was unsettled about SiteLock wanting more money to complete the work and the fact that the website was broken after the partial work was done, so they reached out to us to take a look.

The most likely culprit for when only the homepage is loading for a Joomla website that has Search Engine Friendly URLs enabled, like this one did, is that the .htaccess file has been damaged in some way. The code in that file is needed to translate the Search Engine Friendly URLs in to the form understood by the underlying software. It isn’t uncommon when we are brought to re-clean a hacked website that has been previously cleaned with an automated tool to find that core files have been damaged or deleted entirely, causing varying degrees of problems with the website. In this situation the .htaccess file was missing all of the normal code that should be in it when we took a look at it.

One nice feature of GoDaddy’s standard control panel is that you are able to view how files looked over the previous month or so, which can come in handy when dealing with recently hacked websites. In this case we figured we could pull up the file from right before SiteLock did its cleanup and then restore the file and just remove the malicious code in it. Surprisingly there was no malicious code in the file, so unless some malicious code was added between when backup file was made that day and the time of their cleanup, it looks like SiteLock managed somehow to damage a file that had not contained any malicious code and shouldn’t have been touched.

Posted in Bad Security | Tagged | Leave a comment

Lack of Prompt Revive Adserver Upgrades Reminder That Basic Web Security Precautions Still Not Being Taken

When it comes to keeping websites secure, what we see is that companies are trying to sell people services of limited to no security value while important security practices go undone in many cases. One of the basic measures that needs to be taken to do that is to keep software running on websites up to date as that prevents known security vulnerabilities from being exploited, unfortunately that often doesn’t happen. In the past we looked at data showing this was true for the likes of Drupal, Joomla, and others. Yesterday, Revive Adserver put out a post showing what versions of their software are in use and they tell a similar story.

About 56 percent of the active installations of Revive Adserver are running either version 3.0.2 or 3.0.5:

Source: http://www.revive-adserver.com/blog/quick-adoption-of-revive-adserver-v3-2-0/

Version 3.0.5 contains two moderate severity security issues that were fixed in versions 3.0.6 and 3.1.0, which were released in December. Versions 3.0.2 contains an additional moderate severity security issue that was fixed version 3.0.5, which was released a year ago. We haven’t seen any major issues when upgrading from these versions so there isn’t any excuse not having done this by now.

If you haven’t been keeping Revive Adserver up to date now you should do that now (if need someone to do that for you, we can take care of that for you). For anyone who still hasn’t upgraded from OpenX you really need to do that now since that has more severe known security vulnerabilities in it at this point and the upgrade to Revive Adserver is relatively easy.

Posted in Outdated Web Software, Revive Adserver | 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

CloudAccess.net Stores Non-Hashed FTP/SFTP/SSH Passwords

One of the ways that security issues at a web host can lead to hosted websites getting hacked is if there is breach that reveals users login details and then the hacker uses those to log in to customer accounts. Not getting breached in the first place is the best way to prevent this type of thing from occurring, but other measures should be taken to limit the potential impact of a breach.

One of the measures that needs to be taken is to store passwords as securely as possible, which means storing them in hashed form. You can think of a password hashing as one-way encryption. That is, the data is encrypted, but it cannot be decrypted, so the underlying password is not retrievable in normal circumstances. With this type of password storage when someone tries to log in the password they input is hashed and then compared with the stored password hash to see if they are the same. With hashed passwords even if someone gets access to the stored passwords it would be difficult for them to do anything with them, since they would first have to crack the hashes.

One way to spot if a password is being stored in non-hashed form somewhere in a web host systems is if it can be displayed to you, since if they were only stored in hashed form they wouldn’t know what the underlying password is to be able to show it to you. While we were working on a website hosted with CloudAccess.net recently we spotted this page in their control panel:

CloudAccess.net control panel FTP/SSH page

When you click on the “View hidden password” it will in fact show the password for FTP/SFTP/SSH, which wouldn’t be possible if the password was properly stored. Since we can’t see the underlying systems we don’t know if they are storing the password in plaintext somewhere, which would be the worst case, or if they are at least encrypting it.

Such bad security doesn’t match CloudAccess.net’s claims about their security. For example they claim that:

The CloudAccess.net Platform is continually monitored and managed by specialized security experts who understand the security requirements of both the server and application.

Another claim that sounds bad, but could be an indication that other web hosts have even worse security is that:

Our managed hosting service is widely considered to be more secure than the many alternatives.

Posted in Bad Security | 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

InMotion Hosting Prominently Promoting Installation of EOL’d Joomla Version

When it comes to keeping websites secure, keeping the software on them up to date is one of the basic measures that needs to be taken. We know that web hosts are aware of this because they will often tell people when their websites have been hacked that it was due to outdated software (since this usually isn’t based on any actually evidence, it often is wrong). Unfortunately we continue to find that web hosts don’t bother to make sure that they are not distributing outdated software to their customers.

Recently while doing some work on a web site hosted with InMotion Hosting, we noticed that in the website’s cPanel control panel that the option to install Joomla 2.5 was being prominently displayed:

inmotion-hosting-cpanel-joomla-25

That should not be happening since support for Joomla 2.5 ended back on December 31. Not only does that put websites at risk if a security issues is found in Joomla 2.5, but it can cause unnecessary trouble down the road because upgrading from Joomla 2.5 to 3.x is not always the one-click upgrade it is a promoted as.

On the installation page they do provide the option to install the currently supported version of Joomla, 3.4.1, as well. But you would have to select that version from a drop down box:

inmotion-hosting-joomla-25-installation-page

The problems don’t stop there. On the main page for their software installing service the ninth slot is Moodle 2.0:

inmotion-hosting-top-applications

Support for Moodle 2.0 ended nearly three years ago, in June 2012.

As with Joomla, they do also offer supported versions, but you would have to select those from a dropdown where 2.0 is the default:

inmotion-hosting-moodle-20-installation-page

Installing this version now will lead to otherwise unnecessary work down the road because Moodle will have to be upgraded to version 2.2 before it can be upgraded to a version 2.3 of higher.

Posted in Bad Security, Joomla, Moodle, Outdated Web Software | Leave a comment

Most Website Hackers Are Not Sophisticated

One thing that we see fairly frequently with Internet security companies is that they try to sell their largely unneeded, and usually largely ineffective, security products and services by portraying websites as under constant threat from sophisticated hackers.  The reality is that while few hackers are quite sophisticated, most hackers only have rudimentary skills and basic security measures will prevent your website from being hacked. As an example of what you are dealing with in most cases let’s take a look at someone’s claim on ZONE-H – a website for displaying defaced websites – that they had hacked our website last week. Since that page is supposed to be removed once the claimed defacement is reviewed, here is a screenshot of it:

zone-h-whitefirdesign-com-screenshot

What you can see with that is that the mirror copy of our website shown from the time of the claimed defacement doesn’t actually show that the website has been hacked. Instead it shows that if you request a page on our website that doesn’t exist you will get a message that it doesn’t exist. Why someone would try to pass that off as defaced/hacked website is unclear to us.

Based on the URL of the supposed defaced page, http://www.whitefirdesign.com/wp-admin/admin-ajax.php?action=revslider_ajax_action&client_action=get_captions_css, what they were trying to exploit was a vulnerability in a WordPress plugin that a) we don’t even use, so there is no chance it could be exploited and b) if we did use it and had the vulnerable outdated version installed they would have needed to try to exploit it from where WordPress is actually installed on our website, which isn’t the root directory of the website as they tried (this could be easily checked on, which again shows the lack of sophistication that usually exists).

Posted in Website Hacked | Leave a comment