OWASP Top 10 : Penetration Testing with SOAP Service and Mitigation

Web3 penetration testing
A Guide To Web3 Penetration Testing
August 2, 2024
Threat Intelligence Lifecycle
The Threat Intelligence Lifecycle: 6 Phases and Benefits
August 6, 2024

August 5, 2024

Simple Object Access Protocol (SOAP) Overview:

Simple Object Access Protocol (SOAP) is a Connection or an interface between the web services or a client and web service. SOAP is operated with application layer protocols like HTTP, SMTP or even TCP for message transmission.

 SOAP Operations

Figure 1  SOAP Operation

It is developed in XML language, which uses Web Service Description Language (WSDL) to generate the interface between the web services. If an independent client application or a consumer wants to connect with the web services, it needs Service Endpoint Interface (SEI) which is generated by the application. These interfaces WSDL and SEI are generated using automated tools or by manually, and they are platform independent. Universal Description, Discovery and Integration (UDDI) is a directory where web services can publish about their services and consumer can submit theirs query.

A simple SOAP message contains:

  • Envelope: Identifies the XML documents, has a name space and encoding details.
  • Header: Has header information like content type and character set etc.
  • Body: Contains the request and response information.
  • Fault: Errors and status information.

SOAP Request and Response

Figure 2 Example of SOAP Request and Response

The figure.2 shows the SOAP request and response, where web service is requesting for the name of the user and replying back with a message. SOAP is protocol, a set of standards defined to perform some operations, so it only transmits the data for the requests, whatever the request may be if it is validated in its mechanisms it will have reply.

Common SOAP Vulnerabilities:

1) SQL Injection:

SOAP requests are vulnerable to SQL injections, submitting a parameter as a morphed sql query can authenticate or reveal sensitive information

Before attack Functionality:

Before Performing the attack one must know the functionalities of the web service in fig.3 one can see that username parameter taking string as a input,

Code for request functionality analysis

Figure 3 Request Functionality analysis

A random username is entered to check its operation, so it response back with the message that username does not exit, this may help to perform the attack with the possibilities.

Code for request functionality analysis

Figure 4 Response Functionality analysis

After attack:

The request shown below is an attacker trying to access the user details by passing a sql query in the place of parameter, error message of the database will help to guess the query,

Database Error Message

Figure 5 Database Error Message

Figure 6 SQL Injection request

If the passed query is successful in breaking the database then it will response back with the information of the users.

SQL Injection Response SQL Injection Response

Figure 7 SQL Injection Response

Payloads: 

Payloads for SQL injections typically involve simple morphed queries designed to make the database fetch unintended details. For instance, in the example provided using MySQL (refer to Figure 5), the database may contain multiple tables. While retrieving information from all tables may be challenging, accessing specific fields is feasible.

In Figure 3, the SOAP message requests details for an admin account by combining the username with the condition 1=1 using the OR statement and marking everything else as a comment (–). This technique forces the database to reveal all usernames and signatures. SQL injection attacks can employ various methods, including the use of characters such as ,, “”, –, OR, AND, INSERT, or other query combinations that fulfill the condition.

Patch: 

To mitigate SQL injection attacks, patches can be implemented in the following ways:

  • Whitelisting: This method involves allowing only specific characters through the application. By adding only permissible characters to the whitelist, such as admin, the application restricts input to these characters only.
  • Sanitization: This approach entails sanitizing user input by removing unwanted characters. For example, input like admin’ OR ‘1=1’ — would be sanitized so that only admin is processed.

2) Command Injection:

Command injection is an attack that is usually performed by passing a command with the data to get different information like directory structures, sitemaps, or even sensible information related to the web application.

Command Injection Request

Figure 8 Command Injection Request (1)

In the above lookupDNS web service, a request is made with an IP address and command ls, which lists the directory structure of the application as shown below:

Command Injection Response

Figure 9 Command Injection Response (1)

In other requests, a ping command is passed with an IP address to ping the host, which is shown below:

Command Injection Request

Figure 10 Command Injection Request (2)

Command Injection Response

Figure 11 Command Injection Response (2)

Payloads:

For this type of attack, payloads are commands combined with the user input, but some commands are commonly used and some are operating system specific. Knowing the type of operating system is a simple task; one can see it from HTTP. Commands like ls, adduser, install, kill, or join, etc., can be used to perform the operation.

Patch: 

For patching the command injection attack, a strict validation mechanism must be built and its functionalities implemented. The user input data is validated with the database containing the attack patterns such as 192.168.66.2; ls; and 192.168.66.2 && ping c1 localhost, ensuring it only allows alphanumeric characters. In the above command injection attack, special characters such as & or ; separate the commands and data while executing at the service end, so one must develop functionalities concerning these facts.

3) XML Injection:

In XML Injection type of attack, a morphed request of SOAP  message can make changes in the database and cause serious damage to the database.

Normal Functionalities:

The createUser Functionality creates the new user in the application, which takes several parameters as input and can be seen in Fig. 12.

xml request

Figure 12 XML Request

The response will have a return statement with a message inserting the account username as seen in Fig. 13.

xml response

Figure 13 XML Response

Attack:

IIn actual XML injection, a part of the code is morphed and sent with the request so that the code will be executed on the other side. In fig. 14,  create user functionality is added with additional code to exploit the service.

Morphed XML Request

Figure 14 Morphed XML Request

From fig. 15, it can be seen that the web service is executing the code with a message that inserted the account username. The functionality executes the parameters inserted by the attacker rather than the actual request.

Response for morphed request

Figure 15 Response for morphed request

Payloads:

Payloads for this type of attack are actually the parameters submitted at the other end. In this case, the createUser XML tag is morphed or modified to include the details of account Alice and attached to the request so that it will execute.

Patch: 

The patch for this type of attack involves making strict limits on tag strings like createUser. The length of the string must be defined, and the number of occasions or occurrences for the createUser functionality in WSDL should be specified. Based on the data and parser, a sanitization mechanism for user input should be developed. Additionally, using Document Type Definition (DTD) for validating attempted injections is considered best practice.

4) SOAP Action Spoofing:

Each HTTP request contains a field called SOAP Action, which is used to perform an operation defined in its content. It may be possible to change the content by an attacker who is operating in between the client and server, a sort of bypassing or Man in the Middle operations.

The request message shown below contains a functionality called ‘create user,’ which can be seen in both the SOAP Action field and the SOAP body.

SOAP Request with SOAP Action Field

Figure 16 SOAP Request with SOAP Action Field

Simply morphing the fields (may not be one) can change its functionalities as shown in figure.17.

SOAP Request with SOAP Action morphed

Figure 17 SOAP Request with SOAP Action morphed

After changing the request and passing it to the server, the request will have a response as it seems legitimate and perform its action to delete account, can be seen in fig.18

 SOAP Response executing morphed request

Figure 18 SOAP Response executing morphed request

Payloads:

For this type of attack, there are no specific payloads. The SOAP Action field is considered the target. A thorough analysis of functionalities can provide clues for performing the attack. Changing only the SOAP field may not be sufficient; it might also be necessary to modify the request message according to the action performed.

Patch: 

To prevent this type of attack, you must disable specific SOAP Action fields such as createUser or deleteUser in the HTTP request, or use SOAP Action terminologies that are not easily guessed. In some cases, it might be necessary to make the Action field compulsory. For such scenarios, developers should consider options like SOAPAction: “” (which means the intention of the SOAP message is given by the URI of the request) or SOAPAction: (an empty field indicating that the intention of the message is not to specify any value or URI).

5) SOAP Parameter DOS Attack:

Every SOAP request contains a parameter which is passed to fetch some data, there are some requests where an attacker can exploit the parameters to perform a denial of service attack. If the application fails to perform input validation or no boundaries for the parameter, can cause a buffer overflow and this will make the service unavailability. The figure shown below contains a parameter username without any boundary limits, so any one can pass the string of desire length to the application.

SOAP request without condition

Figure 19 SOAP request without condition

If the username has limits then it will have some exception to pass the correct string this will make the application secure.

Payloads:

For this type of attack, the payloads involve understanding the data types passed in the request. Attackers exploit this by submitting maximum or excessively large values based on the data type.

Patch:

To mitigate this attack, define parameters with specific minimum and maximum length constraints or boundaries. For example, set the username parameter with a minimum length of 5 and a maximum length of 35 characters. This ensures proper validation during processing.

SOAP request with condition

Figure 20 SOAP request with condition

6) WSDL Disclosure:

WSDL disclosure cannot be considered an attack itself but rather a step towards an attack. WSDL contains information about web services, and some web services, such as payment gateways or those collecting sensitive information, need to be hidden from attackers. An attacker can find a web service by simply typing ‘inurl:?wsdl’ into a search engine.

Web-Service Searching

Figure 21 Web-Service Searching

Web service WSDL

Figure 22 Web service WSDL

Patch:

Web applications designed for secure data transmission should not rely solely on their inherent security. Ensure that the URL of the web service (as shown in Figure 22) is concealed from search engines and public disclosure. Additionally, maintain strict adherence to features such as Confidentiality, Integrity, and Authenticity.

References:

Testing for Web Services

Discover more from SecureLayer7 - Offensive Security, API Scanner & Attack Surface Management

Subscribe now to keep reading and get access to the full archive.

Continue reading

Enable Notifications OK No thanks