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.

Why That Trustmark Doesn’t Mean a Website is Actually Secure

Three weeks ago it was disclosed that McAfee’s website contained numerous security vulnerabilities. What make this disclosure significant is that at the time the website was found vulnerable, the McAfee Secure service, which scans websites for security issues, was certifying that the website was secure and McAfee’s website contained a trustmark from McAfee Secure letting visitors know this. This claim was obviously not true at the time. This situation underscores the fact that the McAfee Secure service and other companies security scanning services, as well as the trustmarks they provide to websites, cannot be trusted to identify if a website is secure. This is because scanners can only actually determine is that the website does not contain specific security issues that the maker of the scanner knows about and is testing for. If, as in the case of McAfee’s website, they do not know about the specific security issue they would never detect it and the trustmark would still claim the website is secure.

In the case of McAfee they don’t even seem to be very focused on the security that their scanner is supposed to provide. On the web page for McAfee Secure, the emphasize is placed not on any increased security the product provides but on claims that having their trustmark on the website will increase sales for the website.

While those scanners limitation in only being albe to detect known security issues is a big issue there is also a much bigger problem with these scanners, they scan the website from the outside. This is often touted as a feature, but it is a major weakness of the services. What it means is that anything that is not accessible from the outside cannot be scanned, so even if a scanner could detect all possibilities security issues that are detectable from the outside the website can still be insecure. Here are a couple of real world examples we have dealt with where these scanners failed in this way:

We were contacted about a website in which files on the website were having spam links added to them repeatedly. The client had run two of these scanners and they hadn’t found the security issue allowing this to happen. After discussing the situation with them we were able to assist them in finding a backdoor script which was allowing this to occur. A backdoor script allows a hacker remote access to the website. In their simplest form they execute code sent to them. More advanced ones provide a variety of tools and the ability to view the websites files. It is almost impossible for one these scanners to detect a backdoor script. The backdoor script can be given a random name and placed anywhere in a website. So the scanner would need to scan a nearly unlimited number of URLs to be able to request the backdoor script. Depending on the backdoor script, they might also need to request the backdoor script in a certain way for it to be possible to detect that it is a backdoor that is at the location. Needless to say, these scanners do not attempt this.

In a more serious situation we had a client where credit card information entered on their website was being transmitted to someone who was using it to attempt to make fraudulent purchases. They had run it through one these scanners without it finding any issues. What we found was that a hacker had placed some code into the file that handled credit card input, which transmitted the information to another website. The web page were you inputted the credit card information was exactly the same as it would be without the code, so it is impossible for a scanner to detect this type of thing.

For webmasters who utilize widely used software like WordPress, Joomla, Drupal, etc., the software will have already been run through these security scanners, so as long you keep the software updated the scanners are of little use. If you use custom written software you’re much better off having someone who is a familiar with handling security in programming language the website is written in review your website. They might use one these  security scanners as part of their process in addition to other methods. They would also be able to correct the insecure code, which something that is going to need to done if the scanner identifies anything anyway.

What TVCNet/hackrepair.com Doesn’t Want You to Be Able to Read

Back in March we wrote a post about the danger of unethical hack repair services. This is certainly not the only area that we deal in where there is unethical behavior. On a fairly regular basis we are contacted about issues from companies that are being paid to maintain websites despite not knowing what they need to do maintain the websites and not having the ability to perform that maintenance even if they knew what it was.

In that post we discussed a company called TVCNet, which also does business as hackrepair.com, thehackrepairguy.com, and “The Hack Repair Guy”. We were stunned by a recent interaction with them and felt it was important to write about what happened so that public at large could be aware as well. Here is what we wrote about them in that post:

What we haven’t dealt with before is a company that offers to clean up hacked websites contact us and admit that they were unable to determine how a website was hacked and wanted us to do it for them. Then last week we were contacted by a representative from TVCNet, which also advertises their service at hackrepair.com. They told us that they were good at removing the hack code, but a website they cleaned was being reinfected and they couldn’t determine what was allowing the website to be reinfected. The infection that they describe was one that should have been very easy to determine the source of if they had even very modest experience dealing with cleaning up after hacks. It certainly should not have been a problem for someone that is charging clients 350 dollars to clean up a hacked website (they apparently charge extra to upgrade software, even though that is often essential for securing a website).

With a company operating in what we consider an unethical manner, it is not a surprise that they are also lying about their service. They claim that they “We will work direct with Google staff, and ensure your web site is unblocked by Google”. The truth is getting unblocked by Google is a completely automated process that doesn’t involve working directly with Google staff.

On Monday, they left a comment on our blog that sidestepped the substance of post, it appeared that may not have even bothered to read the post, while making a number of accusations against us (we moderate comments so you won’t see it). We sent them an email letting them know we would not be posting the comment and informing them that we would post a correction if there was a factual mistake in the post.  We are always happy to post a correction if there is a factual mistake in one of our post, that is mentioned in the “Did We Make a Mistake?”section of this blog’s sidebar.

The next day we received an email from them that claimed the post was inaccurate, but did not dispute any of the facts present in the article. What they did instead was to falsely accuse us of slander. It is impossible for our written post to have been slanderous, but it is also was not any other form of defamation either. Defamation requires, among other things, that a statement of fact be false. We stand behind the facts in that article as well as the opinions presented. They so far have also not disputed any of the facts present in the post.

In both instances they requested we remove the post. In the second instances they tied the request to their false accusation of slander, with the implicit implication of bringing that up that an illegal act had occurred and that there could be legal remedies. We won’t be doing that as it is important for the public to know of the danger of unethical hack repair services, especially if companies don’t want you to know about it.

There most recent response also raised other troubling issues. In the email they claim to have had to spend over 40 hours clearing up the hack in question. We have never spent anywhere that much time clearing up after hack and the hack in this case was particular simple so it should not have taken that long. To us, that seems to be an indication that something is really wrong with their capabilities or process. That further backs up our opinion that they operate in unethical manner by providing a service that do not have the necessary experience to do properly.

That response also indicated that they had moved that hacked clients to their hosting service. We strongly believe that hack repair providers should not involved in any way in with moving users to a hosting provider they have a financial relationship with, especially one that has had security issues within the recent past. In a post last year it was disclosed that TVCNet’s servers come “with the standard formmail.cgi  XSS and cgiecho  information disclosure vulnerabilities”. That post also claims that “you can bet they spin more than their fair share of BS.” So we are not the only people that have concerns about this company.

Before publishing this post, we will be offering not publish it as long as TVCNet agrees to stop trying to intimidate us into suppressing our previous posting about the danger of unethical hack repair services and stop making potentially defamatory statements about us. We hope they take up the offer and stop making a bad situation of their own making worse. If this is posted, it means that they continue to want the public not be able read this important information.

Update (April 22, 2011): Since this post was published the situation has taken an odd and disturbing turn. Employee(s) of TVCNet have become rather obsessed with our company and our employees. They have been posting bizarre, incoherent rants about us, as well as posting personal information about employees, across the Internet. At the same time they have not informed us of any actual factual mistakes in our original post, which if they actually existed we would happily post a correction for. What is occurring is certainly not something that a reputable company would be doing and unfortunately seems to be an indication that the employee(s) of the company may have mental health issues, if that is the case we certainly hope that they will get help for those issues.

Understanding the Role of File Permissions in Website Security

Often in discussions of website security or hackings the issue of file permissions comes up. Unfortunately, important information needed to understand what effect permissions have is often not explained and in many cases bad information is spread. Most of the bad information relates to limiting other’s access to the files in your account on a shared server.

First let’s explain the basics of what file permissions are made of. In Unix based operating systems, which is what most web servers are running on, file permissions are composed three type of permissions: read, write, and execute. The read permissions allow reading the file, the write permissions allows modifying the file, and the execute permissions allow a file to run (because of how PHP works .php files do not need to be executed to run).

Directories also have the same types of permissions, but they are somewhat different. The read permissions allows see a listing of the files in the directory, the write permission allows creating, deleting, or renaming files in the directory, and the execute permissions allows accessing the files in the directory.

Those types of permissions are set for three different classes: the owner, group, and others. The owner is normally the user that created the file, the group is whatever groups the owner is part of, and other involves any other users on the system.

The first important thing to understand in terms of security is how the files can be accessed in the first place, because for permissions to come into play the hacker first has to be able to access the files. This requires having login access to the server, a FTP login for example, or having found some exploit in software running on the server. Just by browsing the website they could not access the files. If the hackers gains login access to your account or exploits software on your website they will have the same access that you have, so restricting others access will have stop someone from accessing your files in those cases.

We sometimes see it suggested that to protect a website that is being repeatedly hacked in a way that modifies files, that the write permissions for the files should be removed. The idea is that because the write permissions are disabled the hacker would no longer be able to modify the files. The problem is that most instances the hacker would have the ability to change the permission so that the files are writeable again. For almost as long as we have been seeing it be advised to make the files unwriteable we have been seeing hacks in which the permissions set to be writeable during the hack, so this is not effective strategy. What needs to be done is determine how the hacker is gaining access to the files and stop that.

The most important thing to understand about file permissions is that on a shared server, no matter what the file permissions are set to other users should not have access to your files. One of the developers of WordPress put it this way:

A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.

If your hosting provider does not have proper access controls in place the need to add those or your need to find a new host.

While setting permissions as low as possible is not going to do any harm, in most cases where the file permissions are blamed it would not have mattered what the permissions were set as. This is due the fact the files were being accessed in way that file permissions would not have restricted access. For example, a recent hack involved exploiting the web server instead of individual websites. Once the hacker gained access to the server they had access to all of the files on the server.

The Danger of Unethical Website Hack Repair Services

We have long noticed companies that are offering to fix hacked website appear to lack an understanding of what that actually entails them doing for clients. What they often fail to understand or simply don’t care about is that simply removing the hack is not enough. You have to determine how the website was hacked and make sure that has been fixed or it is likely to be hacked again. We strongly believe that doing otherwise is highly unethical, as it exposes the website and it’s visitors to the potential of infection or data exposure. It also seems to us to be a rip-off as your paying someone for cleaning up an issue that could quickly return. We are often hired to clean up websites that someone attempted to clean up before but were not properly secured after they were hacked

Determining how a website was hacked and properly securing is much harder than just removing the hack. It requires a general understanding of the technology underlying websites, a knowledge of the software that is being used on a website, how hackers operate, prior experience, among other things. There are some situations where we could easily remove the hack from a website but we know that we don’t have relevant expertise to properly secure the website, in those cases we provide the potential client with the information on what needs to be done to secure the website for free.

What we haven’t dealt with before is a company that offers to clean up hacked websites contact us and admit that they were unable to determine how a website was hacked and wanted us to do it for them. Then last week we were contacted by a representative from TVCNet, which also advertises their service at hackrepair.com. They told us that they were good at removing the hack code, but a website they cleaned was being reinfected and they couldn’t determine what was allowing the website to be reinfected. The infection that they describe was one that should have been very easy to determine the source of if they had even very modest experience dealing with cleaning up after hacks. It certainly should not have been a problem for someone that is charging clients 350 dollars to clean up a hacked website (they apparently charge extra to upgrade software, even though that is often essential for securing a website).

With a company operating in what we consider an unethical manner, it is not a surprise that they are also lying about their service. They claim that “We will work direct with Google staff, and ensure your web site is unblocked by Google”. The truth is getting unblocked by Google is a completely automated process that doesn’t involve working directly with Google staff.

Unfortunately, there does not seem to be anything that we can do to stop this type of practice. If other companies contact us we can certainly highlight there unethical practices as well, but that won’t stop them or others from continuing these unethical practices. What we can do and have done for some time is to get accurate information out there on cleaning up after hacks so that those companies have a better chance of properly cleaning websites. From our analytics data it’s clear that many companies that might be dealing with those hacks have been accessing that information. Others also provide this type of information, but unfortunately we often find the information being put is inaccurate. We also have created a tool to detect popular backdoor scripts, which should help to prevent some hacked website from being reinfected as it would of in this situation. We also provide information on how to properly secure websites, which we run advertising to promote, so that websites don’t get hacked to begin with and then have to deal with these companies.

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.