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.

• 3.69.53.252 with 3953193 attempts
• 3.71.111.191 with 2165519 attempts
• 52.59.9.15 with 1726745 attempts
• 35.83.251.89 with 1707670 attempts
• 3.96.219.221 with 1645568 attempts
• 35.182.107.115 with 1553854 attempts
• 34.240.248.60 with 1526032 attempts
• 50.16.69.90 with 1065868 attempts
• 3.99.130.127 with 952639 attempts
• 35.91.211.91 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.

Conclusion

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.

Source: wordfence.com