Analysis of SOAP injection attack instances

 

In this article, we will test and exploit a series of security vulnerabilities in the SOAP service. Not all attack behaviors are targeted at SOAP. We must have a clear understanding of this situation.

New users in this line often have the idea of preemptible, believing that all kinds of attacks that threaten the security of web services are always mysterious and difficult to prevent. However, many attacks to Web services come from the same vulnerability similar to browser application security defects.

The following types of vulnerabilities are described and used in this article:

1. SOAP Injection

2. SQL Injection

3. Default content

4. Damaged authentication and session management

SOAP Injection

Although many security defects in Web services are similar or almost familiar to the public, these vulnerabilities are not only compiled for reference, you don't even need any superb technology to make full use of it. However, SOAP injection is different. The vulnerabilities it points to are not only difficult to defend against, but also have considerable requirements on the level of attackers.

So how exactly is this attack? The XML parsing engine on the server receives input information from the client. The client can be a browser, data from a web application, a mobile device, or another type of source. If the entered information is not correctly verified, the received result may be incorrect, which facilitates the attack.

Based on the above situation, we start from the attacker's standpoint, without advanced technology or in-depth understanding of the Processing Methods of the SOAP request server, it is closer to the real process of SOAP injection attacks step by step. This requires us to first prepare some extremely lengthy error messages (which may sound a bit like a security configuration error ).

Follow the following requirements:

The request is displayed normally. We will issue our own name and password here. If the request is still sent normally, the resolution will also proceed smoothly. Whether or not the access permission can be granted depends on the content of the initial request.

Now let's generate the same request, but this time we omit it

<Lname> </lname>

 

Label.

According to the server response results, we can see that we have made some breakthroughs:

This error warning actually indirectly tells us the code! The actual definition of this fault prompt is that if the lname variable is missing, the Code should use the logon ID parameter as an alternative. The current situation is very interesting. In this case, we need to deliberately omit the lname tag to trigger the fault prompt ("II") and then extract the logon ID tag.

Here is the new request we created:

Now, the following message is displayed:

This means that we need to use the collected authorization certificate or information to start the operation.

(Submit

<Loginid> 1 </loginid>

Label ).

This type of attack is relatively simple. It uses a simple parsing engine written in the background that contains error information. In this way, the requests we submit will be received as operations from the Administrator-level account.

SQL Injection

In this section, we will use some code created in the first part of the article. Start the Burp with a Ruby script named attack_soap.rb.

Let's send a request to the WSDL file, implement interception at the Burp, generate the request, and then perform fuzzy processing and analysis. After finishing your work.

As mentioned in the first part of the article, the above step will automatically generate a SOAP request to disable operations and parameters in the WSDL file. In the attack_soap.rb script, we have compiled special SOAP requests and passed them to the Burp proxy. Once the request is generated and correctly intercepted, we can make it play a role in the attack.

By locating intrusion activities, we need to write a fuzzy string to be inserted.

Please note that we have penetrated 101 in the insert point, so our fuzzy string will replace the integer "101.

Now, you need to select a valid load. Fuzzdb is a good source for Fuzzy strings. We can find any useful content on the following network for creating Burp effective loads: http://code.google.com/p/fuzzdb /.

Select the default drop-down list. In the drop-down list, select "fuzzing-full.

Start the attack, as shown in:

Now we need to review response information from the application. Note that although most of the returned responses are single-byte content with a total length of 634, the string "1 or 1 = 1 --" returns a single-byte content with a total length of 1662.

What are the mysteries behind this? Let's wait and see.

The application has responded to the SQL statement by returning to the credit card list! The SQL injection vulnerability program in the SOAP service has been successfully developed.

Default Content Retrieval

The focus of this vulnerability analysis is to remind readers that, just as the default content exposure of traditional Web applications can cause security threats, server-hosted web services have the same features.

As an attacker, you should do your best to mine any hidden or seemingly useless content that web developers or administrators forget to delete. In general, we can always find code that has not been correctly tested or contains critical vulnerabilities. In addition, such files may store verification information or other sensitive resources in the form of a text document or Excel table.

In general, we should "at least" run the following Google queries (the content is not comprehensive and you need to add it yourself ):

All the files returned by the preceding query match the site name we provided. When using SOAP, we strongly recommend that you add "filetype: wsdl" as your preferred solution to find additional wsdl files on your site.

This step is not complete yet. SVNDigger lists a large list of directories and file names that can be used to find the default content. You can.

You can also use the "DirBuster" tool recommended by OWASP and load the retrieval table in this way.

It should be reiterated that the exposed default content may cause various serious hazards caused by sensitive data leakage. Everyone must be cautious when practicing such attacks. Otherwise, catastrophic consequences may occur.

Corrupted verification and session management Defects

This type of vulnerability has the same impact on web services as on traditional Web applications. In fact, with the rapid rise of mobile devices, Web Services began to provide support for them. In addition, examples of such vulnerability threats are constantly increasing.

User name and password submission in each request

Taking a SOAP request as an example, the request must be basically authorized by the upper-level WSDL. The authorization standards that exist between applications and user browsers are subject to the following interaction process:

1. Users submit verification information

2. The application verifies the information and sends a cookie

3. the user's browser stores the cookie value from the application.

4. Based on subsequent requests from the user's browser, the cookie will be sent to the application again

With this basic process concept, even if cookies are stolen, they should still work for a period of time before they expire. However, if you want to obtain more information to view or modify the password, attackers can only rely on their own luck.

However, too many mobile apps use basic information verification to interact with Web services. Therefore, we often find that some mobile apps carry verification information in each request sent to Web Services!

If your mobile phone is on and connected to a Wi-Fi network that allows public access, and Web services are not using HTTPS, this means that the load media used throughout the transmission process is equivalent to plain text. Let's explore how easy it is to crack basic verification information.

Send the basic verification information string to the Burp Decoder

As you can see, the user name is guest and the password is also guest. Here I stress again that mobile apps are always filled with such simple vulnerabilities.

Lack of account lock mechanism

After a certain number of wrong passwords are entered, the account is still not locked, which is another common defect in the current web service. In other words, attackers can use brute-force cracking to obtain a combination of user names and passwords. Such unnecessary mistakes may bring great security threats to the service account and deserve to be taken seriously.

Low Password Complexity

When you include the above security risks (such as the lack of account lock mechanisms) into the agenda, do not forget to increase password complexity at the same time. Once the password is too simple for the purpose of remembering, this constitutes a new security defect, and unauthorized malicious attackers will soon take advantage of it.

Summary

As you can see, the existing and well-known Web Application Security Vulnerabilities are also rampant in the Web service field. The premise of attack or penetration may vary in details, but the root cause is essentially the same, that is, security design defects and omissions in actual coding.

I hope this article will provide some inspiration for identifying and responding to web services, especially the security vulnerabilities in the SOAP web services field.

From bkjia.com