Hacking

Web Services Penetration Testing Part 7: More Fuzzing with Burp

In the previous article, we discussed how to integrate Burp Suite Free Edition with SoapUI to fuzz different parameters of a soap request, how to configure Burp, and how to use different features like Burp Repeater and Intruder. I assume that whoever is going through this article have that knowledge or if you don't have you just go through the previous article first.

We also learned how to fuzz different parameters to collect different data or test some other test cases, and we found some sensitive user information, such as:

Earn two pentesting certifications at once!

Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.

View Pricing

1. The user Id 2 is a valid user ID.
2. It contains two accounts.
3. Account ID 20 is a checking account.
4. Account ID 21 is a savings account.

Now we will focus on how we can use this information for creating other attacks. I will continue from where I left in the last article. As we have gone through the "GetUserAccounts" method in the previous article, now we will check for the "TransferBalance" method. Let's generate a soap request from SoapUI and then intercept in Burp as shown in Img1.

Img1: Request intercept in Burp

Now if we see the request clearly, it contains four parameters, and we don't know the data type, as shown below in Img2.

[xml]

POST /bank/ws.asmx HTTP/1.1

Accept-Encoding: gzip,deflate

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

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

Content-Length: 598

Host: www.testfire.net

Proxy-Connection: Keep-Alive

User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

<soapenv:Envelope xmlns_soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns_ws="http://www.altoromutual.com/bank/ws/">

<soapenv:Header/>

<soapenv:Body>

<ws:TransferBalance>

<!--Optional:-->

<ws:transDetails>

<ws:transferDate>?</ws:transferDate>

<!--Optional:-->

<ws:debitAccount>?</ws:debitAccount>

<!--Optional:-->

<ws:creditAccount>?</ws:creditAccount>

<ws:transferAmount>?</ws:transferAmount>

</ws:transDetails>

</ws:TransferBalance>

</soapenv:Body>

</soapenv:Envelope>

[/xml]

Img2: "TransferBalance" soap request

So first we have to find the associated data types of those parameters from the WSDL file as shown in Img3.

Img3: WSDL file showing data type

Now as we know that:

1. transferDate(dateTime) = 2000-01-01T00:00:00
2. debitAccount (string) = 21
3. creditAccount (string) = xx
4. transferAmount(double) = 100000

As this is a sensitive request and does not ask for any kind of authentication, an attacker (if he/she is an account holder of this bank) can easily transfer money from other user accounts. So it leads to a critical vulnerability of unauthorized money transfer.

Let's say the attacker doesn't have an account, but still he/she can transfer money from one account to another account. This is also another critical business logic vulnerability i.e. Anonymous money transfer.

In this case, let's assume I am an attacker and I don't have an account in this bank, but I can easily transfer money from account 21 that we have got from the previous vulnerability to any other user's account.

So let's submit the request in Repeater, and check the response as shown in Img4.

Img4: request response in burp repeater

Here we found another critical vulnerability: Account number enumeration. If we fuzz this "creditAccount" parameter we might able to transfer the amount. Send the request to intruder to fuzz this parameter. In the Positions section only select the "creditAccount" as shown in the Img5.

Img5: Selecting the insertion point

Now add all the payloads as shown in Img6.

Img6: Adding all payloads

Now start attack on intruder to check the responses as shown in Img7.

Img7: Intruder attack result

As we can see quite clearly, the first four requests according to the content length differ from other requests, so we are interested in those requests. Let's check one by one to find out what we have here.

The first request we will check is the base request and its response as shown in Img8.

Img8: The base request

The base request contains a special character in place of the "creditAccount" parameter, and we got the response as shown in Img9.

Img9: the base response

It contains server path and dberror pattern, so we have two vulnerabilities:

1. Server path disclosure

2. Possible SQLI

Similarly, let's check the next request and response. For easy understanding, I will send the request to the Repeater, where we can see both request and response in same page as shown in Img10.

Img10: Request response in Burp Repeater

As it shows that the transaction is successful, we successfully created an anonymous account money transfer. Though I don't have any credentials for either of these two accounts, still I am able to transfer money from one account to another. Other than that, we also enumerated other existing accounts of this bank by the account enumeration vulnerability.

Let check the next request and response as shown in Img11.

Img11: Request response in Burp Repeater

Here, if we remember in the previous article, we enumerated some user account information, and according to that account no 20 and 21 belong to same userid=2. So here, nothing interesting apart from version disclosure is found because it's a genuine request; a user can transfer money from one of his/her accounts to another.

Now let's check the last request as shown in Img12.

Img12: Request response in Burp Repeater

We found vulnerability here that same account transfer. Generally it's business logic vulnerability. The sender's account and receiver's account must not be same in any cases.

Though in one of the previous articles I already demonstrated some of these test cases, here I again tested all those test cases from scratch. How to collect various information using fuzzing, and how to use it in other attacks, are demonstrated here in detail. It's not that in black box testing you are restricted to only some vulnerability like information disclosure or authentication bypass, it's always a challenge to do much more in a black box test that any one should ever imagine.

Challenge 1:

Some time you might face some of the problems that I have faced while integrating Burp with SoapUI. The first one is that if you have integrated your Burp with SoapUI and you want to test some web services which run on port 443. You might not get the request in your Burp if you just follow the configuration shown in the previous article. You need to make certain changes in your configuration.

Burp integration with SoapUI for HTTPS:

If you are using SoapUI for a site let's say https://www.example.com/main.aspx?WSDL then you can easily test it in SoapUI, but when you want to integrate it with Burp, you won't get the request intercepted at the Burp end. The root cause of the problem is that it seems SoapUI ignores the proxy settings if the target service runs on HTTPS. So what to do?

Solution:

Open any request in SoapUI. In the top of that, you can find the endpoint URL. Edit the endpoint there as shown in Img13.

Img13: Edited endpoint

You might ask why to edit the endpoint every time, why not edit the project while fetching the methods of the WSDL file while creating the project. Yes it can be done, but sometimes SoapUI won't support this, and you might not be able to send a request response from the SoapUI.

So change the endpoint every time in each request you want to forward to Burp. This configuration edit is done in the SoapUI side; similarly we have to change the configuration in the Burp options as shown in Img14.

Img14: Burp force SSLsetting

First click on the Proxy tab, the click on the Options sub tab. Then select the proxy listener you are using. Then click on Edit. Then a new edit proxy listener window will open. Click on the Request handling tab. Check the force use of SSL and select OK.

After this configuration, you will able to intercept all the requests coming from SoapUI for the port 443 endpoint, because with this solution the SoapUI proxy will properly work and the requests will be sent to Burp without SSL, but Burp will force the SSL with the server, so for the server everything will be the same.

Challenge 2:

Apart from the form-based authentication, if any web services use BASIC or NTLM authentication, you might not able to create a project in SoapUI directly, or in some cases you won't able to invoke a request properly. First let's go for Basic Authentication. In Basic Authentication, username/password credentials are from Windows Active Directory domain and need to be sent in the HTTP header. So, how to authenticate a request in SoapUI?

Solution:

Let's assume that you created a project for a Web service which asks for Basic Authentication. Now when you are sending a request it generates an error that you are not authorized. There are basically two ways to solve this problem.

Solution 1:

When you open a request generated by SoapUI, at the bottom you will find some tabs named Aut, Headers, Attachments, WS-A, WS-RM, JMS Headers and JMS Properties as shown in Img15.

Img15: Different tabs of the Request window

When you click on the Headers tab, it will open a small window, which allows you to add any headers to the message. There you can add a header name "Authorization" and its values should be "Basic <Base64 encoded username:password>". If your username and password are tuser:tpass, then when you encode it, your header values will look like "Basic dHVzZXI6dHBhc3M= " as shown in Img16.

Img16: Adding Authorization Header

After setting this, if you send a request in SoapUI, you will be able to see the Authorization header in the request. So let's send the request and check in Burp whether we are getting the Authorization header or not as shown in Img17.

Img17: Request with Authorization Header

Solution 2:

In this case we will use the Aut tab and define the username and password. But, this information will not get sent as a header. To send them as a header, you need to do the following.

Click on the settings icon, which is present on the third from the right side on top of the SoapUI window. Then select "HTTP settings tab". From that settings list, check the "Authenticate Preemptively" option as shown in Img18.

Img18: Changing SoapUI settings

Then, set the username and password in the Auth tab as shown in Img19.

Img19: Adding username and password in the Aut tab

Now you will see the Authorization header sent with the request as shown in Img20.

Img20: Request with an Authorization Header

Challenge 3:

What if you are testing a web service with NTLM Authentication? How do you configure SoapUI for that?

Solution:

In the case of NTLM Authentication, while creating a project, SoapUI auto detects the authentication type and ask for credentials as shown in Img21.

Img21: NTLM Authentication window

Sometimes even when you give correct credentials, SoapUI will fail to fetch the requests from WSDL. Though SoapUI 4.6.3 comes with better NTLM Authentication feature, I have not used it yet. So the problem is that if after providing correct credentials, SoapUI will fail to generate requests. What to do?

Solution:

Integrate your burp with the browser. Download and install SOA Client Mozilla add-on. Then go to the Options tab in your Burp, and under the Authentication platform, add new authentication type, enter the credentials in the window, select Authentication type as NTLM V1/V2 as shown in Img22 and start testing with the SOA Client.

Img22: NTLM Authentication configuration

Conclusion:

In this article we went through how fuzzing is an essential part of black box testing, how we can use information disclosed from one vulnerability in another, and what are the challenges you might face in testing web services, and what are their solutions.

In the next installment, we will focus on how Burp Suite Professional adds some extra features in Web services penetration testing apart from fuzzing, and mostly on the use of Burp Scanner and Extender while performing Web services penetration testing.

References:

http://gerionsecurity.com/2013/03/soapui-with-burp/

http://meritsolutions.com/images/soapUI-NT-Authentication.jpg

http://blog.zestconsulting.net/?p=35

http://maharachchi.blogspot.in/2013/07/how-to-send-basic-auth-information-when.html

http://charithaka.blogspot.in/

http://www.soapui.org/SOAP-and-WSDL/authenticating-soap-requests.html

http://portswigger.net/burp/

http://www.soapui.org

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://addons.mozilla.org/en-US/firefox/addon/soa-client/