How to remediate – Stronghold swish Search Script Information Disclosure

1. Introduction

The Stronghold swish Search Script Information Disclosure vulnerability allows a remote user to determine the web root directory path of a server running Red Hat’s Stronghold web server. This could allow an attacker to gain further information about the system, potentially leading to more serious attacks. Systems affected are those running Stronghold with the sample script ‘swish’ enabled. Confidentiality is most at risk due to exposure of internal paths and potential system details.

2. Technical Explanation

The vulnerability occurs because the ‘swish’ script reveals the full path to the webroot directory when a request is sent to it. An attacker does not need any authentication or special privileges to exploit this issue. The script appears to also display system-specific information in its HTML output.

• Root cause: The swish script includes the server’s web root path directly in its response without sanitisation.
• Exploit mechanism: An attacker sends a simple HTTP request to the swish script, and examines the returned HTML source code for the webroot directory path. For example, accessing http://example.com/swish will likely reveal the server’s root directory.
• Scope: Red Hat Stronghold web servers using the sample ‘swish’ script are affected. Specific versions were not provided in the available information.

3. Detection and Assessment

You can confirm vulnerability by checking for the presence of the swish script, then examining its output. A thorough method involves sending a request to the script and analysing the response.

• Quick checks: Check if the swish script exists in your webroot directory using a file listing tool or command line interface.
• Scanning: Nessus plugin ID 4785 may detect this vulnerability, but results should be verified manually.
• Logs and evidence: Web server access logs will show requests to the swish script. Examine the HTML responses for the webroot path.

ls -l /path/to/webroot/swish

4. Solution / Remediation Steps

The recommended solution is to remove the vulnerable script from your server. This is a straightforward fix with minimal risk.

4.1 Preparation

• The only dependency is access to the web server’s file system. A roll back plan involves restoring the backed-up webroot directory.

4.2 Implementation

1. Step 1: Delete the swish script from your webroot directory using a file manager or command line tool. For example: rm /path/to/webroot/swish.

4.3 Config or Code Example

Before

# File exists in webroot directory: /path/to/webroot/swish

After

# File no longer present in webroot directory.

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of issue. Least privilege reduces the impact if exploited, and regular code reviews can identify insecure configurations like this one.

• Practice 1: Least privilege – limit access to webroot directories to only necessary users and services.
• Practice 2: Secure defaults – avoid deploying sample scripts in production environments.

4.5 Automation (Optional)

# Example Bash script to remove swish from all webroots:
# WARNING: This will delete files! Test thoroughly before use.
# find /var/www -name "swish" -type f -delete

5. Verification / Validation

• Post-fix check: Attempt to access http://example.com/swish. You should receive a 404 Not Found error or similar.
• Re-test: Repeat the earlier detection method (listing files in the webroot) and confirm that swish is no longer present.
• Monitoring: Monitor web server access logs for any unexpected errors related to missing files or scripts.

curl -I http://example.com/swish

6. Preventive Measures and Monitoring

Update security baselines to exclude unnecessary sample scripts, and incorporate checks in your deployment pipelines to prevent similar issues. Regular patch reviews are also important.

• Baselines: Update a web server security baseline or policy to disallow the use of sample scripts in production environments.
• Pipelines: Add static code analysis (SAST) tools to your CI/CD pipeline to identify insecure configurations like hardcoded paths.
• Asset and patch process: Implement a regular review cycle for website files and configurations, including checking for unnecessary or outdated scripts.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the webroot directory from your backup.

8. References and Resources

• Vendor advisory or bulletin: SecurityFocus BID 4785