Configuration Probing: Your Backups Might Be Your Greatest Weakness
Configuration files exist to make life easier for developers and website operators. In a world without configuration files, every instance of code that depended on a database connection could potentially require the connection details to be hard coded or manually entered. Other reusable data would be defined multiple times, causing code bloat and possible performance issues. Even just making changes to a website could be a tedious task of tracking down exactly where configuration details are kept, and updating all instances. Configuration files are a great resource for maintaining a website with ease, but they are also a common resource for malicious actors.
Sensitive Data in WordPress Configuration Files
WordPress includes a core file named wp-config.php that defines the database credentials, secret keys, the database table prefix to use, and required file paths. Defining these in a configuration file is convenient, but if a malicious actor can get their hands on the wp-config.php file, then they have a lot of information that can lead to data theft and even a site takeover. In WordPress, the website content is stored within the database, including the user details for administrators and other roles. This file is protected by default in WordPress, but what happens when you need to change some minor details in the file, and you make a backup with a different name, but leave it in a web accessible directory?
Let’s take a look at the database details included in the wp-config.php file. What is defined here is the name of the database, the name of the database user as well as the associated password, the hostname for the location of the database, and the default character set and collation. If other protections are not in place on the database server, such as IP restriction, this information can give a malicious actor everything they need to access the database. With unrestricted database access, they can then insert new admin users which in turn provides them with unrestricted access to the website and all of its backend data.
Common Backup Mistakes
A common way of backing up the wp-config.php file is to make a copy of the file and add a new file extension like .txt, .bak, or .html to the end of the filename. This is a quick way to make a backup, and ensure it is readily available to be reactivated by changing the filename back to the original. The problem is that leaving these files in a web-accessible directory makes it relatively simple for malicious actors to find the sensitive data contained in the file.
Let’s say the file is updated to change the absolute path for the WordPress website, with the original backed up as wp-config.php.html. If you go to the backup file directly in a browser, you will get a white page. This seems harmless and safe, but it also gives the information that the file exists, just without any actual HTML code to display content on the screen. If instead the page is called using a cURL command from a terminal, the file contents will be displayed.
If the file is backed up as wp-config.php.bak the browser will download the file when it is loaded, and if the file is backed up as wp-config.php.txt then the content will display in the browser directly.
Configuration Backup Probing
There are multiple techniques used to probe for backups of configuration files. One simple technique is using what is known as Google dorks. This technique makes use of built-in search functionality in Google and other search engines. For instance, the search phrase inurl:wp-config.php intext:DB_PASSWORD will return results for files containing wp-config.php within the URL that also contain DB_PASSWORD in the body of the file that loads. Malicious actors will also often automate the process of finding backup configuration files with the use of scripts and prebuilt tools. Using some form of automation to find these files makes the process much more efficient.
Probing for backups of the wp-config.php file is a very common practice. It is so common, in fact, that the Wordfence firewall has tracked 70,408,576 attempts to locate these backups in the last 30 days alone.
In this data, we did identify four legitimate uptime scanners that were being used to find this file. The thing with these scanners is that they are not expensive, and two of them even have free versions available. Because there is no legitimate reason to scan for backups of the wp-config.php file, it appears that malicious actors have determined that the resources required to use these scanners are outweighed by the benefits of implementing a known legitimate solution for nefarious purposes. These scanners account for a little over 6.5 million attempts to locate the wp-config.php file backups.
The following are the top ten IP addresses we have blocked from probing for wp-config.php backups.
- 22.214.171.124 with 3953193 attempts
- 126.96.36.199 with 2165519 attempts
- 188.8.131.52 with 1726745 attempts
- 184.108.40.206 with 1707670 attempts
- 220.127.116.11 with 1645568 attempts
- 18.104.22.168 with 1553854 attempts
- 22.214.171.124 with 1526032 attempts
- 126.96.36.199 with 1065868 attempts
- 188.8.131.52 with 952639 attempts
- 184.108.40.206 with 789722 attempts
All of these are registered to Amazon, and are spread around the world, which is not uncommon. Threat actors will often use servers in any location that could be useful to them, especially if there is a location that is known for allowing (or at least turning a blind eye to) the type of activity they will be using the server for.
Looking at the data collected in the last 30 days, it becomes clear that scanning for configuration files such as wp-config.php is wide-spread among malicious actors. The database credentials alone can prove incredibly valuable to anyone whose intent is to take over a website. With more than 40% of current websites running WordPress, this makes finding wp-config.php files even more valuable as it only requires knowledge of a single content management system (CMS).
The Wordfence Scanner includes an option to “Scan for publicly accessible configuration, backup, or log files” which will alert you if any publicly accessible configuration, backup, or log files are present in your site’s directory. This setting is enabled on a standard scan and can be checked for custom scans as well. If you received results indicating that you have a publicly accessible sensitive file, we strongly recommend removing it from the publicly accessible directory immediately.
If you believe your site has been compromised as a result of a configuration probing attack or some other exploit, we offer incident response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both of these products include hands-on support in case you need further assistance.
An admin who backups a configuration file by changing it to a readable TXT file really deserves to get removed immediately from his job. I develop and maintain hundreds of customers sites and have never ever had to backup a config.php file this way. It is a rare exception that I even have to touch the config.php ever again after installing WordPress.
While it is true that changes aren't often needed to wp-config.php, there are definitely times that changes are necessary. Often when the file is backed up simply by appending the file extension, the intent is to delete the backup as soon as the changes are confirmed to have worked. People get busy or overwhelmed, and may think that this is low risk due to the short time the file will be there, or the risk may simply have been overlooked. WordPress is also used by people of all technical abilities and knowledge, so someone who may have found a tutorial online for how to change the file may not know the risks involved. I bear no ill will toward those who use these methods, but do hope they can learn and employ best practices before inadvertent vulnerabilities can be exploited.
To keep credentials out of version control, a lot of developers use a .env file, which is added to the .gitignore file. Even though it seems like a web server shouldn't ever serve a .env file because it starts with a dot, some Apache servers are only configured to prevent serving files that start with ".ht" but not all dot files. If you use this technique, it's a good idea to verify that your server won't hand out the .env file, as there are bots that go hunting for exposed .env files.
This is a very similar concept indeed. It is always best to ensure that any sensitive information is not web accessible.
That also goes for leaving entire site backups in public-facing directories. Indexes tend to be disabled for (and in) those, but I personally feel much better when the only way to download a backup file is to authenticate with WP security and fetch a token to access one. Obscurity is not security - relying on the folder name not being known isn't secure in any way. Putting them outside of the public folder somewhere is often a much better option. In fact, putting anything you don't want reachable there is much better than obscuring names.