WebDAV Assessment and Exploitation: A Technical Guide for Enterprise Security

A technical guide for security pros on WebDAV penetration testing, vulnerability assessment, exploitation workflows, and server hardening.

1. Introduction to WebDAV Architecture and Attack Surface

Web Distributed Authoring and Versioning (WebDAV) extends the Hypertext Transfer Protocol (HTTP) to facilitate collaborative editing and management of files on remote web servers. Defined primarily in RFC 4918, WebDAV transforms the web from a read-only medium into a read-write platform, effectively functioning as a network file system over HTTP.

Protocol Design and HTTP Extensions

WebDAV operates by introducing a set of HTTP methods and headers that allow clients to perform remote file system operations. Unlike standard HTTP, which focuses on GET and POST, WebDAV introduces verbs that manipulate state and properties.

Method	Function	Security Implication
`PROPFIND`	Retrieves properties (metadata) for a resource.	Can disclose directory structures and file attributes.
`PROPPATCH`	Changes and deletes multiple properties on a resource.	Potential for metadata tampering.
`MKCOL`	Creates collections (directories).	Unrestricted usage allows attackers to alter server structure.
`COPY` / `MOVE`	Duplicates or relocates resources.	Can bypass access controls or facilitate file overwrite attacks.
`LOCK` / `UNLOCK`	Controls write access to resources.	Improper implementation leads to Denial of Service (DoS) by locking resources indefinitely.
`PUT`	Uploads resources.	Critical risk; allows execution of arbitrary code (webshells) if not restricted.
`DELETE`	Removes resources.	Data loss and service disruption.

Enterprise Deployment and Attack Surface

WebDAV runs on standard HTTP ports (TCP 80 and 443), making it particularly elusive to traditional firewall rules that permit web traffic. It is frequently deployed in:

Legacy Content Management Systems (CMS): For file uploads.
Version Control Systems: Subversion (SVN) often utilizes WebDAV.
Enterprise File Sharing: As a backend for calendar and contact synchronization (CalDAV/CardDAV).
Microsoft Sharepoint & IIS: Extensive native support.

The Risk Profile: WebDAV expands the enterprise attack surface by exposing file system logic to the web. The primary risks include Arbitrary File Upload (RCE), Authentication Bypass, and Information Disclosure. Because it is often enabled by default or forgotten during server hardening, it represents a high-impact, low-complexity entry point for attackers.

2. Assessment Environment Architecture

To accurately simulate an enterprise scenario, a dual-node architecture is required. This environment isolates testing traffic and allows for the observation of server-side logs during exploitation attempts.

Network Isolation and Topology

The assessment environment consists of two distinct zones:

The Attack Node: A penetration testing distribution (e.g., Kali Linux) equipped with clients like cadaver, davtest, and hydra.
The Target Node: A standard enterprise Linux build (e.g., Ubuntu Server) running the Apache HTTP Server with mod_dav.

User Provisioning and Privilege Model

The security of the WebDAV service relies heavily on the underlying operating system's privilege model. Adhering to the Principle of Least Privilege (PoLP) is mandatory.

Secure Account Creation: Service accounts should be created without login shells to prevent lateral movement if the service is compromised.

# Create a dedicated group for web administrators
sudo groupadd webadmins

# Create a user 'webadmin' with specific group membership
sudo useradd -m -G webadmins -s /bin/bash webadmin

# Enforce password complexity (example via chpasswd for automation context)
echo "webadmin:S3cur3P@ssw0rd!" | sudo chpasswd

Purpose: Establishes a non-root user for managing web content.
Security Implication: Isolates web content management from system administration.

Sudo Configuration: Administrative access is restricted via /etc/sudoers.

# Allow webadmin to restart apache without a password, but nothing else
webadmin ALL=(ALL) NOPASSWD: /usr/sbin/service apache2 restart

Purpose: Granular delegation of administrative tasks.
Security Implication: Limits the blast radius if the webadmin account is compromised.

3. Apache Implementation and Hardening

The Apache HTTP Server is the industry standard for WebDAV deployment. Proper configuration involves enabling specific modules and reducing information leakage.

Installation and Module Activation

The WebDAV functionality depends on mod_dav and mod_dav_fs.

# Update repositories and install Apache
sudo apt-get update && sudo apt-get install apache2 -y

# Enable WebDAV modules
sudo a2enmod dav
sudo a2enmod dav_fs
sudo a2enmod headers

# Restart service to apply changes
sudo systemctl restart apache2

Purpose: Installs the web server and loads the necessary shared objects for DAV operations.
Security Implication: Unnecessary modules should remain disabled to minimize the attack surface.

Server Hardening

Default Apache configurations often leak version information. Hardening requires modifying security.conf.

# /etc/apache2/conf-available/security.conf
ServerTokens Prod
ServerSignature Off
FileETag None

Purpose: ServerTokens Prod restricts the header to "Apache" without version numbers.
Security Implication: Prevents attackers from easily identifying specific CVEs associated with version numbers during reconnaissance.

4. Vulnerable Deployment Scenarios

This section details the configuration of a misconfigured WebDAV instance to simulate a vulnerable enterprise environment.

Directory Structure and Permissions

The target directory requires write permissions for the HTTP daemon user (www-data).

# Create the WebDAV root directory
sudo mkdir -p /var/www/html/webdav

# Change ownership to the web user
sudo chown www-data:www-data /var/www/html/webdav

# Set permissions allows owner write, group read/execute
sudo chmod 755 /var/www/html/webdav

Purpose: Establishes the physical location for files.
Security Implication: If permissions are too loose (e.g., 777), local users could compromise web data.

Anonymous Access Configuration (The Vulnerability)

The following VirtualHost configuration explicitly permits unrestricted access, a common misconfiguration in internal networks.

<VirtualHost *:80>
    DocumentRoot /var/www/html/webdav
    <Directory /var/www/html/webdav>
        DAV On
        Require all granted
    </Directory>
</VirtualHost>

Analysis: The DAV On directive enables the protocol. Require all granted removes authentication requirements.
Risk: Any user with network access can read, delete, or overwrite files, and potentially upload executable code.

Sample Sensitive Data

To simulate risk, populate the directory with dummy sensitive data.

echo "CONFIDENTIAL: Q3 Financial Projections" | sudo tee /var/www/html/webdav/financials.txt

Purpose: Provides a target for exfiltration testing.

5. Production Configuration and Authentication

To remediate the vulnerability, Digest Authentication is implemented. Digest is preferred over Basic authentication as it prevents credentials from being transmitted in cleartext.

Digest Authentication Setup

# Create the password file for user 'admin' in realm 'WebDAV-Realm'
sudo htdigest -c /etc/apache2/users.password "WebDAV-Realm" admin

Purpose: Generates a hash of the user, realm, and password.

Secured Apache Configuration

The configuration is updated to enforce authentication and restrict dangerous methods.

<Directory /var/www/html/webdav>
    DAV On
    AuthType Digest
    AuthName "WebDAV-Realm"
    AuthUserFile /etc/apache2/users.password
    Require valid-user

    # Limit methods: Allow Read/Write but block execution (conceptual)
    <LimitExcept GET POST PUT DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
        Require all denied
    </LimitExcept>
</Directory>

Security Impact: Access is now restricted to authenticated users. The LimitExcept directive can be used to further refine allowed verbs.

6. Penetration Testing Workflow

A professional assessment follows a structured methodology: Reconnaissance, Enumeration, Exploitation, and Post-Exploitation.

Phase 1: Reconnaissance and Identification

The objective is to identify WebDAV services and supported methods.

Nmap Scripting Engine (NSE):

nmap -p 80 --script http-webdav-scan <target_ip>

Output:

PORT   STATE SERVICE
80/tcp open  http
| http-webdav-scan:
|   Public Options: OPTIONS, TRACE, GET, HEAD, POST, DELETE, PUT...
|   WebDAV type: Unknown
|_  Server Date: ...

Analysis: The presence of PUT, DELETE, and PROPFIND in the Public Options header confirms WebDAV functionality.

Phase 2: Vulnerability Enumeration with `davtest`

davtest automates the testing of file upload permissions and execution capabilities.

davtest -url http://<target_ip>/webdav/

Expected Output:

SUCCEED:        http://<target_ip>/webdav/davtest_text.txt
FAIL:           http://<target_ip>/webdav/davtest_php.php

Analysis: This tool attempts to upload files with various extensions (.php, .txt, .jsp) and then requests them to see if they execute. A success on .php indicates a Critical RCE vulnerability.

Phase 3: Interactive Exploitation with `cadaver`

cadaver provides a command-line interface similar to FTP for interacting with WebDAV.

cadaver http://<target_ip>/webdav/
dav:/webdav/> put shell.php
dav:/webdav/> move confidential.docx /tmp/stolen.docx

Operational Use: Manual verification of write access and manipulation of file structures.

Phase 4: Credential Testing (Hydra)

If authentication is present, hydra targets the specific protocol.

hydra -L users.txt -P passwords.txt -s 80 <target_ip> http-get /webdav/

Analysis: Tests weak credentials against the HTTP Basic/Digest authentication mechanism protecting the WebDAV resource.

7. Interactive WebDAV Client Deep Dive

Understanding client semantics is crucial for manual verification. cadaver is the standard compliant client.

Command Reference

Command	WebDAV Method	Description
`ls`	`PROPFIND`	Lists collection contents.
`get <file>`	`GET`	Downloads a resource.
`put <file>`	`PUT`	Uploads a local file to the server.
`move <src> <dst>`	`MOVE`	Renames or moves a file on the server.
`mkcol <dir>`	`MKCOL`	Creates a new directory.
`lock <file>`	`LOCK`	Locks a resource, preventing others from modifying it.

Recursive Operations: Clients like cadaver support mput and mget for bulk operations, allowing an attacker to exfiltrate entire directories or flood the server with files, potentially causing storage exhaustion.

8. Professional Assessment Methodology (MITRE ATT&CK)

Integrating findings into the MITRE ATT&CK framework allows for standardized risk communication.

Relevant TTPs (Tactics, Techniques, and Procedures):

Initial Access (TA0001):
- T1190 Exploit Public-Facing Application: Utilizing unsecured WebDAV PUT methods to upload malicious payloads.
Credential Access (TA0006):
- T1110 Brute Force: Targeting WebDAV authentication realms.
Lateral Movement (TA0008):
- T1021.002 SMB/Windows Admin Shares: While distinct, WebDAV can be mounted as a network drive, facilitating movement similar to SMB.
Exfiltration (TA0010):
- T1041 Exfiltration Over C2 Channel: Using the WebDAV protocol itself to transfer stolen data.

9. Risk Analysis and Scoring

When reporting WebDAV vulnerabilities, accurate scoring via the Common Vulnerability Scoring System (CVSS) is essential.

Scenario: Anonymous Write Access

Vector: Network.
Complexity: Low.
Privileges: None.
Confidentiality/Integrity/Availability: High.
CVSS v3.1 Estimate: 9.8 (Critical)
Business Impact: Total loss of data integrity on the affected share; potential for full server compromise if script execution is enabled; reputational damage due to defacement.

Threat Modeling

Threat Actor: External Opportunist or Insider Threat.
Asset: Corporate File Repository.
Impact: Data leakage, Ransomware deployment (via overwriting files with encrypted versions).

10. Defensive Hardening and Detection

Defense requires a layered approach combining prevention, restriction, and monitoring.

Detection Strategies

Log Analysis: Monitor Apache access.log for unusual methods (PROPFIND, MKCOL) originating from non-standard IP ranges.
SIEM Rules: Trigger alerts on high-frequency PUT or DELETE operations (indicative of ransomware or bulk exfiltration).
Web Application Firewall (WAF): Configure WAF rules to block PUT methods to specific directories or block executable file extensions (e.g., *.php, *.exe, *.sh) in upload streams.

Hardening Model

Disable if Unused: If WebDAV is not a business requirement, ensure mod_dav is disabled.
Restrict Methods: Use <LimitExcept> to strictly control which HTTP verbs are permitted.
Strong Authentication: Enforce MFA or strong Digest authentication. Never use Basic auth without TLS/SSL.
Execution Prevention: Configure the web server to force downloaded files to be treated as text, or disable the script engine for the WebDAV upload directory.
```
<Directory /var/www/html/webdav>
    php_admin_flag engine Off
</Directory>
```

11. Reporting Framework

A professional report must decouple technical findings from executive impact.

Executive Summary Structure

Assessment Scope: Definition of the WebDAV instance tested.
Strategic Risk: High-level explanation of the risk (e.g., "Unrestricted file access could lead to data theft...").
Key Recommendation: "Immediately disable anonymous access and implement strong authentication."

Technical Evidence Guidance

Proof of Concept: Screenshot of the davtest output showing successful file upload.
Reproduction Steps: Exact cadaver or curl commands used to replicate the finding.
Remediation: Specific Apache configuration snippets (as shown in Section 5) to fix the issue.

12. Conclusion

WebDAV remains a powerful but frequently mishandled protocol in enterprise environments. Its capability to blur the line between a web server and a file system makes it a high-value target for attackers. By understanding the underlying architecture, leveraging standard enumeration tools like davtest and nmap, and applying rigorous hardening configurations, security professionals can effectively mitigate the risks associated with distributed authoring. The transition from a vulnerable state to a secured posture requires not just patch management, but a fundamental understanding of HTTP method restrictions and access control logic.