How to remediate – Web Accessible Backups

1. Introduction

The Web Accessible Backups vulnerability means a web server is making archive files available publicly that may contain backups or sensitive data. This poses a risk to confidentiality as attackers could access confidential information. It affects any web server hosting user-uploaded content or running applications with backup functionality, particularly those without proper access controls. Impact on confidentiality is likely high if sensitive data is present; integrity and availability are less directly affected but could be compromised during exploitation.

2. Technical Explanation

The root cause is typically insufficient access control to archive files stored on the web server. Attackers can directly request these files via HTTP or HTTPS. Exploitation requires only a valid internet connection and knowledge of the file paths. There isn’t a specific CVE currently associated with this general issue, but it falls under CWE-598 (Insufficient Access Control). An attacker could simply browse to https://example.com/backups/database_backup.zip if that path is accessible. Affected platforms include any operating system hosting a web server such as Linux, Windows Server, or macOS, and services like Apache, Nginx, IIS are in scope.

• Root cause: Missing or incorrect configuration of web server access controls for archive files.
• Exploit mechanism: An attacker uses a web browser or command-line tool to request the backup file directly from the web server. For example, curl https://example.com/backups/sensitive_data.tar.gz.
• Scope: Apache HTTP Server versions 2.4 and later; Nginx versions 1.0 and later; IIS 10 and later are all potentially affected if misconfigured.

3. Detection and Assessment

Confirming vulnerability involves checking for publicly accessible archive files. A quick check is to browse the web server’s file system using a web browser, looking for common backup extensions. A thorough method involves scanning the entire web server directory structure with an automated tool.

• Quick checks: Use a web browser to navigate to https://example.com/backups/ or similar paths commonly used for backups.
• Scanning: Nessus plugin ID 10423 (Web Server Files Information Disclosure) may identify accessible backup files, but results should be manually verified.

curl -I https://example.com/backups/database_backup.zip

4. Solution / Remediation Steps

Fixing this issue requires reviewing and restricting access to archive files on the web server. These steps should be performed carefully to avoid disrupting legitimate services.

4.1 Preparation

• No services need to be stopped, but monitor resource usage during testing. A roll back plan involves restoring from the earlier backup or snapshot.
• Changes should be approved by the IT security team and implemented during a scheduled maintenance window.

4.2 Implementation

1. Step 1: Identify all archive files on the web server’s file system using a command like find /var/www -name "*.zip" or equivalent for your OS.
2. Step 2: Configure the web server to deny direct access to these files. For Apache, this can be done in the .htaccess file or virtual host configuration.
3. Step 3: If archive files are needed for legitimate purposes, implement a secure download mechanism with authentication and authorization.
4. Step 4: Test the changes by attempting to access the archive files directly via a web browser. Verify that access is denied (HTTP 403 error).

4.3 Config or Code Example

Before

<Directory /var/www/backups>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

After

<Directory /var/www/backups>
    Options -Indexes FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege is crucial, limiting access to sensitive files only to authorized users and services. Input validation prevents attackers from requesting arbitrary files. Safe defaults ensure that archive files are not publicly accessible by default.

• Practice 1: Implement least privilege principles, granting only necessary permissions to web server processes and users.
• Practice 2: Use input validation on any file upload or processing functionality to prevent the storage of malicious backups.

4.5 Automation (Optional)

If using Infrastructure as Code, update your configuration management scripts to enforce access restrictions for archive files.

# Ansible example:
- name: Deny access to backup directory
  apache2_module:
    name: rewrite
    state: present
- name: Add deny rule to .htaccess file
  lineinfile:
    path: /var/www/.htaccess
    regexp: '^Require all granted'
    line: 'Require all denied'
    state: present

5. Verification / Validation

• Post-fix check: Use curl -I https://example.com/backups/database_backup.zip and expect an HTTP 403 Forbidden response.
• Re-test: Re-run the web browser test from step 3 of Detection and Assessment to confirm no archive files are accessible.
• Smoke test: Verify that users can still log in, access core application features, and submit forms as expected.
• Monitoring: Monitor web server access logs for any attempts to access archive file extensions; alert on unexpected requests.

curl -I https://example.com/backups/database_backup.zip

6. Preventive Measures and Monitoring

Update security baselines or policies to include restrictions on publicly accessible archive files. Add checks in CI/CD pipelines to prevent the deployment of misconfigured web servers. Implement a regular patch review cycle for all web server software.

• Baselines: Update your CIS benchmark or hardening guide to explicitly deny access to backup directories.
• Pipelines: Integrate SAST tools into your CI/CD pipeline to scan for insecure configurations in web server configuration files.
• Asset and patch process: Review web server software updates weekly, applying security patches promptly.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Denying access to necessary archive files may break application features that rely on them.
• Risk or side effect 2: Incorrectly configured rules could inadvertently block legitimate traffic.
• Roll back: Restore the web server configuration from backup, or revert the changes made in your Infrastructure as Code repository.