For the past few months, we’ve spent a good deal of time talking about backups. This is for good reason: backups are your safety net when things go wrong. Interestingly enough though, they are often the forgotten pillar of security.
We spent some time thinking through what a good backup strategy might look like along with some real-world examples to help illustrate not only the value of backups, but the potential threats they pose as well.
In our strategy discussion, you might recall our emphasis on the location of your backups. The act of having a backup is great, but having it on the same server (or worse yet) in the same web directory can be devastating.
An example of this is in database backups. The database backup does not just contain your posts, pages and comments; it holds something so much more valuable – think usernames and passwords.
Websites Hacked Via Website Backups
How ironic to think that the thing that is designed to be your safety net can also be used against you. Such is the tale with Website Backups when employed incorrectly. We want to focus specifically one type of backup, those of your database.
Most website owners believe that your information on the website server itself is safe from prying eyes, and in most instances that’s true, but sometimes it’s not.
You might be thinking, “But my database backups aren’t linked anywhere on my website.”
Search engines are still able to index a web directory via a process known as Directory Indexing. Directory indexing occurs when a normal base file is missing (i.e., index.html / home.html/default.htm/default.aspx, etc..).
If one of these files are not present, the web server will issue a directory listing, which in turn causes them to be indexed via search engines. Those directories might have a treasure throve of content that isn’t meant for public consumption; information you might not want indexed.
There are a number of things that Directory Listing can lead to, they include some of the following:
- Backup Files
- Temporary Files
- Hidden Files
- Naming Conventions
- Enumerate User Accounts
- Configuration File Contents
- Script Contents
A good example can be seen using a carefully crafted Google search. We were able to find the following database backups being indexed by Google:
If a user were to download these files, they’d be able to find information like user information, hashed passwords and a number of emails in plain text (great for spamming and new phishing lures):
Cracking Hashed Database Passwords
The first anticipated argument is the fact that the passwords are hashed. That’s true, they are.
However, the art of password cracking has evolved greatly over the years. What makes it more convenient for the attacker is that they do not have to expend much energy attacking a website directly, they are able to download the files locally and perform a series of Brute Force techniques to reveal the password. All that is needed is the right brute-force software; yes, there are a wide range of tools freely available that the attacker configure and deploy daily.
The worst part is, you won’t even know you’ve been,, or are under attack; until it’s too late.
The discussion of password cracking is not new, it’s been going around for years. Joseph Bonneau wrote back in 2013:
Password cracking can be evaluated on two nearly independent axes: power (the ability to check a large number of guesses quickly and cheaply using optimized software, GPUs, FPGAs, and so on) and efficiency (the ability to generate large lists of candidate passwords accurately ranked by real-world likelihood using sophisticated models). It’s relatively simple to measure cracking power in units of hashes evaluated per second or hashes per second per unit cost.
To put this into context, Jeremi Gosney, Founder & CEO, Stricture Consulting Group (an organization that cracks passwords for a living), was able to crack 14,734 of 16,449 MD5-hashed passwords in 20 hours, using a common computer with a single AMD Radeon 7970 graphics card.
That’s over 90% of the passwords on the list. The experiment was conducted by Ars Technica in response to a previous test conducted by one of their reporters, Nate Anderson, who was able to decipher close to half of the same 16,000 cryptographically hashed passwords that Jeremi worked on. All done with no experience in the art of password cracking.
Granted, this example is specific against an MD5 hash.
Most cryptographers out there will laugh that it’s employed, and as such the passwords deserve to be revealed. No arguments there! It’s also why some of the more modern CMS applications, including WordPress and Joomla!, leverage some salt+md5 hashing configuration. Unfortunately, that’s of little comfort as the technology has evolved and tools like HashCat have hit the market making the cracking of those passwords that much easier to crack.
Hardening Server Directories
The emphasis on the art of cracking is important to help drive the point home on the importance of your backups. They contain information that is critical to your website, and most likely your online brand and business.
It’s why we place so much emphasis on a good policy for passwords, and always recommend randomly generating them, retaining a good length (greater than 20) and the use of a password manager. All this is moot however if the attackers can get access to the hashes themselves (via your database backup).
If you must store the backups on the same server/account as your website we recommend placing them outside the public web directory. Please, also make sure they are not accessible from the outside.
You can also add additional rules to the .htaccess file inside the backup directory to further harden it:
# Block Directory Listing
Options -Indexes
This will only work if your web server is configured to allowed server overrides. If on a shared host, be sure to ask your host for guidance.This configuration is only for those on Apache web servers.
If you’re using NGINX, another very popular web server, the directory listing option is disabled by default.
Windows IIS however, is similar to Apache, in that it’s set to enabled by default, so to disable directory listing you’ll want open the command line on your web server and use the following:
appcmd set config /section:directoryBrowse /enabled:false
Don’t Underestimate the Value of Your Backups
Backups are a critical piece of your overall security posture, be sure to have them. Having a backup however is just the first step, you must have a good approach to creating them and more importantly storing them.
There is no greater example than the impacts if your database backups were to get into the wrong hands. Database backups contain secret / sensitive information about your users; things like their email addresses, and passwords to name a few (varies on what you collect), and wide range of other data. In the wrong hands, this information can be used to wipe out your website, worse yet, attack your users. We’ve illustrated the processes employed by today’s attackers to crack passwords in an effort to demonstrate its impacts. When a hacker gains access to your information, there is no telling what will happen next.
Make sure that you keep your website backups in a secure location. If you don’t have such a configuration and you’re a client, we highly recommend looking into the Sucuri backup service.
Kayleigh Martin
Luke Leal
Rianna MacLeod
Victor Santoyo
Cesar Anjos
Ben Martin
Krasimir Konov
10 comments
Or, forget about backup plugins and backup to another server (which you should be doing anyway) using a secure and efficient program. I use linux and rsync over an ssh tunnel. I set up the backup daily using a cron job. rsync is one of the best bash utilities ever written imho and is very fast as it only updates files that have changed.
It would have been helpful to point out that a decent backup plugin will already take care of this.
UpdraftPlus, for example (of which I am the lead developer), both adds an .htaccess file (and the IIS equivalent), and adds an index.html file so that there’s no possibility of a directory listing. (And it also recommends storing your backups off-site, e.g. in Dropbox, and can automate that).
It also has an optional facility for encrypting your database backup, so that even if you did leave it lying around somewhere, its contents are unreadable without the encryption key.
I think it’d have been handy to discuss some of these things, as the piece as-is sounds rather alarmist – many readers may wonder if being vulnerable in the way that the article describes is the normal situation, or not.
HI David
It is normal, which is why we wrote about it. The features of your product sound great, but they are not the norm unfortunately.
The point was also not to talk to any plugins, extensions, modules or anything else in between. It was designed to speak to an issue we see; regardless of technology being employed.
Thanks for stopping by though.
Tony
Hi Tony,
You’ve said that it is not “the norm” for backups to be protected from index listing. On what grounds are you saying this? All the major backup plugins I am familiar with – ours and our competitors – do protect from index listing. And AFAIK, the vast majority of people backing up their WP websites are doing so using either plugins, or cPanel backups (because most users would lack the technical skills to do it any other way). So I’m interested to know why you say that unprotected backups are “the norm”.
Even if you’re not talking about any particular technology, I think it’d be helpful if the article avoided – unintentionally, from what you say – unnecessarily alarming users. You’ll notice that the first comment on the article, before mine, interpreted you to be saying that backup plugins have a general problem too – Vic Hardy suggested as a solution, “Or, forget about backup plugins and … (other solution)” – he’s understood from your article that you’re talking about backup plugins.
If common WP backup “plugins, extensions, modules”, as you say, are as “the norm” causing this problem, then wouldn’t the best thing for your guys, whose work I think is usually really good, to do, be to issue security advisories and to co-operate with the vendors of the products? I agree that this can be a real problem, is a serious one, and needs fixing – but I think the article is causing problems as well as helping, because as written it gives the idea that most people will have this problem and therefore (by implication) that most backup plugins have a security hole in them.
David
He wasn’t talking about plugins, as he clearly stated – plugins are not “the norm”. The norm is manually creating a backup by going to SQL and typing a command to dump the contents of a database into a file. Your comment is helpful in suggesting a plugin that will automatically generate access controls, but in no world is that the “default” or “the norm” – new web developers should be aware of the PROBLEM, so that they can individually look into solutions.
Get’em David. UpdraftPlus 4 Life!
That is a very good post about WordPress security! I’m surprised as well as worried about the backups and how hackers can exploit them!
I have a dedicated Serve (Apache, WHM) and for each of my clients a separate CPanel-Account. On January 2015 there were 5 of my 20 websites hacked 4 od the same person and 1 of an other hacker. Could it be that someone through the wordpress login can hack other websites on the server (different account with different secure passwords). All sites were hacked within 10 minutes.
What do you think?
i recommend 2 ways for avoid this danger:
1. insert backup out of public_html
2. encrypt backup file (with AES)
note that the second method also is necessary if you want to save backup on another server.
>> If you must store the backups on the same server/account as your website we recommend placing them outside the public web directory. Please, also make sure they are not accessible from the outside.
I use BackupBuddy. BackupBuddy currently places backups in /home/user/public_html/wp-content/uploads/backupbuddy_backups/ and everything is 755. We *can* change this default location to a location above root, but what are your suggestions for permissions for moving the backups to a directory above root / ? If we move the backups to /home/user/backupbuddy_backups/ can we safely set the backupbuddy_backups directory to 755 in order to keep BackupBuddy happy?
Comments are closed.