How to remediate – WebPagetest Detection

1. Introduction

WebPagetest Detection indicates that a web page performance tool is running on a remote web server. This can present an information disclosure risk as the tool may expose internal website details and configurations to anyone with internet access. Systems commonly affected are those hosting public websites or web applications, particularly development or testing environments. A likely impact is low confidentiality, integrity, and availability due to potential data exposure.

2. Technical Explanation

The vulnerability occurs because the WebPagetest tool is accessible from a network. This tool, written in PHP, is designed for website performance testing but can reveal server information if not properly secured. An attacker could use this access to gather details about the web server’s configuration and potentially identify other vulnerabilities. There is no known CVE associated with simply running the tool; however, misconfigurations or outdated versions of WebPagetest itself may be subject to separate exploits.

• Root cause: The WebPagetest installation is publicly accessible without appropriate authentication or access controls.
• Exploit mechanism: An attacker accesses the WebPagetest interface via a web browser and runs tests against the target website, examining the results for sensitive information. For example, accessing http://example.com/webpagetest may reveal server details.
• Scope: Any publicly accessible web server running WebPagetest is affected. Specific versions are not directly in scope unless they contain known vulnerabilities themselves.

3. Detection and Assessment

Confirming the presence of WebPagetest can be done through simple network checks or by examining website responses. Thorough assessment involves reviewing the tool’s configuration.

• Quick checks: Attempt to access the default WebPagetest URL, such as http://example.com/webpagetest. A login page or test interface indicates its presence.
• Scanning: Nessus plugin ID 163849 can detect publicly accessible WebPagetest instances. This is an example only and may require updates.
• Logs and evidence: Examine web server access logs for requests to the WebPagetest directory (e.g., /webpagetest). Look for patterns associated with test runs.

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

4. Solution / Remediation Steps

The primary solution is to restrict access to the WebPagetest installation or remove it if no longer needed. These steps aim to minimise information disclosure.

4.1 Preparation

• Ensure you have appropriate permissions to modify web server configuration files. A roll back plan involves restoring the original configuration file or restarting the web service.
• Change windows are typically low risk, requiring approval only if the WebPagetest instance is used in production testing.

4.2 Implementation

1. Step 1: Configure your web server to require authentication for access to the /webpagetest directory. This can be done using .htaccess files (Apache), or equivalent configuration options for other servers.
2. Step 2: Restrict access to specific IP addresses if only internal users need to use WebPagetest.
3. Step 3: If WebPagetest is no longer required, remove the installation directory and any associated configurations from the web server.

4.3 Config or Code Example

Before

# Apache .htaccess file - allowing open access
<Directory /webpagetest>
    Require all granted
</Directory>

After

# Apache .htaccess file - requiring authentication
<Directory /webpagetest>
    Require valid-user
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue and similar information disclosures.

• Practice 1: Least privilege – restrict access to sensitive tools and directories to only authorized users.
• Practice 2: Secure defaults – configure new installations with strong authentication and limited access by default.

4.5 Automation (Optional)

# Example Ansible task to add .htaccess file
- name: Restrict WebPagetest Access
  copy:
    src: webpagetest.htaccess
    dest: /path/to/webserver/.htaccess
    owner: root
    group: www-data
    mode: 0644

5. Verification / Validation

Confirm the fix by attempting to access WebPagetest without authentication and verifying that access is denied.

• Post-fix check: Attempt to access http://example.com/webpagetest. You should be prompted for a username and password.
• Re-test: Re-run the quick check from section 3; it should no longer display the WebPagetest interface without authentication.
• Monitoring: Monitor web server logs for failed login attempts to the /webpagetest directory, which could indicate unauthorized access attempts.

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

6. Preventive Measures and Monitoring

Regular security assessments and baseline configurations can help prevent this issue.

• Baselines: Update your web server security baseline to include restrictions on access to internal tools like WebPagetest.
• Pipelines: Incorporate static analysis (SAST) into your CI/CD pipeline to identify publicly accessible directories or files that should be protected.
• Asset and patch process: Regularly review the list of installed software on web servers and remove any unnecessary components.

7. Risks, Side Effects, and Roll Back

Restricting access may impact legitimate users who require WebPagetest functionality.

• Risk or side effect 1: Legitimate users may be unable to access WebPagetest if authentication is not properly configured. Mitigation: Provide clear instructions for accessing the tool with appropriate credentials.
• Roll back: Remove the added .htaccess file or revert the web server configuration to its previous state. Restart the web service if necessary.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: https://www.webpagetest.org/