How to remediate – Publicly writable directory

1. Introduction

A publicly writable directory allows anyone with network access to upload files to a web server, potentially including malicious code. This poses a significant risk to confidentiality, integrity and availability as attackers can modify website content, steal sensitive data, or take complete control of the server. Web servers are commonly affected, particularly those used for development or testing purposes. Impact is high; successful exploitation leads to full remote compromise.

2. Technical Explanation

The HTTP `PUT` method allows clients to upload files directly to the webserver’s file system. During application development, this can be useful but often lacks security checks. Attackers exploit this by uploading server-side executable code like PHP or ASP scripts into a publicly accessible directory on the server. The scanner confirmed that the affected path accepts `PUT` requests and successfully uploaded a test file which was then retrieved via HTTP GET.

• Root cause: Lack of filtering on files uploaded using the HTTP `PUT` method.
• Exploit mechanism: An attacker sends an HTTP `PUT` request containing malicious code to the affected directory, overwriting existing files or creating new ones. They then access the uploaded file via a web browser to execute it. For example, uploading a PHP shell script named ‘backdoor.php’ to /var/www/html/uploads/.
• Scope: Web servers supporting the HTTP `PUT` method, particularly those running IIS and Apache.

3. Detection and Assessment

Confirming vulnerability involves checking if the server responds to `PUT` requests on web-accessible paths. A thorough assessment includes attempting to upload a test file and verifying its accessibility.

• Quick checks: Use curl or wget to check HTTP method support. For example, curl -X PUT http://example.com/uploads/test.txt should return a 200 OK response if `PUT` is enabled.
• Scanning: Nessus plugin ID 34865 can identify publicly writable directories. OpenVAS also has relevant checks. These are examples only and may require tuning.
• Logs and evidence: Web server access logs should be checked for HTTP `PUT` requests to web-accessible paths. Look for unusual file uploads or attempts to write to sensitive areas of the filesystem.

curl -X PUT http://example.com/uploads/test.txt -d "Test content"

4. Solution / Remediation Steps

The primary solution is disabling the `PUT` method globally where possible. If required for application functionality, implement strict access controls and file system permissions.

4.1 Preparation

• Stop the web server service (e.g., Apache or IIS) to ensure consistent configuration updates. Roll back by restoring the backup and restarting the service.
• Changes require approval from the application owner, especially if `PUT` is used for legitimate purposes.

4.2 Implementation

1. Step 1: Disable the HTTP `PUT` method in the web server configuration file. For Apache, edit the httpd.conf or .htaccess file and add Options -Method PUT to the relevant directory block.
2. Step 2: Restart the web server service to apply the changes. For example, on Ubuntu/Debian use sudo systemctl restart apache2.
3. Step 3: If `PUT` is required for REST APIs, configure access controls to allow only authorised clients (e.g., based on IP address or SSL/TLS authentication).

4.3 Config or Code Example

Before

<Directory /var/www/html/uploads>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

After

<Directory /var/www/html/uploads>
Options -Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

4.4 Security Practices Relevant to This Vulnerability

• Practice 1: Least privilege – restrict access rights to the minimum necessary for each user and service, limiting potential damage from exploitation.
• Practice 2: Input validation – thoroughly validate all uploaded files to ensure they conform to expected types and sizes, preventing malicious code execution.

4.5 Automation (Optional)

# Example Ansible task to disable PUT method on Apache
- name: Disable HTTP PUT method
  line:
    path: /etc/apache2/sites-available/000-default.conf
    regexp: '^Options Indexes FollowSymLinks'
    line: 'Options -Indexes FollowSymLinks'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Use curl to attempt a PUT request; expected output should be “405 Method Not Allowed”. For example, curl -X PUT http://example.com/uploads/test.txt
• Re-test: Repeat the initial vulnerability scan and confirm that the publicly writable directory is no longer detected.
• Smoke test: Verify core website features (e.g., browsing pages, submitting forms) still function as expected.

curl -X PUT http://example.com/uploads/test.txt

6. Preventive Measures and Monitoring

Update security baselines to include disabling unnecessary HTTP methods. Implement regular vulnerability scanning during development and deployment. Maintain a sensible patch cycle for web server software.

• Baselines: Update your CIS benchmark or hardening guide to explicitly disable the `PUT` method unless required.
• Asset and patch process: Review web server configuration changes regularly, and apply security patches within 30 days of release.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Unexpected application errors – monitor logs for new errors following deployment.
• Roll back: Restore the original web server configuration file and restart the service.

8. References and Resources

• Vendor advisory or bulletin: Check your specific web server vendor’s documentation (e.g., Apache, IIS) for guidance on disabling HTTP methods.
• NVD or CVE entry: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
• Product