How to remediate – Web Service Description Language File Detected

1. Introduction

A Web Service Description Language (WSDL) file has been detected on a remote host. A WSDL file describes the functionality offered by a web service, typically using SOAP over HTTP. This indicates a web service is running and potentially accessible from outside your network. Successful exploitation could allow an attacker to execute commands or access sensitive data exposed through the service. Confidentiality, integrity, and availability may be impacted depending on the service’s function.

2. Technical Explanation

The presence of a WSDL file means a web service is advertised on the server. Attackers can use this to understand the service’s capabilities and attempt to exploit vulnerabilities in its implementation. Exploitation typically involves sending crafted SOAP requests to trigger flaws like remote code execution or information disclosure. Preconditions include network access to the web service endpoint and knowledge of the WSDL file’s location.

• Root cause: The server is hosting a publicly accessible WSDL file, indicating an active web service.
• Exploit mechanism: An attacker could analyse the WSDL to identify methods with potential vulnerabilities, then send malicious SOAP requests to exploit them. For example, they might attempt to inject code into input parameters.
• Scope: Any platform hosting a web service using WSDL is potentially affected, including Windows Server (IIS), Linux servers running Apache or Nginx, and cloud platforms offering web service capabilities.

3. Detection and Assessment

Confirming the presence of a WSDL file can be done quickly with a simple HTTP request. A thorough assessment involves analysing the WSDL content for potential vulnerabilities.

• Quick checks: Use curl or a web browser to access the URL where the WSDL file is located. For example, curl http://example.com/service?wsdl should return XML content describing the service.
• Scanning: Nessus plugin ID 10423 can identify exposed WSDL files. OpenVAS also has relevant checks; consult their documentation for specific IDs. These are examples only.
• Logs and evidence: Web server logs may show requests for the WSDL file. Look for entries containing the filename extension “.wsdl” or patterns associated with SOAP traffic.

curl http://example.com/service?wsdl

4. Solution / Remediation Steps

The following steps outline how to address a detected WSDL file. Prioritise disabling the service if it is not required. If needed, restrict access and harden the web service configuration.

4.1 Preparation

• Ensure you have appropriate permissions to modify the web server configuration. A roll back plan involves restoring the previous snapshot or restarting the stopped service.
• A change window may be needed, depending on the criticality of the service and potential impact. Approval from a senior IT administrator is recommended.

4.2 Implementation

1. Step 1: If the web service is not required, disable it in IIS Manager or Apache/Nginx configuration.
2. Step 2: If the service must remain active, restrict access using firewall rules to only allow trusted IP addresses.
3. Step 3: Review the web service code for input validation vulnerabilities and apply necessary fixes.

4.3 Config or Code Example

Before

# Apache configuration allowing access from any source
<VirtualHost *:80>
    DocumentRoot /var/www/html
    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

After

# Apache configuration restricting access to trusted IPs
<VirtualHost *:80>
    DocumentRoot /var/www/html
    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require ip 192.168.1.0/24  # Replace with trusted IP range
    </Directory>
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent issues related to exposed web services. Least privilege limits the impact of a successful attack, while input validation prevents malicious data from being processed.

• Practice 1: Implement least privilege by granting only necessary permissions to the web service account and restricting network access.
• Practice 2: Enforce strict input validation on all data received by the web service to prevent injection attacks.

4.5 Automation (Optional)

# Example PowerShell script to block access via Windows Firewall
# Replace '192.168.1.0/24' with your trusted IP range
New-NetFirewallRule -DisplayName "Block Untrusted IPs" -Direction Inbound -Action Block -Protocol TCP -LocalPort 80 -RemoteAddress !192.168.1.0/24

5. Verification / Validation

Confirm the fix by verifying restricted access and re-scanning for the WSDL file. A smoke test should ensure core service functionality remains operational.

• Post-fix check: Use curl from an untrusted IP address to attempt to access the WSDL file. The request should be blocked, resulting in a connection error or timeout.
• Re-test: Re-run the Nessus scan (ID 10423) or OpenVAS check; it should no longer report the exposed WSDL file.
• Smoke test: Verify that authorized users can still access and use the core functionality of the web service.
• Monitoring: Monitor web server logs for attempts to access the WSDL file from untrusted IP addresses. A simple query could search for “.wsdl” requests originating from outside your trusted network.

curl http://example.com/service?wsdl # Should return connection error or timeout

6. Preventive Measures and Monitoring

Update security baselines to include restrictions on web service exposure. Implement checks in CI/CD pipelines to prevent the deployment of vulnerable configurations.

• Baselines: Update your server hardening baseline (for example, CIS benchmarks) to require disabling unnecessary web services or restricting access by default.
• Pipelines: Add static code analysis (SAST) tools to your CI/CD pipeline to identify potential input validation vulnerabilities in web service code.
• Asset and patch process: Establish a regular review cycle for server configurations and security settings, including checks for exposed web services.

7. Risks, Side Effects, and Roll Back

Disabling the web service may impact dependent applications. Restricting access could block legitimate users if not configured correctly.

• Risk or side effect 1: Disabling a required web service will cause downtime for any applications that rely on it.
• Risk or side effect 2: Incorrectly configured firewall rules may block legitimate traffic to the web service.
• Roll back: 1) If disabled, restart the web service. 2) If access restricted, remove the firewall rule and restore default configuration. 3) Restore server snapshot if necessary.

8. References and Resources

Link only to sources that match this exact vulnerability.