It’s a well-known fact that website backups are important for mitigating a plethora of site issues. They can help restore a site after a compromise or even facilitate the investigative process by providing a clean code base to compare the current site state to.
However, if a backup is not set up correctly, it can have the opposite effect — and may instead impose a security threat to your website.
For example, we often find webmasters maintaining old copies of a site within a subdirectory of their main site. These copies are often accessible from outside and, if they contain files with security vulnerabilities, hackers can easily exploit them — even if the vulnerabilities have already been fixed in the main version of the site.
These older versions can also be easily infected during new compromises, rendering them unusable for website restoration and negating the entire purpose of creating the backup in the first place.
Backup Archives: To Zip, or Not to Zip
To mitigate these security issues, one step that is often taken is to archive older versions of a website (e.g. zip, gzip, tar, etc) so that individual files cannot be accessed from the outside or become infected during a new attack. However, creating an archive is not enough to minimize all security risks — and in certain cases, it may even increase chances of a compromise.
For example, if the backup archive file is saved in a publically accessible location (i.e. in the site root) and has a predictable name, this can actually help a bad actor identify a site’s backup files.
Here are some recent examples found in access logs:
111.231.205.120 - - [14/Jun/2020:20:44:14 +0500] "HEAD /<domain-name>.zip HTTP/1.1" 405 73 - "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)" 111.231.205.120 - - [14/Jun/2020:20:44:11 +0500] "HEAD /<domain-name>.rar HTTP/1.1" 405 73 - "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)"
As seen in the examples above, requests from the Chinese IP 111.231.205.120 are probing (HEAD request) for .zip and .rar files whose names match the domain name of the attacked site, e.g. example.com.zip and example.com.rar. These are typical file names that webmasters label their site archives when they either create backups or move a site to a new host.
Attackers are looking for archived files like these because, unlike server-side .php files, they can be easily downloaded — and usually contain sensitive information like database dumps and internal documents. Backup archives also usually contain CMS configuration files (e.g. wp-config.php for WordPress) along with database credentials.
Under certain conditions, stolen credentials can be used to directly modify the CMS database and inject malicious code, create rogue users, or even reverse hardening settings.
Avoiding Common Backup Configuration Problems
One of the most effective steps you can to avoid these types of problems is to name your backup archives less predictably, password-protect your backups, and save them outside of publically accessible directories — preferably on an entirely different server to avoid problems that might occur within your primary server’s environment.
