Backup-File Artifacts: The Underrated Web-Danger

- 6 mins

Testing and Exploiting Backup-File Artifacts with BFAC

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

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

What is Backup-File Artifacts that can affects web-applications?

Backup-File Artifacts are basically files that was left during a backup process. Offline backup artifacts is a something that I will not discuss, 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), and then push it to the web-server along with the backup file. Also, one of the developers’ behaviours is to edit a script in the webroot of the web-server, and when finished the process, the backup-file is left on the webroot. This eventually allows any unauthenticated party to retrieve the source-code by downloading the BFA. This is a general explanation of the BFA concept.

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 that developers can recover the files they are editing if they encountered any issues. By default, the backup file is made in the same directory of 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 to other code editors, each code-editor has its own 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-forces 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 response of the request, showing the source-code of the script. Of course, the same goes to all different patterns.

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

Version Control Systems (VCS) are very popular systems in today’s world. All VCS creates a meta-directory on the same folder of the project. This folder includes tracks and logs for every change is done to the files of the project.

Developers tend to 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 for unauthorized parties on the web-server.hg

3. Human-Based Missed Backup-File Artifacts

Developers who are not using Version Control Systems tend to do a manual backup file for scripts that needs to be edited. Also, developers uses similar patterns usually that can be easily guessed and enumerated.

For example, when a developer would like to edit index.php, he/she would make an initial copy in case of any errors or issues. The copy can be named with something that is really common.

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 that was mentioned above, which causes the disclosure of the web-application’s source-code.

The Problem

Security Researchers and Penetration Testers who relies solely on web-application vulnerability scanners might not encountered this issues a lot in real-world. The reason is because Most web-application vulnerability scanners does not test against Backup-File Artifacts on web-servers. Also, there are no major tools till the release of this research that is dedicated to test Backup-File Artifacts.

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

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

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

Introducing BFAC

BFAC (Backup-File Artifacts Checker) is an automated tool that checks for backup artifacts that may discloses the web-application’s source code. BFAC goal is 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, then remove it to a temporary directory for review by developers responsible for it.

Developers

After doing any edits, check if a backup file exist, 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