How to remediate – Web Services Description Language (WSDL) File Detected

1. Introduction

A Web Services Description Language (WSDL) file has been detected on a given URL. WSDL files describe web services, allowing different applications to communicate with each other. Their presence doesn’t necessarily indicate an issue but can be a reconnaissance step for attackers looking for vulnerable web services. This could impact the confidentiality, integrity and availability of systems using those services if exploited.

2. Technical Explanation

The detection of a WSDL file itself isn’t a vulnerability; it indicates that a web service is exposed. However, poorly secured or outdated web services described by these files can be targeted. An attacker could exploit vulnerabilities within the service logic to gain unauthorized access or disrupt operations. Preconditions include network connectivity to the URL and knowledge of the service endpoint.

• Root cause: The presence of a publicly accessible WSDL file, potentially exposing service details without adequate security measures.
• Exploit mechanism: An attacker could analyse the WSDL file to understand the service’s operations and then craft malicious requests targeting vulnerabilities in those operations. For example, they might attempt SQL injection or cross-site scripting attacks through exposed parameters.
• Scope: Any system hosting a web service with an accessible WSDL file is potentially affected. This includes applications built using technologies like SOAP, .NET Web Services, and Java Web Services.

3. Detection and Assessment

• Quick checks: Use curl or a web browser to access the URL where the WSDL file is suspected to reside. A successful response will show XML content starting with “”.
• Scanning: Nessus plugin ID 68794 can detect exposed WSDL files. This is an example only and may require tuning.
• Logs and evidence: Web server logs should be checked for requests to the URL hosting the WSDL file. Look for patterns indicating access from unknown sources.

curl https://example.com/service.wsdl

4. Solution / Remediation Steps

Fixing this issue involves securing the web service and limiting exposure of the WSDL file. These steps should be small, testable, and safe to roll back.

4.1 Preparation

• No services need to be stopped for most configurations. Ensure you have access to restore the original configuration if needed. A roll back plan is to revert the configuration file to its previous version.
• Change windows may be required depending on service criticality and impact. Approval from the application owner may be necessary.

4.2 Implementation

1. Step 1: Restrict access to the WSDL file using web server configuration (e.g., .htaccess, nginx config). Allow only authorized IP addresses or networks.
2. Step 2: Implement authentication and authorization for accessing the web service operations described in the WSDL file.
3. Step 3: If possible, move the WSDL file to a location that is not directly accessible from the internet.

4.3 Config or Code Example

Before

# Apache .htaccess - allowing public access
Allow from all

After

# Apache .htaccess - restricting access to specific IP addresses
Allow from 192.168.1.0/24
Deny from all

4.4 Security Practices Relevant to This Vulnerability

Practices that directly address this vulnerability type include least privilege and input validation.

• Practice 1: Least privilege access controls reduce the impact if a web service is compromised by limiting what an attacker can do.
• Practice 2: Input validation prevents malicious data from being processed by the web service, mitigating risks like SQL injection or cross-site scripting.

4.5 Automation (Optional)

# Example Ansible playbook snippet to restrict access via firewall
- name: Restrict WSDL file access
  firewalld:
    service: http
    port: 80/tcp
    permanent: true
    state: enabled
    zone: public
    rich_rule: 'rule family="ipv4" source address="192.168.1.0/24" port protocol=tcp port=80 accept'

5. Verification / Validation

Confirming the fix involves verifying restricted access and re-testing for vulnerabilities. A simple service smoke test should also be performed.

• Post-fix check: Use curl from an unauthorized IP address to access the WSDL file. The response should be a 403 Forbidden error.
• Re-test: Re-run the initial curl command and confirm that access is denied from outside authorized networks.
• Smoke test: Verify that legitimate users can still access the web service operations they are authorized to use.
• Monitoring: Monitor web server logs for failed access attempts to the WSDL file, which could indicate reconnaissance activity.

curl https://example.com/service.wsdl - returns 403 Forbidden

6. Preventive Measures and Monitoring

Update security baselines and implement checks in CI pipelines to prevent similar issues. A sensible patch or config review cycle should be established.

• Baselines: Update a web server baseline configuration to include default restrictions on access to sensitive files like WSDLs.
• Pipelines: Add static analysis (SAST) checks in CI pipelines to identify publicly exposed WSDL files or insecure service configurations.
• Asset and patch process: Implement a regular review cycle for web service configurations, ensuring that security best practices are followed.

7. Risks, Side Effects, and Roll Back

Restricting access could inadvertently block legitimate users if not configured correctly. Ensure you have steps to return to the previous state.

• Risk or side effect 1: Blocking legitimate user access. Mitigation is to carefully define authorized IP addresses/networks and monitor logs for errors.
• Roll back: Revert the web server configuration file (e.g., .htaccess, nginx config) to its previous version. Restart the web service if necessary.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for best practices on securing WSDL files.
• NVD or CVE entry: No specific CVE exists for the detection of a WSDL file, but related vulnerabilities in web services may be listed on the NVD website (https://nvd.nist.gov/).
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation for configuration options regarding access control and security settings.