Exploiting backup copies of settings

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.

To see how this is exploited in the wild, the following shows a list of real files requested by a malicious visitor.

# Examples of real attempts to access sensitive files and backups
/sites/default/settings
/sites/default/settings.php~
/sites/default/settings.php.txt
/sites/default/settings.php.old
/sites/default/settings.php_old
/sites/default/settings.php-old
/sites/default/settings.php.save
/sites/default/settings.php.swp
/sites/default/settings.php.swo
/sites/default/settings.php_bak
/sites/default/settings.php-bak
/sites/default/settings.php.original
/sites/default/settings.php.orig
/sites/default/settings.php.bak
/sites/default/settings.save
/sites/default/settings.old
/sites/default/settings.bak
/sites/default/settings.orig
/sites/default/settings.original
/sites/default/settings.txt

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.

e.g.

• /sites/default/settings.bak
• /sites/theexample.org/settings.bak

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:

/CHANGELOG.txt
/.bash_profile
/.bashrc
/.db_config
/.default
/.logs
/.old
/.private
/.queries
/.query
/.secret
/.sql
/.temp
/.git
/phpinfo.php
/pinfo.php
/info.php

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

# deny access to txt files and php files other than specific ones
<FilesMatch "([^(xxrobots|robots)].*\.txt|[^(index|channel)].*\.php)$">
# Apache < 2.3
<IfModule !mod_authz_core.c>
    Require valid-user
    Order deny,allow
    Deny from all
    Allow {your-static-ip}
    Allow from 127.0.0.1
    Satisfy Any
</IfModule>

# Apache ≥ 2.3
<IfModule mod_authz_core.c>
    AuthName "Restricted"
    AuthUserFile /path/to/passwdfile
    AuthGroupFile /path/to/.htpasswds/groupfile
    AuthType basic
    <RequireAny>
        <RequireAll>
            <RequireAny>
                Require ip {your-static-ip}
                Require ip 127.0.0.1
                Require valid-user
                Require group {your secure group}
            </RequireAny>
        </RequireAll>
    </RequireAny>
</IfModule>
</FilesMatch>

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

# deny access to files by extension
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
<IfModule !mod_authz_core.c>
    Order allow, deny
</IfModule>

# Apache ≥ 2.3
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
</FilesMatch>

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

# Block access to all hidden files and directories with the exception of
# the visible content from within the `/.well-known/` hidden directory.

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} "!(^|/)\.well-known/([^./]+./?)+$" [NC]
    RewriteCond %{SCRIPT_FILENAME} -d [OR]
    RewriteCond %{SCRIPT_FILENAME} -f
    RewriteRule "(^|/)\." - [F]
</IfModule>

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!

# Block access to directories without a default document.
<IfModule mod_autoindex.c>
    Options -Indexes
</IfModule>

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.