The past few months we’ve been spending a good deal of time talking about backups. This is for good reason, they are often your safety net e nen things go wrong; interestingly enough though, they are often the forgotten pillar of security. It’s why we spent some time thinking through what a good backup strategy might look like. As in most things however, we have to give real-world examples to help illustrate not only the value of backups, but also the potential threats they pose.
In our strategy discussion, you might recall our emphasis on the location of your backups. As described, the act of having a backup is great, but having it on the same server, worse yet, in the same web directory, can be devastating.
An example of this is in the 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 in many instances it’s not.
You might be thinking, “But my database backups are not linked anywhere on my website.”
Search engines though, 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.