Web Services Penetration Testing Part 4: Manual Testing with SOA Client

In the previous article, we discussed the automated tools available for testing web services, how to automate web services penetration testing using different automated tools, and also why the automation of web services penetration test is not sufficient and manual testing is needed.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

In this article, we will focus on the open source tools available to pen test web services manually and why it is so important.

Manual Testing

Manual testing covers lots more different types of nontraditional test cases that will help a pen tester to understand the functionalities and trying different new approaches based on the scenario, rather than fuzzing the general payloads to cover traditional vulnerabilities. It allows a pen tester to think out of the box, which may lead to a zero-day. It also provides freedom to a pen tester to test different business logic vulnerabilities that are literally impossible to cover by a auto scanner.

For manual testing also we need some kind of tools that will help us, so today we will start with the open source manual tools that can be used test web services. We will start with a simple yet effective Mozilla Firefox add-on, SOA Client.

SOA Client

SOA Client (https://addons.mozilla.org/en-US/firefox/addon/soa-client/) is a Mozilla Firefox add-on by Michael Santoso. It is a portable client to access web services and UDDI registries. It is easy to install and it has a user-friendly interface to perform web services penetration testing manually, as shown in Figure 1.

Figure 1: SOA Client window

As I stated earlier, SOA Client is used to access WSDL and UDDI. Below is a list of some web services and UDDI registries that are on the SOA Client page.

Web Services

Credit card verification: https://ws.cdyne.com/creditcardverify/luhnchecker.asmx?wsdl

Census information: http://ws.cdyne.com/DemographixWS/DemographixQuery.asmx?wsdl

Currency foreign exchange: http://www.xignite.com/xCurrencies.asmx?WSDL

Email address validation: http://www.webservicex.com/ValidateEmail.asmx?WSDL

English dictionary: http://services.aonaware.com/DictService/DictService.asmx?WSDL

Number conversion: http://www.dataaccess.com/webservicesserver/numberconversion.wso?WSDL

Image converter (e.g., PSD into JPG): http://www.bigislandcolor.com/imageconvert.wsdl

IP address into location: http://ws.cdyne.com/ip2geo/ip2geo.asmx?wsdl

Stock quote: http://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?wsdl

Translator (English to Chinese): http://fy.webxml.com.cn/webservices/EnglishChinese.asmx?wsdl

FIFA World Cup 2010: http://footballpool.dataaccess.eu/data/info.wso?WSDL

Weather forecast: http://www.webservicex.net/WeatherForecast.asmx?WSDL

UDDI Registries

http://hma.eoportal.org/juddi/inquiry

http://registry.gbif.net/uddi/inquiry

http://test.uddi.microsoft.com/inquire

As you can see in Figure 1, There are four tabs in SOA Client:

1. Access Web Services
2. Access UDDI Registries
3. Advanced Access
4. About

In this article, we will be using mostly the "Access Web services" and "Advanced Access" options, since we are going to use a public-facing demo web service and not the UDDI registry. So, for this case, we are going to use the same (http://www.testfire.net/bank/ws.asmx?WSDL) for manual testing.

Manual Testing with SOA Client

First open your SOA Client and put this WSDL URL, as shown in Figure 2.

Figure 2: Access Web Services tab

Then Click on "Parse WSDL" to import all the operations present in that web service, as shown in Figure 3.

Figure 3: Parsed WSDL window

In the result page, you will get all the operations available in the web service. And, as you can see, there are five tabs:

1. Raw WSDL Data
2. Raw Request Header
3. Raw Request Body
4. Raw Response Header
5. Raw Response Body

This is a very good, light-weight, simple GUI tool to test web services manually. Let's start the test by selecting the "GetUserAccounts" operation, as shown in Figure 4.

Figure 4: invoking GetUserAccounts operation

As we can see here, the "GetUserAccounts" operation contains only one parameter of "int" data type and we provided an appropriate value there. Now click on "Invoke" (because Figure 4 is a partial image, you will see the "Invoke" button on the very right side of this window. as shown in Figure 3) to send the request.

Since we provided it with a proper request, we get a valid response "200 OK" without any error. (If you remember, in the previous article "Web Services Penetration Testing, Part 2: An Automated Approach With SoapUI Pro" in Figure 10: XML View, we used the same method and value and got a response with no error; here we got a similar response, as shown in Figure 5.)

Figure 5: Response to GetUserAccounts requests

Similarly, you can change the values in different parameters and invoke the request to get the response. But there are certain problems with this SOA Client; one problem is that sometimes it won't parse the WSDL properly. That's what happened here. As you can see in Figure 6 in the Raw WSDL Data tab, the operation "TransferBalance" has four parameters, but in the GUI, the SOA Client shows only two.

Figure 6: Parsed WSDL operations window

As is very clear from the raw WSDL data, the "TransferBalance" operation needs four values:

1. transferDate (date-time data type)
2. debitAccount (string data type)
3. creditAccount (string data type)
4. transferAmount (double data type)

But the SOA Client only parsed two parameters, "debitAccount" and "creditAccount."

We can come out of this and still perform web service manual penetration testing using its "Advanced Access" option. All we need is the sample request. Most probably, in gray box testing, we are provided with sample requests, but sometimes we get those sample requests due to an information leakage vulnerability.

I prefer this tool when I get a WSDL file and the sample requests are disclosed publicly due to server misconfiguration while performing a Web application penetration test. I use the "Advanced Access" module to check the operation to find vulnerabilities.

So here we assume that we found the sample requests of this WSDL (http://www.testfire.net/bank/ws.asmx?WSDL) and we use them to learn how to use the "Advanced Access" module in the SOA Client tool.

We will use the sample request of the "TransferBalance" operation, which can be found on (http://www.testfire.net/bank/ws.asmx?op=TransferBalance), as shown in Figure 7. The normal "Access Web Services" module is unable to parse it properly.

Figure 7: Sample request for the TransferBalance operation

Before starting the testing, first let's have a check on the "Advanced Access" module interface to understand what data we need to start the test. The interface can be found in Figure 8.

Figure 8: Advanced Access module window

As you can see, we need a URL (which is an end point URL to perform the test). We have to specify the request type (whether we want to use GET, POST, HEADER, TRACE, or OPTIONS). We have to deal with the authentication mechanism, if any is needed, and we need to determine the communication type, synchronized or asynchronized. We also need the HTTP request header (If any specific header has to be added) and, last but not least, the SOAP request. We can find all these details in the sample request. But before that, we need to understand how to differentiate all these requirements from that one sample request, as shown in Figure 9.

[xml]

POST /bank/ws.asmx HTTP/1.1

Host: www.testfire.net

Content-Type: text/xml; charset=utf-8

Content-Length: length

SOAPAction: "http://www.altoromutual.com/bank/ws/TransferBalance"

<!--?xml version="1.0" encoding="utf-8"?-->

dateTime string

string

double

[/xml]

Figure 9: Sample request of TransferBalance operation

This is the same request from Figure 7. Here we can see in the very first line that the request method is POST. And from line 1 and line 2 we can deduce that the URL used must be http://www.testfire.net/bank/ws.asmx. In the header there is nothing special that we need to use in the "Advanced Access" module. The type of communication is not specified, so we can go with the default options. There is no authentication mechanism required for this request, so we will not touch that option in the "Advanced Access" module. And last but not least, we have the SOAP request in the second part of the sample request. This SOAP request contains four parameters.

1. transferDate (date-time data type)
2. debitAccount (string data type)
3. creditAccount (string data type)
4. transferAmount (double data type)

As it's a black box testing, we don't have the exact data that we can use in this request, so we will use some data with the required data type.

1. transferDate (date-time data type) = 2009-01-01T00:00:00
2. debitAccount (string data type) = test
3. creditAccount (string data type) = tester
4. transferAmount (double data type)= 1.0

When we enter all these details in the "Advanced Access" module it will look as shown in Figure 10.

Figure 10: Advanced Access window with required data

The things added or changed are marked in red in Figure 10. The rest are the default settings. Now submit the request by clicking the "Submit" button in the right top corner to get a response. The response is shown in Figure 11.

Figure 11: Response of TransferBalance request

As you can see in Figure 11, in the "Raw Response Body" tab we got the "200 OK" with some interesting information.

1. TransferBalanceResult success is false (we are unable to transfer the balance).
2. System.Data.OleDb.OleDbException (we got a "DB Exception"; this is a hint to a possible SQLI).
3. d:downloadsAltoroMutual_v6websiteApp_CodeWebService.cs:line 146 (server path disclosure).

This is how we can use the "Advanced Access" module of the SOA Client tool. This is how we manually test for various vulnerabilities. As we can see, by using one request we got one vulnerability, the server path disclosure, and a hint of another vulnerability, i.e., SQLI. One/some/all of the parameters might be vulnerable to SQLI; you just need to check each of the parameter to get the result.

What we have learned so far is how to use different modules of SOA Client to perform the manual web service penetration testing. There are restrictions, such as the fact that it sometimes won't able to parse the request properly and, to test efficiently, we need the sample request.

Conclusion

Although there are certain limitations, SOA Client is a very light-weight and user-friendly GUI tool. We can use it in most of the cases while performing the penetration testing of web services. But there are certain cases where we are bound to choose another option.

Let's say we need to perform a black box web services penetration testing: In that case, there is no way we will get the sample request from the client. What if the sample request is not exposed to public as it is exposed in our case for testfire.net? What if SOA Client is unable to parse some requests, as we see earlier in this article? We need some other tool to perform manual web services penetration testing and we will learn about that in the next installment.

References

https://addons.mozilla.org/en-US/firefox/addon/soa-client/

Become a Certified Ethical Hacker, guaranteed!

Get training from anywhere to earn your Certified Ethical Hacker (CEH) Certification — backed with an Exam Pass Guarantee.

Learn More

https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcT0Nhftsh09x8FvWR14QfK2tIsdTf6R3akw0uB-9cuHVeyGWFnA7g