In this lab, you will learn to attack SOAP-based web services. More specifically, you would enumerate the WSDL file to discover and invoke hidden methods, bypass SOAP body restriction and perform SQL and Command injection attacks on the provided web service.
In this lab environment, the user will get access to a Kali GUI instance. A slightly modified instance of the Mutillidae web application can be accessed using the tools installed on Kali at http://demo.ine.local.
Objective: Perform the following attacks on the provided SOAP-based web service and collect all three flags (flag1, flag2, and flag3):
- WSDL Enumeration
- Invoking hidden methods
- Bypass SOAP body restrictions
- SQL Injection
- Command Injection
Flag Information:
- flag1 and flag2 would be retrieved by invoking the hidden methods.
- flag3 would be invoked from the server file system after exploiting the command injection vulnerability.
The web services to be attacked can be located here: - WSDL Enumeration, Invoking hidden methods, SQLi, bypassing SOAP body restrictions: http://demo.ine.local/webservices/soap/ws-user-account.php - Command Injection: http://demo.ine.local/webservices/soap/ws-lookup-dns-record.php
The best tools for this lab are:
Please go ahead ONLY if you have COMPLETED the lab or you are stuck! Checking the solutions before actually trying the concepts and techniques you studied in the course will dramatically reduce the benefits of a hands-on lab!
Step 1: Open the lab link to access the Kali GUI instance.
Step 2: Check if the provided machine/domain is reachable.
Command:
ping -c3 demo.ine.local
The provided machine is reachable.
Step 3: Check open ports on the provided machine.
Command:
nmap -sS -sV demo.ine.local
Port 80 (Apache webserver) and 3306 (MySQL server) are open on the target machine.
Step 4: Open the browser to inspect the hosted website.
URL: http://demo.ine.local
An instance of OWASP Mutillidae II is hosted on the Apache webserver.
Step 5: Open the Lookup User web service.
In the challenge description, the link for the web services is already provided.
You could navigate to the web services from the menus available on the web page:
Visit Web Services > SOAP > Username Enumeration > Lookup User:
Alternatively you can visit the web service URL provided in the challenge description:
URL: http://demo.ine.local/webservices/soap/ws-user-account.php
And that should take you to the following web page:
Step 6: Enumerate the WSDL file.
Information:
WSDL stands for Web Services Description Language and is used to describe web services. It is written in XML.
A WSDL document describes a web service. It specifies the location of the service, and the methods of the service, using these major elements:
Reference: https://www.w3schools.com/xml/xml_wsdl.asp
And that's why this file is quite interesting since it's a description of the web service we will be pentesting.
We would be locating all the defined operations/methods of the service and the parameters they accept to invoke those later.
On the web service page, click on the WSDL file link or append ?wsdl to the URL:
That would show the WSDL file for the web service we will be interacting with:
As we already saw on the W3schools WSDL page, <portType> describes the operations that can be performed by the web service along with the messages (or the parameters) that have to be passed.
If you check the WSDL for the web service, you will find that it supports five operations, namely:
The documentation for all of these operations is also available in the WSDL file.
The conclusion is that the web service page only lists 3 out of these 5 operations. So seemingly, these operations are not meant to be invoked by the normal users and are probably reserved for the administrators.
Step 7: Check information on getUser operation.
Head back to the web service page and click on the getUser link:
As you can see, the information on the getUser operation is listed. The input, and output parameters are also listed here. All this information is also present in the WSDL file which we explored in the last step.
Scroll down to view the complete request to invoke the getUser method of the web service:
Step 8: Launch Burp Suite.
Open the start menu and select: 03 - Web Application Analysis -> burpsuite
If you get a warning about the JDK version, feel free to ignore it and press the OK button:
Create a temporary project:
We will be using the default Burp Suite configuration:
After these steps, Burp would start up!
Step 8: Invoke the getUser method.
Open the Repeater window in Burp Suite:
Copy the request to invoke the getUser method from the web page and paste it in the Repeater window:
Remove the /mutillidae part of the URL as the web service is located at /webservice and not at /mutillidae/webservice.
Once that is done, send the request.
That should open a dialog asking for the Host and the Port of the target machine:
Host: demo.ine.local Port: 80
Now with the target configured, click on the send button again:
Now the request worked!
Scroll down the response and you would notice the username and signature returned by the web service:
Step 10: Invoke the deleteUser method.
Replace all the occurences of getUser with deleteUser and end the request:
As you can see in the above image, we got back a 200 response!
Scrolling down reveals about an error:
As you can see in the above image, there's a parameter that is missing from the request sent to the web service.
But more importantly, we were able to invoke the web service that was supposedly hidden.
Head over to the web service's WSDL file and locate deleteUserRequest:
As you can notice in the above image, there are two parameters accepted by this function, namely: username and password. Both of them are of the string data type.
Step 11: Performing SQL Injection attack.
Now we know that the deleteUser requires two parameters. But we don't know the password of any of the users.
We could perform a dictionary attack. Alternatively, we could check if the web service is vulnerable to SQL Injection.
Let's go with the latter. First, we will send a single quote (') as the password and see if any errors are returned from the web service:
As you can see, we again get back a 200 response.
Scrolling down reveals a SQL error:
The SQL query executed by the web service is also revealed in the error message:
SQL Query:
SELECT username FROM accounts WHERE username='Jeremy' AND password=''';As you can see, there is a single extra quote (') which invalidated the whole SQL query.
So we are sure that an SQL Injection vulnerability is present in the web service!
Now we will send the following SQL injection payload:
' or '1'='1The above payload would result in the following SQL query being executed by the web service:
SQL Query:
SELECT username FROM accounts WHERE username='Jeremy' AND password='' or '1'='1';The condition on the right side of the OR clause would always evaluate to true since '1'='1' and therefore, even when the conditions on the left side evaluate to false, the result would still be true!
Therefore, sending the above payload in the password field should delete the account for the user named Jeremy:
Scrolling down reveals the account deletion message:
As you can see, we also get back the first flag:
flag1: 6701f2d8bf691da5ee694d3a1786a7e6
Step 12: Invoke the getAdminInfo method.
Check the WSDL file for the parameters required to invoke the getAdminInfo method:
As you can see in the above image, no parameters are required to invoke the getAdminInfo method.
Scroll down to the view the documentation for the getAdminInfo method:
This method retrieves some (non-sensitive) account details for the admin user. A sample request has also been provided.
Head over to Burp Repeater and send the following request:
Request:
POST /webservices/soap/ws-user-account.php HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
Content-Length: 387
Host: localhost
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ws-user-account">
<soapenv:Header/>
<soapenv:Body>
<urn:getAdminInfo soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
</urn:getAdminInfo>
</soapenv:Body>
</soapenv:Envelope>
Sending the above request results in a 500 response!
Scrolling down reveals that the only admin user could invoke this method:
So it seems like there is some restriction on the invocation of this method.
Step 13: Bypass the SOAP body restrictions using the SOAPAction header.
There is possibly a restriction on the invocation of the getAdminInfo method.
An alternative way to invoke a web service method is by using the SOAPAction header.
Information:
The SOAPAction header is a transport protocol header (either HTTP or JMS). It is transmitted with SOAP messages, and provides information about the intention of the web service request, to the service. The WSDL interface for a web service defines the SOAPAction header value used for each operation. Some web service implementations use the SOAPAction header to determine behavior.
Reference: https://www.ibm.com/docs/en/baw/19.x?topic=binding-protocol-headers
Head over to the WSDL file for the web service and inspect the soapaction attribute for the getAdminInfo operation:
SOAPAction attribute value:
urn:ws-user-account#getAdminInfoNow head over to the Burp Repeater window and send the following request:
Request:
POST /webservices/soap/ws-user-account.php HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
Content-Length: 228
Host: localhost
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
SOAPAction: urn:ws-user-account#getAdminInfo
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ws-user-account">
</soapenv:Envelope>As you can notice, we are sending the SOAPAction header and have removed the SOAP request header and body.
Sending the above request results in a 200 response!
Scrolling down the response shows the details for the admin user and the second flag:
flag2: 4315749f21a66fad53895daccbebf309
So that was all about WSDL enumeration, invoking hidden methods, performing SQL injection and bypassing SOAP body restrictions.
Step 14: Open the DNS Lookup web service.
Visit Web Services > SOAP > Command Injection > DNS Lookup:
That would take you to the following web page:
Step 15: Check the WSDL file.
Click on the WSDL link to view the WSDL file for the provided web service:
As you can see in the above image, lookupDNS is the only available operation:
Viewing the details for the lookupDNS operation:
The information on the web page reveals the input and output parameters expected by this operation. All this information could be inferred directly from the WSDL file as well.
Scroll down to view the sample request:
Step 16: Interact with the web service using Burp Suite.
Copy the sample request for the lookupDNS method to the Burp Repeater window:
Remove the /mutillidae part of the URL as the web service is located at /webservice and not at /mutillidae/webservice.
Once that is done, send the request:
We got back a 200 response!
Scroll down to view the DNS Lookup results:
Step 17: Identifying command injection vulnerability.
Send a semicolon (;) instead of a hostname:
Scroll down to view the DNS Lookup results:
Notice that the provided hostname was used as is and no errors were reported.
Send the following payload to the web service:
Payload:
;ls -alSending the above payload results in a 200 response:
Scroll down to view the DNS Lookup results:
Notice that the output for the ls -al command is retrieved!
So the web service is indeed vulnerable to command injection vulnerability.
Step 18: Retrieve the flag.
Since the DNS Lookup web service is vulnerable to a command injection vulnerability, send the following command to find the flag file:
Payload:
;find / -iname *flag* 2>/dev/nullSending the above payload results in a 200 response:
The output reveals that the third flag is present in the file /app/flag3.
Send the following payload to read the flag file:
Payload:
;cat /app/flag3
flag3: 6ae5422a0f086335766e1de8f75c16b7
So that was all about performing command injection attacks against web services.
And with that, we conclude this lab on attacking web services. There was a lot of ground to cover in this lab and we learned quite a lot of techniques to pentest SOAP-based web services and bypass SOAP body restrictions.