You probably wouldn’t have heard of this, but there is a well-known hack that can be used to read config files from other people’s accounts. Not only is it being used actively by hackers at the moment, it’s been used to hack hundreds of thousands of web and email hosting accounts worldwide, and the amount is growing daily.
Obviously, from a hosting point of view, this is a serious issue! However, much to our surprise, the rest of the industry has been very slow to cotton on to the ways of protecting users from this. The particular concern is that this works by hacking only one account on a server then escalating to hack most of the accounts on the same server.
Interestingly, some hosts have been hiding behind claims such as “the users should know, it’s well known”! What is surprising about this assertion is that this bug is actually fairly recent and information about it is actually not at all widespread amongst user and developer internet communities.
What does the bug do and how is it exploited? Normally I wouldn’t explain this in any detail, but since information about this is really widely available at this point it’s probably interesting to describe how it is being done.
The first step is that the user works out a name of another account on the same server. They then create a Unix “symlink”, which is a link pointing to another file; in this case the link points to the WordPress wp-config.php file of the other user! However, they name the link “file.txt” and then visit it in the web browser. The victim’s webserver happily tells them the contents of this file, thinking that the file is a text file and thus safe to visit. However, the baddies can then grab the passwords from the config file and off they go.
Although WordPress is the most commonly exploited system with this bug (perhaps because it is simply the most commonly used CMS), all other CMS systems are vulnerable. The key is that the system has to have a configuration file with a known name, as they have to guess the name successfully for it to work.
This trick gives them access to the victim’s database access details, which in turn lets them view and alter everything in the database. If there are credit card transactions, they can be stolen. They can put viruses on the home page, and often do.
So – how does one defend against this?
There are two ways.
A simple Apache patch, published about 6 months ago in the cPanel forums, provides most of the protection against this. The patch prevents a user from using a symlink to view a file that is not owned by them. The patch is not 100% effective, as there is a way to work around (called a “race” condition for the techos out there), but it makes it so much harder to get past the protection that we expect that at this stage most people won’t bother trying to bypass it.
When we realized there was a way around the patch, we were concerned for obvious reasons. However, it turns out that simply altering the config file permissions to only allow the owner to read it, is sufficient to stop these hacking attacks – the file simply can’t be read through the link, even if the link is successfully created!
It turns out that PHP files are normally mode “644”. Changing them to mode “600” is sufficient to prevent the attack, and so this is what we do. Across our multiple thousands of accounts, there have been no user complaints or sites that have stopped working since we implemented a job to make permissions on all .php files secure.
Why it’s important to us to stop sites getting hacked
We are pioneers in the technology of keeping sites secure, and perhaps it goes without saying that this is very important to us.
At the end of the day, this is about running a service that is available and able to be used without interruption, and without hacking attacks on your account.
However, there’s also a larger picture here. Speaking as a sysadmin, One of the things we have to defend against is preventing the server being compromised at a root level (the “root” account allows universal access to all files on the server). Any experienced sysadmin will tell you that given enough shell time as a normal user on almost any *ix system, they can get to root. As a system owner, I don’t want them getting enough time to poke around my servers and maybe find the inevitable vulnerabilities or 0 days that are present. At the end of the day, once my system has been compromised, it costs us money, and inconveniences you as users significantly.
Some hosts take the “user beware” attitude!
It surprised me recently to find the owner of a large, well known and respected hosting company saying publicly that there was “no patch for this problem” and that “users should know to set their file permissions securely”. I found this an amazing attitude, as the information about a patch being available was there if they had looked, and there was little chance a user could have been informed as to file permissions. Still, their attitude is common amongst hosts, even if it is mostly unvoiced.
There’s no doubt that it’s true that at the end of the day, users do have to carry the responsibility for keeping the software they install on their account secure. While I’d love to be able to help with every security problem out there, the volume of open source software and security problems is so huge that we just can’t spend the time necessary to solve every problem.
However, what we CAN do is to do as much filtering as possible – to try to prevent common attacks from succeeding. We do this very successfully through a variety of filters, such as preventing many common attacks — as just one example, we are able to block most “SQL injection” attacks, a very common attack method.
Despite this, we’re noticing that the number of attacked accounts on our servers is growing steadily. There’s no doubt in my mind, as an industry watcher of many years, that the security problem is going to increase to the point that it will be hard to keep your site up if your host is not willing to take responsibility for doing what they can in this area.
Stay safe out there! And we’ll do our best to keep you that way.