Web Services Attacks
A web service is any software that is used for communication over a network. One
could imagine a web service as any function that performs a specific operation. Web
service may or may not include input parameters and may or may not return output
parameters. Input / Output parameters can be used as attack points to gain an entry
into web service to access confidential information. This guest blog post is to brief
you about some attacks one could perform to keep a tab on security vulnerabilities
within the web service.
Enumeration & Profiling
Suppose, there is a shopping website http://shoppy.com. A user could place an order
by clicking on “Place Order” button. The user is taken to http://shoppy.com/buy. An
attacker can check if a web service is involved or not by accessing
http://shoppy.com/buy?wsdl. WSDL file for the web service becomes accessible
through a browser. In this particular case, “buy” is a web service whose WSDL file
can be accessed by attaching “?wsdl” as the query parameter in the URL.
Flaws:
1. The WSDL file shouldn’t be allowed for public view in the first place. An
authentication process needs to be in place to check if an authorized user is
accessing the WSDL or not. Once WSDL is accessible, attacker can get
information about web methods, data types of input and output parameters,
end point information and others. This in turn can be used to exploit it
further.
Parameter Tampering
Attacker now knows about input and output parameters.
Meta characters: He could tamper using Meta characters like single quote, double
quote, ampersand, percentage and dollar symbols as input values for web methods
which consider an input.
Data type mismatch: Attacker may provide numeric values to string data type or null
values to arrays.
Large Buffer / Abnormal values: Attacker could also provide large values in the range
0 – 2^31. Highest value or lowest value for the input parameters may also break the
system.
Once inputs are provided and web methods are serviced by the web service, note
the <faultstring> messages in the web service response to the user. These should not
contain any confidential information about the web service.
This Web service accepts username and password as input and issues a security
token as output.
Web Service Request
<?xml version="1.0"?>
<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/envelope/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<Soap: Body>
<getSecurityToken xmlns=http://tempuri.org/>
<username>JohnA</username>
<password>Eiffel6Tower</password>
</getSecurityToken>
</soap:Body>
</soap:Envelope>
Web Service Response
<?xml version="1.0" encoding=”utf-8”>
<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/envelope/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<Soap: Body>
<getSecurityTokenResponse xmlns=http://tempuri.org/>
<getSecurityTokenResult>304334</getSecurityTokenResult>
</getSecurityTokenResponse>
</soap: Body>
</soap: Envelope>
XML Poisoning
One could add exploitable elements into existing XML build a SOAP envelope around
it and process it as a web service request. If appropriate validation is not in place,
exploitable elements might get into database or query critical information from the
server. Attacker can also use this attack to observe <faultstring> messages returned
in the response to gather information about the server.
Directory Traversal
Attacker could look for Autoexec.bat script by keying in../../../../Autoexec.bat or
using different versions of the same command to get hold of automatically
executable batch files.
<faultstring> messages sometimes return directory paths. Consider the following
example:
<faultstring>
Server was unable to process request. --&gt; Could not find file &amp;
quot;c:\inetpub\wwwroot\news\junk&amp;quot;.
</faultstring>
Attacker now knows about c:\inetpub\wwwroot\news\junk!
SQL Injection
Keying in symbols like single quote, double quote, hyphen, asterisk, and common
parenthesis may result in different <faultstring> messages provided the input
parameters were acting as direct inputs to the database query executed at the
server level.
Using 1’ or 1=1 may return complete records of username.
In above web service request, replace JohnA with 1’ or 1=1 as input. If the web
service was performing a query like Select * from username where
username=’JohnA’, using the input 1 or 1=1 would result in a query Select * from
username where username=’1’ or 1=1 hence displaying complete details for the first
record in the table. Using this, user may even drill down to other records in the table
using smart SQL queries.
HTTP method tampering
Web services will include a GET or POST method to support its operations. Using GET
method to transfer confidential data is not secure enough. Any services using GET
need to be cross checked by processing them using Burpsuite or wsKnight tool and
checking what data gets submitted and returned through the web service. POST
methods need to be converted to GET and check if any confidential information gets
revealed.
SOAP message tampering
1. Providing * in input fields in web service request above may return several
records if suitable validations are absent
2. Attackers could use brute force method to continuously key in username and
password to gain illegal entry into secure area of the server. Note that there
is no account lockout policy at Soap request level (Good Catch?)
3. Parameter Guessing can be used to continuously guess username and
password using social engineering attacks, observe the <faultstring>
messages, and fine tune guessing method to get access to web service.
OS command execution
Users could append valid operating system commands to input parameters and get
access to confidential information.
For eg. “JohnA” | ls –r
Above input may process JohnA as username and also pass on ls –r command to list
down directories in Unix OS.
This blog post is an overview of different ways to attack web services. This is a
guideline on how web services can be exploited. Attackers can devise more powerful
attacks to gain access to web services.