How to remediate – Backup Files Disclosure

1. Introduction

The Backup Files Disclosure vulnerability allows retrieval of file backups from a remote web server. This can lead to unauthorized access to sensitive information stored in those backups, potentially impacting business confidentiality. Systems hosting web applications and storing backup files are typically affected. A likely impact is the compromise of confidential data if backups contain credentials or other sensitive details.

2. Technical Explanation

The vulnerability occurs because file backups are accessible via direct request with appended suffixes. An attacker can predict these suffixes to download potentially sensitive files. There is no known CVE associated with this specific issue, but it relates to insecure file storage practices. For example, an attacker could attempt to access a database backup by requesting /backup/database.bak or /backup/config.old.

• Root cause: Missing restrictions on accessing files with common backup extensions.
• Exploit mechanism: An attacker appends known suffixes (e.g., .old, .bak, ~) to file names and requests them via HTTP(S).
• Scope: Web servers storing backups without proper access controls.

3. Detection and Assessment

Confirming vulnerability involves checking for accessible backup files. A quick check is browsing the web server’s filesystem for common backup extensions.

• Quick checks: Use a web browser to attempt accessing files with suffixes like .bak, .old, or ~ appended to known file names.
• Scanning: Nessus vulnerability ID 8f3302c6 can identify this issue as an example.
• Logs and evidence: Web server access logs may show requests for files with backup extensions. Look for HTTP status codes 200 (OK) when accessing these files.

curl -I http://example.com/backup/database.bak

4. Solution / Remediation Steps

Fixing this issue requires securing access to backup files.

4.1 Preparation

• Ensure you have rollback procedures in place, such as restoring from the previous backup. A change window may be required depending on your environment.

4.2 Implementation

1. Step 1: Review all files stored within the web server’s document root for sensitive information.
2. Step 2: Delete any unnecessary backup files that contain sensitive data.
3. Step 3: Configure the web server to deny access to files with common backup extensions (e.g., .bak, .old, ~). This can be done through configuration settings or using a .htaccess file.

4.3 Config or Code Example

Before

# Apache .htaccess example - no restrictions
<FilesMatch ".(bak|old|~)$">
  Allow from all

After

# Apache .htaccess example - denying access to backup files
<FilesMatch ".(bak|old|~)$">
  Require all denied

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Least privilege: Restrict access to backup files to only authorized personnel.
• Secure defaults: Configure web servers with secure default settings that deny access to sensitive files.

4.5 Automation (Optional)

An example script for Apache using a configuration management tool:

# Ansible task example - update .htaccess file
- name: Deny access to backup files in .htaccess
  lineinfile:
    path: /var/www/.htaccess
    regexp: '^<FilesMatch ".(bak|old|~)$">'
    line: '<FilesMatch ".(bak|old|~)$">'
            '  Require all denied'
            ''
    state: present

5. Verification / Validation

• Post-fix check: Use a web browser or curl command to attempt accessing files with suffixes like .bak, .old, or ~ appended to known file names. Expect an HTTP status code of 403 (Forbidden).
• Re-test: Repeat the detection steps from Section 3 and verify that backup files are no longer accessible.
• Monitoring: Monitor web server access logs for any attempts to access files with backup extensions, which should now be blocked.

curl -I http://example.com/backup/database.bak

6. Preventive Measures and Monitoring

Update security baselines and implement checks in CI pipelines.

• Baselines: Update your web server security baseline to include restrictions on accessing files with common backup extensions.
• Pipelines: Add static analysis tools (SAST) or vulnerability scanners to your CI/CD pipeline to identify insecure file storage configurations.
• Asset and patch process: Review web server configurations regularly as part of a standard asset management process.

7. Risks, Side Effects, and Roll Back

Incorrectly configured access controls could block legitimate files.

• Roll back: Restore the previous web server configuration from backup. Revert any changes made to .htaccess files or other configuration settings.

8. References and Resources

• Vendor advisory or bulletin: http://www.nessus.org/u?8f3302c6
• NVD or CVE entry: No specific CVE is associated with this issue.
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation for configuring access controls and file restrictions (e.g., Apache .htaccess documentation).