WordPress

Our New Web Browser Extension to Warn When Outdated Software is Being Used

We are always looking for ways how we can help to improve the security of the web. One of the basic security measures that needs to be taken to keep websites secure is keeping the software running on them up to date, as newer releases often contain security fixes and enhancements.

The developers of web software have done a lot to make that easier by providing messages in the software that the websites is in need of update and making the update process easier. Even with this there is still many website running outdated versions of that software.

When we are in touch with people running websites whether they are potential clients, people we are contacting to let them know their website has been hacked, or for some other reasons, we make sure to let them know if we see they are running outdated software that needs to be updated. We only reach a limited number of people so to increase awareness that outdated software is running on websites we have created a new web browser extension, named Meta Generator Version Check, to make it easier for others to see when there is outdated software running a website.

With the web browser extension installed, each time a web page finishes loading the extension checks the web page’s source code for a meta generator tag. The one for the current version of WordPress looks like:

<meta name="generator" content="WordPress 3.2.1" />

After reading that, the extension then provides a warning if it detects one of the following software is running on the website:

WordPress versions prior to 3.2.1
Joomla 1.0 and Joomla 1.6
Mediawiki versions 1.16.4-1.13 (earlier versions do not contain a meta generator tag)
vBulletin versions prior to 3.8.7
TYPO3 versions prior to 4.3
Movable Type versions prior to 4.37, 5.06, and 5.12
Melody versions prior to 1.0.2

Looking at that list you might notice that there is a fair amount of software missing. The limitation of checking the meta generator is that not all software produces one and some of those that do, do not provide a tag that allows us to identify what version is running. In other cases only partial version information is given. For Joomla, this means the extension can warn about websites running Joomla 1.0 and 1.6, which are no longer supported, but for Joomla 1.5 and Joomla 1.7 there is no indication if they are running the current version of those, as of yesterday they were 1.5.24 and 1.7.2, or an older version.

Another issue we have found as we looked to add checks for more software is that the supported versions of software are not always easy to find. We would recommend that software developers make sure that they prominently display what versions of their software are supported so that people looking for that information can easily find it.

If you see that we are missing a check for software that provides the required information in the meta generator tag please let us know so that we can include that in the extension.

While it would be possible to have the extension do a more intensive check to determine what version of software is running on website, using information not available in the meta generator tag, this would in most cases require requesting additional files when each page is loaded and would provide information that is not being made available by the web page itself.

We currently plan to update the extension to warn that software is outdated a month after a subsequent version has been released or support has ended for a version. For severe security vulnerabilities the extension may e updated sooner provide an earlier warning.

Uses

The main use for the extension is to be alerted that websites that you are visiting are running outdated software so that you can let them know that they need to update it or if they are your client you can do the update yourself.

It also could be useful in looking at who you considering doing business with or what software you might use on your website.

If a web host isn’t keeping software on the frontend of their website updated, it is reasonable to be concerned that they might not be taking proper security measures for their hosting clients as well. After checking just a few web hosts we found that both Just Host (3.0.3) and IX Web Hosting (3.1) were running outdated version of WordPress. It is also interesting to note that homepage of IX Web Hosting’s website has security seals from both McAfee Secure and something called Ecommerce HackerShield (which appears to something created IX Web Hosting’s parent company) claiming the website is secure despite the outdated software, with known security vulnerabilities, running on a sub-domain of the website and linked directly from the homepage.

For software, an example of something that might be concerning that we just noticed with a piece of software that we run on our website, Piwik, is that their website is still running WordPress 3.0.4.

Availability

A version of the extension is now available for Chrome. A version for Firefox is currently pending a review from Mozilla. The Firefox version has some limitations in comparison to the Chrome version due to current limitations of the Mozilla Add-On SDK, as the Add-on SDK is further developed those limitations will also go away. A version for Safari will not be released until Apple modernizes their enrollment process for Safari Extension development.

You can also find a web-based version of the tool here.

Is Running Outdated Software Always a Security Concern?

Outdated software is not automatically less secure than a newer version, it would only be more insecure if it contains a security vulnerability that does not exist in a newer version. Often new releases include fixes for security vulnerabilities or security enhancements. There is also a possibility that changes have been made in a newer version that removed a security vulnerability that was not known to be security vulnerability at the time. To be safe it is a good rule to update the software even if the developers have not warned of vulnerabilities in prior versions. To keep things simple we have decided that the extension will warn if outdated version is running instead providing a warning only when we know an old version contains a security vulnerability.

Is Including a Meta Generator a Security Concern?

With software that includes a meta generator tag there are often people claiming that it makes websites less secure, this is especially true when it comes to WordPress. We previously discussed the issue in detail in regards to WordPress. The summary of that is as follows: The bad guys are not generally checking the meta generator tag and they usually don’t even check if you are running the software they are trying to exploit. On a daily basic there are attempts to exploit software that is not and has never been on our website. Because the bad guys attempting to exploit vulnerabilities do not bother to check what version of software you are running the website, you will get hacked if you are running a version with that vulnerability even if you managed to completely hide the version running. Finally, if someone wanted to find out what version you are running they could do that even if you remove the meta generator tag.

With our new extension we think it makes even more sense to include a meta generator tag as it increases the usefulness of the tag by letting people inform others they have outdated software running on their website that needs to be updated.

Increased PHP Requirement for WordPress 3.2 Not a Major Issue

With the release of WordPress 3.2 coming up shortly (we are running the release client of it on our other blog without issue) the issue of its higher version requirements for PHP and MySQL have been coming up as a possible issue. One comment that we noticed was from a self-proclaimed security researcher was making the point this would lead to more outdated WordPress installations because servers are still running versions PHP below 5.2.4, which is the new required version, will not be able to be upgraded. On that point we have actual data on what version of PHP is running on servers and, more importantly, information on why an actual security researcher would see a much bigger issue with people still running a version of PHP below 5.2.4 than not being able to upgrade WordPress.

For every client that we need access to their website’s filesystem during our work we check the PHP version as well as other software running on the server (you can check your host using a tool we have created). For hosts having particularly outdated versions of software we alert the client to the issue and we also document some cases on our page detailing hosts with security issues. Our clients host websites around the world and with host provider of all sizes so the data should be a good representation of what is exists overall. We reviewed our data for this year and we found that none of our clients had been running a version of PHP 5 below 5.2.4, the lowest we found was 5.2.6. We did have some clients that were still running PHP 4, in all those cases we were able to switch them to PHP 5, above version 5.2.4, through the host’s control panel without issue. If you are still running PHP 4 you should make the switch as soon as possible as support for PHP 4 ended on December 31, 2007 and updates for critical security issues ended on August 8, 2008.

If there are still people on hosts that are only running a version of PHP less than 5.2.4 they probably have much bigger security issue than not being able to upgrade WordPress. PHP 5.2.4 was released on August 31, 2007 and last version PHP 4 was released on August 7, 2008. So that means their host has not bothered to upgrade one of the core pieces of software on their servers for nearly three or four years. While PHP itself is not a common target of hackers other server software is. Keep software running on the servers is the most basic security measures a host should be taking, if the host is not doing that then there is good chance that are not taking care of other security measures. There are many hosts that do take the basic security measures of keeping the server software up to date, so no one should be using a host that isn’t.

We would expect that a security researcher would know that you need to keep server software up to date and that PHP 5.2.4 itself is very outdated before making the statement they did. The fact that somebody claiming to be a security researcher doesn’t know this is a great example of why website security is in such a bad place. There are many people that are involved in website security that don’t’ know even the basics, but that doesn’t seem to stop them from telling others what they should be doing. If an actual security researcher were to complain about this, you would expect them to be suggesting that WordPress and other web software raise the required PHP version even higher. There have been numerous security fixes included in versions of PHP since version 5.2.4 was released and support for PHP 5.2 ended in December of last year. PHP 5.3 includes major changes that can cause software to break so many host are holding back switching to until more software is available with a version that supports PHP 5.3, but there is no reason they could not be running the last version of 5.2, 5.2.17. 5.2.17 was released over six months ago.

WordPress 3.2 also requires at least MySQL 5. None of our clients were running something below that this year. Support for the version below that, 4.1, ended on December 31, 2009.

How the basicpills.com Spam Links are Getting Into Websites

There has recently been a lot of discussion about a hack that added spam links, primarily to basicpills.com, into the databases of WordPress based websites. These spam links are then included in some of the pages generated by WordPress in the website. What we have not seen explained so far is how the hack has been occurring. Determining the source is essential to cleaning up the website, otherwise you leave the website vulnerable to being rehacked. If we had cleaned up a website with the issue we would have worked on determining that for our client and we would expect that any companies cleaning up websites would have done the same but unfortunately they often don’t.

So far we have not had any clients with the issue, but several days ago we did clean up a website that appears to have been used to place those spam links into websites at a different web host. Among the files we found a file containing a listing of the database host, database username, database login, database name, database prefix, and the addresses for quite a few WordPress based websites. We contacted the host to alert them to what we had found and to inquire into the source of the issue.

What we have been told is the web server itself had been exploited and not individual websites, they are still in the process of determining what exactly allowed this exploit. So the issue is not caused by an issue with WordPress or an individual user’s computer. Once the web server is exploited it is possible to read the wp-config.php file, which stores the database information that WordPress uses, in user’s accounts and access their databases to add the spam links. Because the web server is exploited the file permissions of wp-config.php do not have an effect on whether it can be read or not.

If have been dealing with this issue let your host know that the server has been exploited. If they refuse to acknowledge they have an issue and fix it, it is time to find a new host. If you looking for a new host, we provide some information on what ask a hosting provider to determine if they handle security properly here and a list of providers we have found to have security issues here.

If any hosting provider would like to see about sharing information on the issue with the host we have been in contact with, please contact us and we will pass along their information.

Hiding the WordPress Version Number Will Not Make Your Website More Secure

One of the most mentioned measures that is supposed to make a WordPress installation more secure is hiding the WordPress version number, but the truth is that it will not make your installation any more secure. If it has any effect, this measure is making WordPress installations less secure. The idea certainly sounds good if you don’t have an understanding of what the actual threats are and the methods someone could use to determine what version is being used. The biggest thing to understand is that hackers are not checking what version of WordPress is being run when trying to hack a website. In fact in most cases they don’t even check if WordPress is installed, they just try to exploit known vulnerabilities in older version of WordPress at locations that WordPress might be installed (they also attempt to exploit other software that might be located on a website as well). So no matter how hard you try to hide the WordPress version number, you will still get hacked if you are running an outdated version of WordPress. This is why keeping WordPress updated is the only measure you really need to do to keep WordPress secure.

If the WordPress version number is hidden someone who wants to check what WordPress version is running, as we often do with for potential clients or we are alerting websites we have found to have been hacked, will not be able easily determine what version is running and therefore not be able to give the webmaster a reminder that they need to upgrade it.

Furthermore, these attempts to hide version number would not be successful in preventing some who wants to determine the WordPress version number from actually doing it. There are multiple ways to check pages and files to determine the version is running and we have listed a number of them below. Someone who really wanted to know the version could also use the more advanced method of testing capabilities to determine the version as well. So if there was a real risk that came from the WordPress version number being known the attempts to hide the version would fail to protect the website.

Meta Generator Tag

The most well known way of checking what version of WordPress is being used is to check generator that is included in the source code of the website’s pages:

<meta name=”generator” content=”WordPress 3.1″ />

There are multiple methods of removing this from the pages.

Readme.html File

The other well known method is to check readme.html file that is placed in the root directory of the WordPress installation. From our experience this is not always reliable for determining what version is running as people don’t always copy the new readme.html when the perform an upgrade. So this could only be relied on to tell that the website is only running at least a certain version of WordPress. This can be removed by just deleting the files, but it will need to be done each time if you use the automatic update feature.

RSS/Atom Generator Element

If the website provides a RSS or Atom feed generated by WordPress it will include a generator element similar to the one placed on the website’s pages:

<generator>http://wordpress.org/?v=3.1</generator>

Like the generator tag this can removed, but we have found that this occurs much less often.

Login Page CSS File

The next two methods will only allow the major version of the WordPress to be determined. That is they could tell if you are running 3.0 or 3.1, but not it you were running 3.0.1, 3.0.2, 3.0.4, or 3.0.5. This information would be enough to narrow down the possible vulnerabilities that the hacker could use making the task of finding one they could use much simpler.

In the source code of the WordPress login page a version number is attached to the login.css style sheet:

<link rel=’stylesheet’ href=’http://localhost/wordpress/wp-admin/css/login.css?ver=20081210′ type=’text/css’ media=’all’ />

These are version numbers for the last five major releases:
2.7: 20081210
2.8: 20090514
2.9: 20091010
3.0: 20100601
3.1: 20110121

Limiting access to the wp-login.php could prevent this from being checked.

New Files

The final method involves checking for a file that has been added to a given version. These are files that were introduced in the latest version for the last five major releases:
2.7: /wp-includes/js/comment-reply.js
2.8: /wp-includes/js/autosave.dev.js
2.9: /wp-includes/js/json2.dev.js
3.0: /wp-includes/js/wp-list-revisions.dev.js
3.1: /wp-includes/js/admin-bar.dev.js

It impossible to have a file that has not yet been created already on your website and blocking access to these files is not something that you could realistically do, so this is something that could not be prevented from being able to be used to determine the version.

If you see someone promoting hiding the WordPress version number as a security measure we would appreciate if you point them to this post to help stop it from being promoted.

WordPress 3.0.2 Fixes SQL Injection Vulnerability

WordPress 3.0.2, which was released yesterday, fixes a SQL injection vulnerability that would allow Author-level and above users to view any information stored in the WordPress database. This could be used to view email address, hashed passwords, and other sensitive information stored in the database. WordPress rates this vulnerability as a moderate security issue. The vulnerability existed due to the fact that the “do_trackbacks() function in wp-includes/comment.php does not properly escape the input that comes from the user”. According to Vladimir Kolesnikov, who discovered it, the vulnerability seems to have existed since WordPress 2.x. Further details of the vulnerability can be found in Vladimir’s blog post.

The new version also includes fixes for several minor cross-site scripting (XSS) vulnerabilities and a number of bug fixes.

Websense Threat Report Repeats False Claims of WordPress Hackings

In Websense’s 2010 Threat Report they listed WordPress Attacks as on of the significant events of the year. They also claimed that WordPress “was hacked numerous times in 2010”. While its true that some outdated WordPress installations were hacked during the year (as they and other web software have been for years), the hacks that they refer to in their report, which were much larger than any actual hacks of WordPress, were not hacks of WordPress at all. The hacks they refer to were actually hacks that targeted hosting providers that would allow malicious code to be added to websites hosted with the provider whether they were running WordPress, other software, or no software at all.

In most of the hacks the malicious code was placed in all files that had a .php extension. WordPress, by the nature of being the most popular web software, was the most of often affected, but all web software that have files with a .php extension were also affected. In other cases the hacks targeted database fields specific to WordPress, but they could have affected any other software that utilized a database if the hacker had chose to target them instead of WordPress.

Websense is not alone is making these false claims, other supposed security experts also made similar claims and some hosting provider have attempted to lame blame on WordPress. Network Solutions was the only one to later apologize for blaming WordPress.

Websense also claimed that “numerous vulnerabilities were known to exist during the height of the attacks”. Seeing as WordPress was not hacked as claimed, the claimed numerous vulnerabilities also don’t exist. In fact during the year the only security vulnerability that required the release of a new version of WordPress was one that allowed “logged in users can peek at trashed posts belonging to other authors”. This vulnerability would not have allowed the WordPress installation to have been hacked.

Making false claims about WordPress’s security damages WordPress reputation without improving security. In fact it may have the effect of decreasing security, as it may lead to people to use software that does not focus on security as well as WordPress does. WordPress responds quickly to security issues, automatically informs users of upgrade within their software, and makes it relatively easy to upgrade the software as well. By comparison two web software apps that have actually had major hackings in 2010 have not responded properly, osCommerce has chosen not release a patch for their security vulnerabilities and OpenX has recommend a fix for a vulnerablility that actually causes future upgrades to fail.

The One Fairly Simple Step To Keep WordPress Secure

We have seen many guides that list many steps that are claimed that you need to take to secure WordPress. There are also companies out there that will charge hundreds of dollars to secure your WordPress installation. But the truth is that there is only one fairly simple step to secure WordPress, keep WordPress and any installed plugins updated. The developers of WordPress agree with us, in blog post about keeping WordPress secure they said:

There is only one real solution. The only thing that I can promise will keep your blog secure today and in the future is upgrading.

The upgrade process involves making a backup of the websites files and database, disabling plugins, and then performing the update of the WordPress installation. WordPress provides a helpful guide that detail the process. If you are currently running version 2.7 or above, WordPress includes an Automatic Update feature that takes care of the updating part of the upgrade for you. If you are running version 2.6.5 or below, you made need to make one or more incremental upgrades to avoid potential issues. If you need help upgrading, especially if you are currently running a very outdated version, we can perform the upgrade of WordPress for you.

Will This Protect You From All Hackings?

The simple answer is no. Many hackings occur because of the FTP credentials for the website have been compromised or through a hosting provider being hacked. Nothing you do to WordPress installation will prevent these from happening because they do not take advantage of a vulnerability in WordPress. You can find our suggestion on the steps the steps you need to take to prevent those types of hackings here.

WordPress 2.9 Released

Version 2.9 of WordPress was released on Saturday. The new version includes a trash feature, a built-in image editor, plugin compatibility checking, and support for the embedding content using the oEmbed standard. With trash feature posts and comments that are deleted will be placed in a trash folder instead being completely deleted. The image editor allows images to be cropped, edited, rotated, flipped, and scaled and the post announcing the new version indicated that this is the first of “many planned media-handling improvements”. To help the users planning to upgrade to newer versions, WordPress will now present data compiled from other users as to whether installed plugins are compatible with the new version. Support for oEmbed standard allows for embedding of images, video, and other content by pasting an URL into a post. The standard is supported by YouTube, Flickr, Hulu, Scribd, PollDaddy and other websites.

The new version requires that your server run MySQL 4.1.2 or higher, previously versions only required 4.0 or higher. WordPress will check if the server has a supported version of MySQL during the auto upgrade process.

A full lists of changes in 2.8 is available at the WordPress Codex.

WordPress 2.8.5 Improves Security

WordPress 2.8.5 was released yesterday, which includes a fix for a denial-of-service (DoS) attack and a number of changes that removed code that could potentially be used to hack into WordPress. The denial-of-service attack utilizes specially crafted trackbacks that cause WordPress to use a significant amount of processing power when they are processed which could lead WordPress becoming unresponsive. The code removal changes were originally developed for the upcoming version 2.9 and were backported to improve security as soon as possible.

WordPress 2.8.2 Patches Security Vulnerability

Following less than two weeks after the release WordPress 2.8.1, which fixed a potentially serious security vulnerability, a new version has been released to patch another potentially serious security vulnerability. In versions before 2.8.2, comment author URLs were not fully sanitized which could lead to a cross-site scripting (XSS) attack. When viewing a page in the administrative interface that contains a specifically crafted comment author URL the user would be automatically redirected to another web page. That other web page could try to infect the user’s machine with malware or try to perform some other harmful activity.