Exploiting backup copies of settings
In case you haven't the time to read this whole post the TL;DR is -
never make backup copies of your settings and configuration files within your live publicly accessible web environment and protect all sensitive files routinely. - Someone is looking for them right now!
We have all done it at some point, a quick change in production to some settings in your CMS configuration, probably in a panic reacting to some ongoing issue, and made a temporary backup of wp-config or settings.php with a bak or similar extension. Tested the fix and then probably forgotten to remove the backup - no problem?
Big problem! - Putting the issues of such bad practice aside for a moment (fixing production directly and 'reacting' in this way), in this post I want to explore in greater depth why this is a serious issue, how it leads to compromised web sites, who is exploiting such scenarios and how to defend against them.
I have been meaning to write this post for ages having presented on the issue of web site security nd defence in depth at several developer conferences and camps.
It is a common issue and a regularly exploited attack vector - which means criminals actively seek out this vulnerability. More recently we have seen very active prospecting by malicious visitors and this prompted me to write this post to show in real terms that the risk is not theoretical but a real vulnerability.
First off let's remind ourselves why such files should be protected more than any others. Most CMSs have a settings file that contains the database user credentials and other sensitive information; that is how the web server software accesses the database.
There are lots of discussions around how best to secure these files including keeping them outside the web folder and other means. However the standard setup of most CMS systems is to place them within the web folder structure and recommend protecting them with limited access rights.
However the default out of the box setup does rely on users taking that additional step and protecting the files - most CMS will warn you when the rights are improperly set.
But they don't warn you when you create a backup version that may then be readily viewable by anyone using a browser.
Configuration errors in the wild
To see this in action see this image that shows a Drupal settings file that is readable.
That is clearly an incorrect configuration of the web server that rather than running the requested php file through the php interpretor is simply returning it as a text file to the requesting user.
That is a rare case and you would be aware of that if it happened as your site would not work at all.
More common is the case when the sensitive files are copied as a temporary backup and therefore become accessible to the public.
The core site configuration file (e.g. settings.php, wp-config.php) contains sensitive information about the database connection.
More often than not it is not kept in version control (due to it having sensitive information and being site specific) and this leads to cases where site developers make changes directly within the site file system.
If the changes made cause an error the developer has to hastily undo these changes to fix the site.
Preparing for this and make recovery quicker it is common for the developer to make a copy of the file renaming it settings.bak for example. This file can then quickly be restored if the changes need to be reverted.
That is clearly not good practice on many levels - but it is common - and often the file copy won't be cleaned up if the changes went well, and it will be left in the file system publicly available.
Also as it now has an extension other than .php it will not get passed through the php process but treated as a text file and available for viewing by anyone.
Such instances (found in the wild - as the images here show!) would make your site open to compromise if you allowed that. I have spoken about that many times in presentations and it might be seen by some as a theoretical risk - but it is really common
Over the past 24 hours we have seen a raft of live exploit attempts of precisely this across a wide range of sites on separate servers, prompting me to get around to finishing this post.
In this case the malicious agents trawl the web for variations of settings and config files that may be present. If found they would provide the attacker with access to the site database and other sensitive information.
Whilst non of the attempts we observed were successful due to a range of security measures, (some outlined below in addition to other measures at a lower level not covered here),
it is clear that they are likely to be successful elsewhere on more susceptible/vulnerable sites - it pays never to be complacent.
Real world exploits of visible settings files.
To see how this is exploited in the wild, the following shows a list of real files requested by a malicious visitor.
As you can see they enumerated a variety of plausible extensions and copies of the settings.php file.
In fact they were CMS savvy as they also repeated that same set for all possible variations of sites within a multisite configuration, using real domains accessible on the same IP (aliases - presumably sniffed from the secure certificate alternate names!)
So in the above set they replaced 'default' with another plausible multisite folder.
So as you can see, if any of those existed (which they didn't), they would be able to get access to DB credentials and other sensitive data.
It also worth mentioning that exactly the same goes for database dumps placed in the site root - another common error and attack vector!
In fact this current pattern of exploit, in addition to looking for backups of settings files, also sniffs out txt files and other sensitive files as can be seen below:
So how do we ensure that such files are not available and this type of malicious exploitation attempt doesn't ever succeed?
It isn't always possible to enforce good practice such as not making backup copies and leaving sensitive files in the file system, but you can protect against these and other common scenarios with a few standard good practices.
In the following examples I will show how you can configure your webserver (Apache in the examples) to defend against these scenarios.
Ideally these are within your Vhost configuration of your site, but work equally well n .htaccess files.
Preemptive protection measures
1) Deny access to any PHP and TXT files other than index.php and robots.txt
This will prevent visitors being able to run any php files other than the index.php file - Most CMS applications require that all requests pass through the index file and all other php files are there for the web server to access not site visitors.
Preventing access to all other php files is a simple method to avoid access to other files; you can allow access to known IPs or provide authenticated access to known users if specific php files need to be accessed.
It is beyond the scope of this blog - but there are some interesting ideas emerging about placing all other non public php files outside the public web root altogether.
The gist also prevents the sniffing of information about your CMS install version (e.g. CHANGELOG.txt) and from other txt files.
There is conflicting advice about the protection of txt files, with some arguing that they represent no risk and others suggesting that they be deleted.
In my view they represent an unnecessary leakage of information and can be used to gain knowledge of the version of the CMS core, modules and other files that may have known exploits.
Deleting the files is not really practical as when the site is updated you have to repeat that and they may serve a use to the site developers.
But more importantly this method protects against these files should they exist and inadvertent copying of the settings file to a txt backup.
Note that the method does allow access to robots.txt - the one txt file that should be visible.
2) Deny access to commonly used extensions that aren't required by your app
This will prevent access to commonly used extensions (inc, bak, sql, etc) that aren't required for the functioning of your site and shouldn't be publicly accessible.
3) Deny acess to hidden files
Hidden files such as version control folders and files would ideally be kept outside of your document root, but it is common for the repo and other hidden files to be present within the site.
These files often contain sensitive information and should not be accessible.
There are certain exceptions such as the .well-known folder that may be required to be accessed - so these should be explicitly 'white-listed'
4) Don't create copies of sensitive files on a production server
Well we don't right! Not us, but someone might - even you under pressure! So the above measures provide a blanket protection in case you do.
I'll remind you here that this is bad practice on many levels - but it happens - you know it does - so call off the high horses!
It's not fool proof but should be part of your Defence in Depth strategy.
Another thing that is always worth mentioning and is clear from the image here, is that you should make sure that directory browsing is turned off!
Otherwise malicious agents would be able to hunt around for files to exploit.
Clearly this another badly misconfigured site, but it happens when no default document exists and directory listing is allowed.
It is also commonly seen on copies of sites made for testing purposes - so consider all of your sites not just the main production site.
So recently, over the past few days we have seen this scenario (visible copies of configuration files) actively exploited with these attacks originating from a range of IPs.
Clearly they are following a pattern, all looking for the same variations of the configurations files and possible copies.
The current attack, from various IPs, follows exactly the same pattern of file exploration and appears to test the site for the CMS variety before it then trawls for the possible backups.
I have put a full list of the files trawled for in the latest exploit in this pastebin - http://pastebin.com/Tdva8DUX
The IP address list there is by no means comprehensive.
Although you should definitely block IPs actively engaged in the exploit (using IPSET / IPTABLES or some other firewall) that is all after the fact and no substitute for protecting these files in the first place.
In a follow up post I will explore methods of recognising such attacks and proactively banning traffic from the malicious origin IPs.
- info [at] blue-bag.com
- Telephone: 0843 2894522
- Blue-Bag HQ:
The Garage, Manor Farm
Somerset, BA3 4HP, United Kingdom
- Telephone: (+44) 01761 411542
- Blue-Bag Brighton:
Unit 35 Level 6 North, New England House
New England Street, Brighton
BN1 4GH United Kingdom
- Telephone: (+44) 07944 938204
- VAT GB 748125034
- UK Company Reg: 3932829