Keeping your WordPress secure involves a continuous process of testing, hardening, monitoring, and improving. There are several things WordPress administrators can take care of to help them ensure their websites are safe. From ensuring passwords meet specific criteria to hardening PHP, these processes can go a long way in helping you ensure you run a tight, clean ship. One thing that tends to get overlooked is exposed backup and unreferenced files. These files can pose a security risk that can easily be managed by following best practices.
WordPress uses directories to organize information. All pages and media reside within this structure. In a typical installation, this structure would look something like var/www/html/wordpress/wp-content.
Web servers, including servers hosting WordPress websites, are typically configured to serve clients all files that reside within a particular directory. There are a few exceptions, such as PHP files; however, unless an administrator has explicitly blocked access, the chances are that if a client requests it, the web server will oblige.
Generally speaking, this is a good thing, and it is what you want to happen since this is how files pertinent to your web pages, such as CSS files, JS files, and images, are served to the visitor. However, this behavior also means that you can be unwittingly serving files you never intended the public to see, such as backup and unreferenced files.
What are backup and unreferenced files?
As the name suggests, backup and unreferenced files are actual backups taken that can either be backups of particular files, typically created when editing files such as configuration files, or even full backups. Understanding what these backup files are and how they are generated is the first step we need to take to address the problem.
There are many reasons why you might need to edit WordPress files. Editing your WordPress site’s files, however, without taking a backup first takes some nerve — one missing semicolon can take your website down!
Of course, because such mistakes are easy to make, it is not advisable to edit files directly on production web servers. Best practices tell us to first test any changes in a testing or staging server. Only after thorough and successful testing can changes be moved to the live/production server.
In real life, however, best practices are not always followed. This can be especially true when it’s a teeny-weeny change. The process of downloading the file, making the changes, testing, and re-uploading can take considerably longer than editing the file on the live server. We have all been there.
Editing on the live server can be very easy. With an SSH client and Vi (or Vim if you prefer the improved version), you can do wonders. Once you connect to the server and make your way to the directory, chances are you’ll first take a backup of the file (ex. wp-config.php.bak), edit the live one, make sure everything is in order, and it’s all hunky-dory. However, that backup file left in the folder (just in case, you know) can end up being the source of many aches and pains. Chances are pretty much anyone can download it and with it the entire configuration, in plain text, no less.
Moreover, many WordPress administrators may not be aware that editing files in place using a file editor such as Vim may automatically create backup, recovery, and lock files. Vim creates these files to allow you to recover your work if Vim crashes or quits unexpectedly. While this is unquestionably a valuable feature to have, this also means that you may inadvertently end up with backup files you never intended to create sprinkled around your website, waiting for anyone to access.
Equally, backups of entire directories left in a public folder can be as damaging. While taking backups of your WordPress website is critical, this needs to be done safely without introducing new security risks. We will talk about this in more detail later in this article.
Common examples of backup files include renamed old versions of modified configuration files, PHP files or other source code, and automatic or manual backups in the form of compressed archives (such as .zip, .gz, or .tar.gz archives).
On the other hand, unreferenced files are misplaced files that, due to a configuration or design decision, end up somewhere where they do not belong.
What are the risks?
Backup and unreferenced files accidentally left accessible may leak sensitive information. Depending on the file, sensitive data can include configuration parameters or source code that help malicious users better understand how your website works, thus making it easier to craft an attack against your website. In some cases, passwords that may give attackers control over the entire WordPress installation can also be leaked.
There are several ways someone can find leftover files on your web server. While some of the methods require some technical expertise, others are as simple as a Google search, which increases the risk of exposure. If you’re unsure whether you have leftover files on your server, continue reading to learn how you can search for them and find them before someone else does.
How to find backup files and unreferenced files on your WordPress website
There are a few different methods someone can use to find backup and unreferenced files. As the server owner, you have the edge since you can go about it more directly. This section will explore these different tools, starting with the tools you can use to hunt and remove these files. We will then look at how a curious cat might go about finding backup and unreferenced files on your server.
When looking for backup files you may have left behind on your web server, you can take one (or more) of three approaches. The easiest way is to install a plugin that monitors files for changes. Alternatively, you can either try looking for backup files left on the filesystem using command-line tools such as find or, you can try looking for backup files using a technique called fuzzing.
File integrity monitoring plugin
A file integrity monitoring solution for WordPress can effortlessly help monitor file changes on your web server and alert you if it detects anything has been added, removed, or changed.
This can be achieved with the Website File Changes Monitor plugin. The plugin takes a fingerprint of your directories and then compares it to subsequent fingerprints. In essence, it works on the same principles as a checksum, making it highly secure and reliable.
A file integrity monitor can be especially effective if you’re not privy to all of the directories used by WordPress. One other significant advantage of this plugin is that monitoring is automated, so you do not have to remember to check for files – the plugin does it automatically.
Find
Let’s now look at how we can find backup files using the find command. The following command will look for several commonly used file extensions that are used when creating backup files.
find /var/www -type f ( -name ‘*.bak’ -o -name ‘*.backup’ -o -name ‘*.bac’ -o -name ‘*.zip’ -o -name ‘*.tar’ -o -name ‘*.jar’ -o -name ‘*.log’ -o -name ‘*.swp’ -o -name ‘*~’ -o -name ‘*.old’ -o -name ‘*.~bk’ -o -name ‘*.orig’ -o -name ‘*.tmp’ -o -name ‘*.exe’ -o -name ‘*.0’ -o -name ‘*.1’ -o -name ‘*.2’ -o -name ‘*.3’ -o -name ‘*.gz’ -o -name ‘*.bz2’ -o -name ‘*.7z’ -o -name ‘*.s7z’ -o -name ‘*.lz’ -o -name ‘*.z’ -o -name ‘*.lzma’ -o -name ‘*.lzo’ -o -name ‘*.apk’ -o -name ‘*.cab’ -o -name ‘*.rar’ -o -name ‘*.war’ -o -name ‘*.ear’ -o -name ‘*.tar.gz’ -o -name ‘*.tgz’ -o -name ‘*.tar.z’ -o -name ‘*.tar.bz2’ -o -name ‘*.tbz2’ -o -name ‘*.tar.lzma’ -o -name ‘*.tlz’ -o -name ‘*.zipx’ -o -name ‘*.iso’ -o -name ‘*.src’ -o -name ‘*.dev’ -o -name ‘*.a’ -o -name ‘*.ar’ -o -name ‘*.cbz’ -o -name ‘*.cpio’ -o -name ‘*.shar’ -o -name ‘*.lbr’ -o -name ‘*.mar’ -o -name ‘*.f’ -o -name ‘*.rz’ -o -name ‘*.sfark’ -o -name ‘*.xz’ -o -name ‘*.ace’ -o -name ‘*.afa’ -o -name ‘*.alz’ -o -name ‘*.arc’ -o -name ‘*.arj’ -o -name ‘*.ba’ -o -name ‘*.bh’ -o -name ‘*.cfs’ -o -name ‘*.cpt’ -o -name ‘*.dar’ -o -name ‘*.dd’ -o -name ‘*.dgc’ -o -name ‘*.dmg’ -o -name ‘*.gca’ -o -name ‘*.ha’ -o -name ‘*.hki’ -o -name ‘*.ice’ -o -name ‘*.inc’ -o -name ‘*.j’ -o -name ‘*.kgb’ -o -name ‘*.lhz’ -o -name ‘*.lha’ -o -name ‘*.lzk’ -o -name ‘*.pak’ -o -name ‘*.partimg.’ -o -name ‘*.paq6’ -o -name ‘*.paq7’ -o -name ‘*.paq8’ -o -name ‘*.pea’ -o -name ‘*.pim’ -o -name ‘*.pit’ -o -name ‘*.qda’ -o -name ‘*.rk’ -o -name ‘*.sda’ -o -name ‘*.sea’ -o -name ‘*.sen’ -o -name ‘*.sfx’ -o -name ‘*.sit’ -o -name ‘*.sitx’ -o -name ‘*.sqx’ -o -name ‘*s.xz’ -o -name ‘*.tar.7z’ -o -name ‘*.tar.xz’ -o -name ‘*.uc’ -o -name ‘*.uc0’ -o -name ‘*.uc2’ -o -name ‘*.ucn’ -o -name ‘*.ur2’ -o -name ‘*.ue2’ -o -name ‘*.uca’ -o -name ‘*.uha’ -o -name ‘*.wim’ -o -name ‘*.xar’ -o -name ‘*.xp3’ -o -name ‘*.yz1’ -o -name ‘*.zoo’ -o -name ‘*.zpaq’ -o -name ‘*.zz’ -o -name ‘*.include’ -o -name ‘*_1’ -o -name ‘*_2’ -o -name ‘*_x’ -o -name ‘*bak’ -o -name ‘*_bak’ -o -name ‘*old’ -o -name ‘*_old’ -o -name ‘*_a’ -o -name ‘*_b’ -o -name ‘*_c’ -o -name ‘*_d’ -o -name ‘*_e’ -o -name ‘*_f’ -o -name ‘*inc’ -o -name ‘*_inc’ -o -name ‘*_backup’ -o -name ‘* – Copy’ -o -name ‘* – Copy (2)’ -o -name ‘* – Copy (3)’ -o -name ‘*backup’ -o -name ‘*-backup’ -o -name ‘*-bak’ -o -name ‘*-old’ -o -name ‘*-1’ -o -name ‘*-2’ -o -name ‘* – Copy – Copy’ -o -name ‘*(copy)’ -o -name ‘*(another copy)’ -o -name ‘*(second copy)’ -o -name ‘*(third copy)’ -o -name ‘*(fourth copy)’ -o -name ‘*(2nd copy)’ -o -name ‘*(3rd copy)’ -o -name ‘*(4th copy)’ -o -name ‘* (copy)’ -o -name ‘* (another copy)’ -o -name ‘* (second copy)’ -o -name ‘* (third copy)’ -o -name ‘* (fourth copy)’ -o -name ‘* (2nd copy)’ -o -name ‘* (3rd copy)’ -o -name ‘* (4th copy)’ -o -name ‘Copy of *’ -o -name ‘Copy (2) of *’ -o -name ‘Copy (3) of *’ -o -name ‘Copy of Copy of *’ -o -name ‘backup*’ -o -name ‘backup_*’ -o -name ‘backup-*’ -o -name ‘bak*’ -o -name ‘bak_*’ -o -name ‘bak-*’ -o -name ‘old*’ -o -name ‘old_*’ -o -name ‘old-*’ -o -name ‘1*’ -o -name ‘1_*’ -o -name ‘1-*’ -o -name ‘2*’ -o -name ‘2_*’ -o -name ‘2-*’ )
Fuzzing
The following method uses a command-line-based tool called ffuf with a wordlist (a list of file names and file paths collected in plain text) that focuses on WordPress files. ffuf can be configured to make requests using a comma-separated list of common backup file extensions ( this example only uses a shortened list that only includes .bak and .backup, but in reality, it would likely be much longer).
ffuf -u http://example.com/FUZZ -w wordlist.txt -e ‘.bak,.backup’
Search Engine searches
Search engines are very, very good at finding and cataloging information on web servers. Someone can do this by using advanced operators that can, for example, drill down a query to find specific file types on a given server.
This type of search is also known as Google Dorking and can use a combination of advanced filters and inference. Inference is how someone with no knowledge of what resides on a server uses general information to infer what kind of files and structures might reside on a server and then searches for those specific things.
Security scanners
There are different types of scanners that can scan the directories of a website. The first type of scanner is called a site crawler, which is the same underlying technology search engines use to read websites. These types of scanners, however, are not exclusive to search engines and can be downloaded freely.
It is illegal to scan a target website in most countries, even if your intentions are good. You can and should only use a scanner against websites you own. If you are scanning a third-party website, make sure you have consent. Even so, someone with malicious intentions can use a security scanner to learn more about your website and understand what kind of files are on it.
Another type of scanner is a penetration testing scanner, which can scan a website for vulnerabilities, including leftover files.
Found backup or unreferenced files? Here’s what to do
Storing backup files on a website is never a good idea. Unfortunately, it’s not uncommon for WordPress website owners and administrators to configure cron jobs (scheduled tasks) to take database backups, only to store these backups on the same server. While you most certainly should be backing up your website, you should take care that backup files not be stored anywhere on the system you backed up.
Having a well-thought-out WordPress backup strategy that follows best practices is crucial not only from a security perspective but equally from a business continuity standpoint. After all, backups are not worth much if you cannot use them to restore data.
How to prevent backup file enumeration
As we’ve seen throughout this article, keeping backup files on your WordPress website can be pretty risky. As such, you should always use a test or staging environment to carry out your changes before pushing them to the live/production server. Most managed WordPress hosting accounts come with a staging environment right out of the box. You can also use software such as Local, which allows you to spin up WordPress instances on your PC.
Nevertheless, if you choose to keep backup files on your web server, ideally, keep them out of the directory you have configured your webserver to serve.
Additionally, configure your WordPress files permissions to prohibit access to the web server’s user — this ensures that even in the event of a misconfiguration, the webserver will not be allowed to serve the file to a client requesting it. As an added measure, it’s a good idea to encrypt any database backups and make sure the encryption key is not accessible by the web server’s user.
The post Exposed backup and unreferenced files and how to find them appeared first on WP White Security.
Source: Security Feed