Web Services Penetration Testing : More Fuzzing with Burp

May 15, 2023May 15, 2023 Ahmad Khan 0 Comments black hat pakistan, Ethical hacking, hacking, Web Services Penetration Testing

In this article we will learn about Web Services Penetration Testing.

Introduction to Web Services Penetration Testing:

In the previous article, we discussed how to integrate Burp Suite Free Edition with SoapUI to unify various soap request parameters, how to configure Burp, and how to use various features such as Burp Repeater and Intruder. I assume everyone going through this article has this knowledge, or if not, 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 found some sensitive user information such as:

User ID 2 is a valid user ID.
Contains two accounts.
Account ID 20 is a current account.
Account ID 21 is a savings account.

Now we will focus on how we can use this information to create other attacks. I will continue where I left off in the last article. Since we went through the “GetUserAccounts” method in the previous article, now we will review the “TransferBalance” method. Let’s generate a soap request from SoapUI and then capture it in Burp as shown in Figure 1.

Img1: Request intercept in Burp

Now, if we can see the request clearly, it contains four parameters and we don’t know the data type as shown in Figure 2 below.

[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)

?

?

?
?

[/xml]

Img2: Application for “TransferBalance” soap.

So first we need to find the related data types of these parameters from the WSDL file as shown in Img3.

Img3: WSDL file showing data type

Now as we know that:

transferDate(dateTime) = 2000-01-01T00:00:00
debitAccount ( string ) = 21
creditAccount ( string ) = xx
transferAmount(double) = 100,000
Since this is a sensitive request and requires no authentication, an attacker (if he is the account holder of this bank) can easily transfer money from other user accounts. This leads to a critical money transfer vulnerability.

Let’s say an attacker doesn’t have an account, but can still transfer money from one account to another. This is also another critical business logic vulnerability i.e. anonymous money transfer.

In this case, let’s assume that I’m an attacker and I don’t have an account with this bank, but I can easily transfer money from account 21, which we obtained from the previous vulnerability, to any other user’s account.

So let’s send the request in the Repeater and check the response as shown in Figure 4.

Img4: request response in burp repeater

This is where we found another critical vulnerability: account number enumeration. If we blurred this “creditAccount” parameter, we could transfer the amount. Send a request to the intruder to blur this parameter. In the Positions section, select only “credit account” as shown in Figure 5.

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 clearly see, the first four requests differ from the other requests in terms of content length, so we are interested in these requests. Let’s take a look one by one to see what we have here.

The first request we will review is the base request and its response as shown in Figure 8.

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

Since the transaction appears to be successful, we have successfully created an anonymous money transfer to the account. Even though I don’t have any credentials for either of these two accounts, I can still transfer money from one account to the other. In addition, we also quantified other existing accounts of this bank according to account vulnerability.

Check the next request and response as shown in Figure 11.

Img11: Request response in Burp Repeater

Here, if we remember in the previous article, we listed some information about the user account, and according to this, accounts 20 and 21 belong to the same userid=2. So nothing interesting found here except to publish the version because it’s a real request; the user can transfer money from one of his accounts to another.

Also Read:Theoretical Methodology for Detecting ICMP Reflected Attacks: SMURF Attacks 2023

Now let’s check the last request as shown in Figure 12.

Img12: Request response in Burp Repeater

We found the same account transfer vulnerability here. Generally, this is a business logic vulnerability. The account of the sender and the account of the recipient must not be the same in any case.

Although I have already demonstrated some of these test cases in one of the previous articles, here again I have tested all these test cases from scratch. Here is a detailed demonstration of how to collect various information using fuzzing and how to use it in other attacks. It’s not that black box testing is limited to some vulnerability like information disclosure or authentication bypass, it’s always a challenge to do a lot more in black box testing than anyone can imagine.

Challenge 1:

Over time, you may face some of the problems I faced when integrating Burp with SoapUI. The first one is if you have integrated your Burp with SoapUI and you want to test some web services that run on port 443. If you follow the configuration in the previous article, you may not get a request in your Burp. You need to make some changes to your configuration.

Burp integration with SoapUI for HTTPS:

If you’re using SoapUI for a website, say https://www.example.com/main.aspx?WSDL, you can easily test it in SoapUI, but when you want to integrate it with Burp, you won’t get the request caught at the end of the burp. The root cause of the problem is that SoapUI seems to ignore proxy settings if the target service is running on HTTPS. So what to do?

Solution:

Open any request in SoapUI. At the top, you can find the endpoint URL. Edit the endpoint there as shown in Figure 13.

Img13: Edited endpoint

You may ask, why modify the endpoint each time, why not modify the project when loading the methods of the WSDL file when creating the project. Yes, it can be done, but sometimes SoapUI doesn’t support it, and you might not be able to send a request response from SoapUI.

So change the endpoint every time in every request you want to pass to Burp. This configuration modification is done on the SoapUI side; similarly, we need to change the configuration in the Burp options as shown in Figure 14.

Img14: Burp force SSLsetting

First, click on the Proxy tab, then click on the Options sub-tab. Then select the proxy listener you are using. Then click Edit. Then a new window will open for editing the proxy listener. Click the Request Processing tab. Check Enforce Use of SSL and select OK.

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

Challenge 2:

In addition to form-based authentication, if any web services use BASIC or NTLM authentication, you may not be able to create a project directly in SoapUI, or in some cases you may not be able to make a request correctly. First, let’s do some basic verification. In basic authentication, the username and password credentials are from the Windows Active Directory domain and must be sent in the HTTP header. So how to validate a request in SoapUI?

Solution:

Assume that you have created a project for a web service that requires basic authentication. Now when you send the request it will generate an error that you don’t have permission. There are basically two ways to solve this problem.

Solution 1:

When you open the request generated by SoapUI, you will find some tabs at the bottom named Auto, Header, Attachments, WS-A, WS-RM, JMS Header and JMS Properties as shown in Figure 15.

Img15: Different tabs of the Request window

When you click on the Header tab, a small window opens where you can add any header to the message. Here you can add “Authorization” header name and its values should be “Basic “. If your username and password are tuser:tpass, then when you encode them, your header values will look like “Basic dHVzZXI6dHBhc3M= “, as shown in Figure 16.

Img16: Adding Authorization Header

After this setup, if you send a request in SoapUI, you will see an Authorization header in the request. So we send the request and check in Burp whether we are getting the Authorization header or not as shown in Figure 17.

Img17: Request with Authorization Header

Solution 2:

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

Click on the settings icon located third from the right at the top of the SoapUI window. Then select the “HTTP Settings” tab. In this list of settings, check “Authenticate Preemptively” as shown in Figure 18.

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 this?

Solution:

In the case of NTLM authentication, when creating a SoapUI project, it will auto detect the authentication type and ask for credentials as shown in Figure 21.

Img21: NTLM Authentication window

Sometimes, even if you enter the correct credentials, SoapUI fails to load requests from the WSDL. Although SoapUI 4.6.3 comes with a better NTLM authentication feature, I haven’t used it yet. So the problem is that if after providing the correct credentials, SoapUI fails to generate the requests. What to do?

Solution:

Integrate your burp with your browser. Download and install the Mozilla SOA client add-on. Then go to the Options tab in Burp and add a new authentication type under the Authentication platform, enter the credentials in the window, select the 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’ve gone through how fuzzing is an essential part of black box testing, how we can leverage the information revealed from one vulnerability into another, and the challenges you may face when testing web services and their solutions.

In the next installment, we’ll focus on how Burp Suite Professional adds some additional functionality to web service penetration testing beyond fuzzing, and mainly the use of Burp Scanner and Extender when performing web service penetration testing.