Since we started to work with computers, we always heard the following advice: Make backups!. Everytime you have to change something in a file or an application, first make a backup of the existing resources (code, configuration files, data). But, if not properly managed, backups can be evil and increase the surface attack of your web application. Just take an example:

You maintain a Wordpress website for your company and, before changing the configuration, you make a backup of the main configuration file.

# cd /var/www/htdocs
# cp -p wp-config.phpwp-config.php.bak

Alternatively, you can also archive the directory content:

# zip -r .

For the same reasons, youcan also make abackupof the SQL databases or user files.

Now, you can edit them and if everything goes wrong,just revert to the previous version. Looks so far so good! But, often, people forget to protect the backup (which is created with the web site UID or a wrong umask - making it readable by anybody).

What am I talking about this? For a few days, I detected a lot of scans for backup"> /db_backup.sql/db_backup.rar/db_backup.sql.tar/db_backup.tar.gz/db_backup.tar.bzip2/db_backup.tar/db_backup.sql.bz2/db_backup.7z/dump.tar.bz2/db_backup.sql.7z/dump.sql/

I also detected scans for files ending with a .bak extension or the ~ (thecommon way for many editors to make a backup of edited files).

To protect yourself against this problem:

  • Do not store backup files in the root of your website.
  • Delete them once the maintenance completed and that youre sure you dont need it.
  • Change the owner and access rights (use a correct umask!)
  • Encrypt them (zip -e)
  • Just store them offline!

But of course, continue to make backups of your sensitive data...

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Docker CVE-2016-9962 Local Privilege Escalation Vulnerability
Internet Storm Center Infocon Status