How to remediate – .bash_history Files Disclosed via Web Server

1. Introduction

The vulnerability “.bash_history Files Disclosed via Web Server” refers to publicly accessible .bash_history files hosted on a remote web server. These files can contain sensitive information, such as usernames, commands executed, and potentially passwords or API keys. This poses a risk to the confidentiality of systems and data. Affected systems are typically those running web servers that host user-generated content or configuration files without proper access controls. Impact is likely to be high on confidentiality if sensitive data is present, low on integrity unless files are modified, and medium on availability if server resources are impacted by malicious activity following a breach.

2. Technical Explanation

The root cause of this vulnerability is the improper configuration of web servers allowing access to .bash_history files. These files store command history for user sessions and are often located in user home directories with permissive permissions. An attacker can exploit this by directly requesting the file via a web browser or using automated tools to scan for accessible .bash_history files. Preconditions include a publicly accessible web server hosting these files, and no authentication required to access them. For example, an attacker could simply navigate to http://example.com/~user/.bash_history in their web browser to view the file’s contents.

• Root cause: Web server configuration allows directory listing or direct access to .bash_history files without authentication.
• Exploit mechanism: An attacker directly requests the .bash_history file via HTTP/HTTPS.
• Scope: Linux systems running web servers (Apache, Nginx) are commonly affected.

3. Detection and Assessment

To confirm if a system is vulnerable, first check for publicly accessible .bash_history files. A thorough method involves scanning the entire web server file system for these files with overly permissive permissions.

• Quick checks: Use a web browser to attempt access to common paths like http://example.com/~user/.bash_history or http://example.com/home/user/.bash_history.
• Scanning: Nessus vulnerability ID 16058 can detect this issue, but results should be verified manually.
• Logs and evidence: Web server access logs may show requests for .bash_history files. Look for HTTP status codes 200 (OK) indicating successful retrieval.

curl -I http://example.com/~user/.bash_history

4. Solution / Remediation Steps

To fix this issue, ensure that .bash_history files do not contain sensitive information and are only accessible to authorized users.

4.1 Preparation

• No services need to be stopped, but testing should occur in a non-production environment first. Roll back plan: Restore the backed-up configuration files.
• Changes may require a short maintenance window depending on server load and complexity. Approval from the system administrator is recommended.

4.2 Implementation

1. Step 1: Restrict access to .bash_history files using web server configuration. For Apache, add the following to your virtual host configuration file: <FilesMatch ".bash_history$"> Order deny,allow Deny from all </FilesMatch>
2. Step 2: Ensure .bash_history files have appropriate permissions (e.g., 600) so only the owner can read and write to them. Use the command chmod 600 ~/.bash_history for each user account.
3. Step 3: Restart the web server service to apply the changes. For Apache, use the command sudo systemctl restart apache2.

4.3 Config or Code Example

Before

# No specific configuration for .bash_history files

After

<FilesMatch ".bash_history$"> Order deny,allow Deny from all </FilesMatch>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – limit user access rights to only what is necessary, reducing the impact if an account is compromised.
• Practice 2: Secure defaults – configure systems with restrictive permissions and access controls by default.

4.5 Automation (Optional)

An Ansible playbook can automate permission changes across multiple servers.

---
- hosts: webservers
  tasks:
    - name: Set .bash_history file permissions
      file:
        path: /home/{{ item }}/.bash_history
        owner: "{{ item }}"
        mode: 0600
      with_items: "{{ users }}"

5. Verification / Validation

• Post-fix check: Use curl -I http://example.com/~user/.bash_history and verify that the HTTP status code is 403 (Forbidden).
• Re-test: Re-run the quick check from Section 3 to confirm access is denied.
• Smoke test: Verify that users can still log in and execute commands via SSH without issue.
• Monitoring: Monitor web server logs for failed requests attempting to access .bash_history files (HTTP status code 403).

curl -I http://example.com/~user/.bash_history

6. Preventive Measures and Monitoring

Regularly review system configurations and implement security baselines to prevent similar issues.

• Baselines: Update your security baseline or policy to include a requirement for restrictive permissions on .bash_history files (e.g., CIS control 1.2).
• Asset and patch process: Implement a regular patch review cycle to ensure systems are up-to-date with the latest security fixes.

7. Risks, Side Effects, and Roll Back

Incorrectly configuring web server access controls could lead to service disruptions.

• Risk or side effect 2: Restarting the web server may cause brief downtime. Mitigation: Schedule changes during off-peak hours.
• Roll back: Restore the backed-up web server configuration file and restart the service.

8. References and Resources

Links to resources related to this specific vulnerability.

• Vendor advisory or bulletin: No specific vendor advisory available for this general issue, but refer to your web server documentation.
• NVD or CVE entry: CVE-2016-5195 (example related vulnerability)
• Product or platform documentation relevant to the fix: Apache Access Control Documentation