How to remediate – WS_FTP.LOG File Detected

1. Introduction

The WS_FTP.LOG File Detected vulnerability means that log files created by WS_FTP are publicly accessible on a web server. This allows anyone to view details of file transfers, including source and destination names, upload dates, and potentially sensitive information. This could lead to unauthorised access to content on the server. Confidentiality, integrity, and availability may be impacted if attackers gain knowledge of internal files or system configurations.

2. Technical Explanation

• Root cause: Incorrect file permissions allowing public access to WS_FTP log files.
• Exploit mechanism: An attacker sends an HTTP request for the WS_FTP.LOG file, which the web server serves due to incorrect configuration. For example, requesting http://example.com/WS_FTP.LOG.
• Scope: Web servers running WS_FTP are affected. Specific versions were identified in reports from 2004 but this is likely a configuration issue across multiple releases.

3. Detection and Assessment

You can confirm the vulnerability by checking if the log file is accessible via a web browser or command line tool. A thorough method involves scanning the web server for publicly readable files with the .LOG extension.

• Quick checks: Use a web browser to attempt access to http://yourserver/WS_FTP.LOG. If the file downloads, it is accessible.
• Scanning: Nessus plugin ID 30851 or OpenVAS scan for publicly writable files may identify this issue as an example.
• Logs and evidence: Web server access logs will show requests for WS_FTP.LOG if accessed.

curl -I http://yourserver/WS_FTP.LOG

4. Solution / Remediation Steps

Remove the publicly accessible WS_FTP.LOG file to prevent information disclosure. Follow these steps carefully.

4.1 Preparation

• Ensure you have appropriate permissions to delete files on the server. A roll back plan involves restoring the backup if necessary.
• A change window may be required depending on your organisation’s policies.

4.2 Implementation

1. Step 1: Connect to the web server using SSH or a similar protocol.
2. Step 2: Navigate to the directory containing the WS_FTP.LOG file. This location varies depending on your installation, but common paths include /var/log/ and /opt/WS_FTP/.
3. Step 3: Delete the WS_FTP.LOG file using the command rm WS_FTP.LOG.

4.3 Config or Code Example

Before

ls -l /var/log/WS_FTP.LOG 
-rw-r--r-- 1 root root 12345 Jan  1 00:00 WS_FTP.LOG

After

ls -l /var/log/WS_FTP.LOG
(file no longer exists)

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent this issue. Least privilege reduces the impact of a successful attack, while secure defaults minimise misconfigurations. Regular patch cadence ensures timely fixes for known vulnerabilities.

• Practice 1: Implement least privilege access control to limit who can read sensitive files.
• Practice 2: Configure secure defaults on all systems, including file permissions and web server settings.

4.5 Automation (Optional)

A simple script could be used to identify and delete exposed log files. Use caution when automating file deletion.

#!/bin/bash
find /var/log -name "WS_FTP.LOG" -type f -perm 644 -delete
echo "Removed publicly accessible WS_FTP.LOG files."

5. Verification / Validation

Confirm the fix by checking that the log file is no longer accessible via a web browser or command line tool. Perform a smoke test to ensure WS_FTP functionality remains intact.

• Post-fix check: Attempt access to http://yourserver/WS_FTP.LOG. You should receive a 404 Not Found error.
• Re-test: Repeat the quick check from Section 3. The file should no longer be downloadable.
• Smoke test: Verify that users can still upload and download files using WS_FTP.
• Monitoring: Check web server access logs for any continued requests to /WS_FTP.LOG.

curl -I http://yourserver/WS_FTP.LOG
HTTP/1.1 404 Not Found

6. Preventive Measures and Monitoring

• Baselines: Update your web server baseline to enforce restrictive permissions on all log files.
• Pipelines: Add static analysis checks in your CI/CD pipeline to identify and flag publicly writable files.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the web server configuration from the pre-change backup.

8. References and Resources

• Vendor advisory or bulletin: https://community.ipswitch.com/s/article/Log-Files
• NVD or CVE entry: No specific CVE is associated with this issue, it’s a configuration weakness.
• Product or platform documentation relevant to the fix: https://community.ipswitch.com/s/article/Log-Files