CAPEC-95 - WSDL Scanning

This attack targets the WSDL interface made available by a web service. The attacker may scan the WSDL interface to reveal sensitive information about invocation patterns, underlying technology implementations and associated vulnerabilities. This type of probing is carried out to perform more serious attacks (e.g. parameter tampering, malicious content injection, command injection, etc.). WSDL files provide detailed information about the services ports and bindings available to consumers. For instance, the attacker can submit special characters or malicious content to the Web service and can cause a denial of service condition or illegal access to database records. In addition, the attacker may try to guess other private methods by using the information provided in the WSDL files.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 2
  • Analysis
  • API Abuse
  • Purposes 1
  • Reconnaissance
  • Sec Principles 3
  • Defense in Depth
  • Never Assuming that Your Secrets Are Safe
  • Securing the Weakest Link
  • Scopes 1
  • Read application data
  • Confidentiality

Low level: This attack can be as simple as reading WSDL and starting sending invalid request.

Medium level: This attack can be used to perform more sophisticated attacks (SQL injection, etc.)

A client program connecting to a web service can read the WSDL to determine what functions are available on the server.

The target host exposes vulnerable functions within its WSDL interface.

An attacker can request the WSDL file from the target host by sending a SOAP message.

There are free Vulnerability testing tool, such as WSDigger to perform WSDL scanning - Foundstone's free Web services security tool performs WSDL scanning, SQL injection and XSS attacks on Web Services.

Step 1 -

The first step is exploratory meaning the attacker scans for WSDL documents. The WDSL document written in XML is like a handbook on how to communicate with the web services provided by the target host. It provides an open view of the application (function details, purpose, functional break down, entry points, message types, etc.). This is very useful information for the attacker..


Step 1 -

The second step that an attacker would undertake is to analyze the WSDL files and try to find potential weaknesses by sending messages matching the pattern described in the WSDL file. The attacker could run through all of the operations with different message request patterns until a breach is identified..


Step 1 -

Once an attacker finds a potential weakness, they can craft malicious content to be sent to the system. For instance the attacker may try to submit special characters and observe how the system reacts to an invalid request. The message sent by the attacker may not be XML validated and cause unexpected behavior..


It is important to protect WSDL file or provide limited access to it.

Review the functions exposed by the WSDL interface (especially if you have used a tool to generate it). Make sure that none of them is vulnerable to injection.

Ensure the WSDL does not expose functions and APIs that were not intended to be exposed.

Pay attention to the function naming convention (within the WSDL interface). Easy to guess function name may be an entry point for attack.

Validate the received messages against the WSDL Schema. Incomplete solution.