Backup-File Artifacts: The Underrated Web-Danger

- 6 mins

Testing and Exploiting Backup-File Artifacts with BFAC

On August 13th, 2016, I talked about Backup-File Artifacts. This attacking vector is not commonly known or being tested by penetration testers, yet it can be critical to the security of the web environment. At the end of the talk, I released BFAC, an automated security tool that tests for backup file Artifacts missed on web servers and can disclose the web application’s source code.

This post will discuss ideas on Backup-File Artifacts and will cover the types of Backup-File Artifacts (BFAs), how they occur, and how they can be related to web servers. Also, it will cover the usage of BFAC (Backup-File Artifacts Checker) in finding BFA issues.

What are Backup-File Artifacts that can affect web applications?

Backup-file artifacts are files that were left during a backup process. Offline backup artifacts are out of the scope of this blog post since it does not affect the security of the web, and it’s not related to this research’s point.

Most developers make a backup file before editing a script (or code editors or other programs), then push it to the web server along with the backup file. Also, one of the developers’ behaviors is to edit a script in the webroot of the web server, and when the process is done, the backup file is left on the webroot. This eventually allows any unauthenticated party to retrieve the source code by downloading the BFA.

Types of Backup-File Artifacts

1. Backup-File Artifacts Caused by Code-Editors

Text-Editors and Code-Editors intentionally make a backup file for the file that is being edited. This is done so developers can recover the files they edit if they encounter any issues. By default, the backup file is made in the same directory as the file that is being edited, also with a pattern based on the original file name.

For instance, when editing a file called index.php with nano, a backup file will be created with the name “index.php.save”. The same goes for other code editors. Each code editor has a pattern that it follows when creating a backup file for the file that is being edited.

If the backup file was left on the web server, an attacker can brute-force the file until he finds an existent backup file. Since index.php.save will not be executed as index.php, index.php.save will be the request’s response, showing the script’s source code. Of course, the same goes for all different patterns.

2. Backup-File Artifacts Caused by Missed VCS Meta-Directories on The Webroot

Version Control Systems (VCS) creates a meta-directory on the same folder of the project. This folder includes tracks and logs for every change done to the project files.

Developers download/clone their project’s repositories on the web server without removing the VCS directory. This causes the project to be leaked since the VCS is publicly accessible to unauthorized parties on the web server.hg

3. Human-Based Missed Backup-File Artifacts

Developers using something other than Version Control Systems tend to do a manual backup file for scripts that need editing. Also, developers use similar patterns usually that can be easily guessed and enumerated.

For example, when a developer would like to edit index.php, they would make an initial copy in case of any errors or issues. The copy approach can be named with something widespread.

index.php → index.php.bak
index.php → index.old
index.php → index.php.temp

Since human-based backup patterns can be easily guessed, we can perform the same damage mentioned above, which causes the disclosure of the web application’s source code.

The Problem

Security Researchers and Penetration Testers relying solely on web-application vulnerability scanners might not encounter these issues in real-time. The reason is that most web-application vulnerability scanners do not test against Backup-File Artifacts on web servers. Also, only significant tools once this research is released are dedicated to trying Backup-File Artifacts.

Examples of tested web-application Vulnerability Scanners that do not test perform Backup-File Artifacts testing

Note: these are the versions that I have tested of the products. Future versions mainly don’t support testing for Backup-File Artifacts, either.

There are very few Web-Application Vulnerability Scanners that do test for Backup-File Artifacts. However, those scanners are using fundamental testing of Backup-File Artifacts. This testing done by this rare portion of web-application vulnerability scanners misses most essential checks and does not satisfy the need for professional security assessment done by security testers. For that reason, I wrote BFAC.

Introducing BFAC

BFAC (Backup-File Artifacts Checker) is an automated tool that checks for backup artifacts that may disclose the web application’s source code. BFAC aims to be an all-in-one tool for backup-file artifacts black-box testing.

Features

BFAC Homepage: https://github.com/mazen160/bfac

How to Protect from Backup-File Artifacts on Web-Servers?

System Administrations

Actively scan web servers for Backup-File Artifacts and review if anything found should be placed publicly. If it’s not needed, remove it to a temporary directory for review by the developers responsible.

Developers

After doing any edits, check if a backup file exists, and remove it from the webroot if it exists.

Penetration Testers

Add testing for Backup-File Artifacts to your testing checklists. Also, you can use BFAC to test for Backup-File Artifacts.

Presentation Mirrors:-

Related Posts

Mazin Ahmed

Mazin Ahmed

Thoughts of a hacker

rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora