How to remediate – Lighttpd Default Index Page

1. Introduction

The Lighttpd Default Index Page vulnerability refers to the presence of the default index page served by a Lighttpd web server. This can expose sensitive information, such as server root and installation paths, to unauthenticated attackers. This could lead to information disclosure, potentially aiding in further attacks against the system. Confidentiality is most at risk.

2. Technical Explanation

The vulnerability occurs because Lighttpd does not remove or replace its default index page after installation. An attacker can simply access the web server via HTTP/HTTPS to view this page and extract potentially sensitive information about the system’s configuration. There is no authentication required for exploitation. For example, an attacker could use a web browser to navigate to http:///index.html and view the default page.

• Exploit mechanism: An attacker sends an HTTP request to the server’s root directory, retrieving the default index page.
• Scope: Lighttpd web servers are affected by this issue.

3. Detection and Assessment

To confirm vulnerability, check for the presence of the default index page. A thorough method involves attempting to access it via a web browser.

• Quick checks: Access the server’s root directory in a web browser (e.g., http:///index.html). If the default Lighttpd index page is displayed, the system is vulnerable.
• Scanning: Nessus plugin ID 10423 can detect this vulnerability. This is an example only.
• Logs and evidence: Web server access logs may show requests for index.html from attackers or internal users.

curl -I http:///index.html

4. Solution / Remediation Steps

Remove the default index page to mitigate this vulnerability. The steps below outline how to achieve this.

4.1 Preparation

• No dependencies exist. Changes should be made during a maintenance window if possible.

4.2 Implementation

1. Step 1: Delete the default index page file. Use the command rm /var/www/index.html (the exact path may vary depending on your installation).

4.3 Config or Code Example

Before

ls /var/www/index.html

After

ls /var/www/  # index.html should not be listed.

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Secure defaults are important, as is regular configuration reviews.

• Practice 1: Implement secure defaults by removing unnecessary files and configurations during installation.
• Practice 2: Conduct regular configuration reviews to identify and remove any default or insecure settings.

4.5 Automation (Optional)

#!/bin/bash
# Check if index.html exists
if [ -f /var/www/index.html ]; then
  # Remove the file
  rm /var/www/index.html
  echo "Removed default index.html"
else
  echo "Default index.html does not exist."
fi

5. Verification / Validation

Confirm that the fix has been applied by attempting to access the default index page again. A negative test involves verifying it no longer exists.

• Post-fix check: Access http:///index.html in a web browser. You should receive a “404 Not Found” error or similar, indicating the file is no longer present.
• Re-test: Repeat the quick check from Section 3. The default index page should not be displayed.
• Monitoring: Monitor web server access logs for any attempts to access index.html, which could indicate ongoing reconnaissance activity.

curl -I http:///index.html # Should return a 404 error.

6. Preventive Measures and Monitoring

Update security baselines to include the removal of default files. Implement automated checks in CI/CD pipelines to prevent this issue from recurring.

• Pipelines: Add a check within your CI/CD pipeline that verifies the absence of default files, such as index.html, during deployment.
• Asset and patch process: Review system configurations regularly for any deviations from security standards.

7. Risks, Side Effects, and Roll Back

Removing the index page should not cause service disruption if it is the only change made. However, ensure you have a backup of your configuration files in case of unexpected issues.

• Roll back: Restore the backed-up Lighttpd configuration files to revert any changes made.

8. References and Resources

• Vendor advisory or bulletin: http://redmine.lighttpd.net/projects/lighttpd/wiki/TutorialConfiguration