How to remediate – WebDAV

1. Introduction

WebDAV, or Web Distributed Authoring and Versioning, is a method for managing files on a web server. It allows users to access a webserver as if it were a network share. A successful attack could allow an attacker to harvest information from directories or upload malicious files, potentially compromising the server’s confidentiality, integrity, and availability. This vulnerability typically affects any system running a WebDAV service.

2. Technical Explanation

The core issue is that the WebDAV facility is enabled on the affected page. Attackers exploit this by sending specific HTTP methods (`PROPFIND`, `PROPPATCH`) to gather information or manipulate files. Exploitation requires network access to the WebDAV service and no authentication may be required if not configured correctly.

• Root cause: The server responds to WebDAV requests, indicating the facility is active.
• Exploit mechanism: An attacker sends `PROPFIND` requests to enumerate files and directories. They could then attempt to upload a malicious file (e.g., a web shell) using `PUT`.
• Scope: Any server running a WebDAV service, including Apache, IIS, and Nginx configurations with WebDAV modules enabled.

3. Detection and Assessment

Confirming vulnerability involves checking if the server responds to standard WebDAV requests. A thorough assessment requires testing all exposed directories for WebDAV functionality.

• Quick checks: Use `curl` to check HTTP method responses. For example, `curl -v –head http://yourserver/webdavpath`. Look for support of methods like PROPFIND and PROPPATCH in the response headers.
• Scanning: Nessus plugin ID 10384 or OpenVAS NVTs related to WebDAV may identify exposure as examples only.
• Logs and evidence: Check web server access logs for requests containing `PROPFIND`, `PROPPATCH`, `PUT`, `DELETE` methods against the affected directories.

curl -v --head http://yourserver/webdavpath

4. Solution / Remediation Steps

The primary solution is to disable WebDAV if it’s not required. If needed, secure it with SSL/TLS and strong authentication.

4.1 Preparation

• Ensure you have access to revert the configuration if necessary. A roll back plan is to restore from backup or redeploy the previous config.
• Consider a change window and approval process, especially for production systems.

4.2 Implementation

1. Step 1: Determine if WebDAV functionality is required by any applications.
2. Step 2: If not required, disable the WebDAV module in your web server configuration. For Apache, this may involve commenting out or removing relevant lines from `httpd.conf` or virtual host files.
3. Step 3: Restart the web server to apply changes.
4. Step 4: If WebDAV is required, ensure SSL/TLS is enabled for all WebDAV connections.
5. Step 5: Implement strong authentication (e.g., username/password with multi-factor authentication) for WebDAV access.

4.3 Config or Code Example

Before

LoadModule dav_module modules/mod_dav.so
<Directory /var/www/webdav>
    Dav On
</Directory>

After

#LoadModule dav_module modules/mod_dav.so
#<Directory /var/www/webdav>
#    Dav On
#</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can mitigate WebDAV risks. Least privilege limits the impact of a compromise, while input validation prevents malicious file uploads. Secure defaults ensure that WebDAV is disabled unless explicitly enabled with appropriate security measures.

• Practice 1: Implement least privilege to restrict access to WebDAV directories and resources.
• Practice 2: Use input validation on any files uploaded through WebDAV to prevent malicious code execution.

4.5 Automation (Optional)

# Example Ansible task to disable mod_dav in Apache configuration
- name: Disable mod_dav
  lineinfile:
    path: /etc/apache2/mods-enabled/dav.conf
    regexp: '^LoadModule dav_module'
    state: absent
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Run `curl -v –head http://yourserver/webdavpath` again. The server should return an error (e.g., 404 Not Found or 403 Forbidden) instead of responding with WebDAV headers.
• Re-test: Repeat the quick check from section 3 to confirm that WebDAV methods are no longer supported.
• Smoke test: Verify that other web server functionality remains operational (e.g., accessing static pages).
• Monitoring: Monitor web server logs for any unexpected errors related to file access or WebDAV attempts.

curl -v --head http://yourserver/webdavpath

6. Preventive Measures and Monitoring

Regular security baselines should include checks for unnecessary services like WebDAV. CI/CD pipelines can incorporate static analysis to identify insecure configurations. A sensible patch cycle ensures timely updates to address known vulnerabilities.

• Baselines: Update your security baseline or policy to explicitly disable WebDAV unless required, aligning with CIS controls if applicable.
• Pipelines: Add checks in your CI/CD pipeline to scan for insecure WebDAV configurations during deployment.
• Asset and patch process: Implement a regular review cycle (e.g., monthly) for web server configurations and security patches.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Disabling WebDAV may impact applications needing file management functionality. Mitigation is to restore the original configuration if issues arise.
• Roll back: Restore the web server configuration from backup, or redeploy the previous version of the configuration files. Restart the web service.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s website for specific WebDAV security guidance.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2017-9805
• Product or platform documentation relevant to the fix: Refer to your web server’s official documentation for instructions on disabling and configuring WebDAV.