I have been playing around with a lot of directory traversal attacks lately, and I wanted to experiment and see if a web service(SOAP) would be vulnerable to these types of attacks as well.
One of the web services that I was able to get to play with utilized SOAP (Simple Object Access Protocol) to interact with programs to pass data/execute methods across networks via XML. Here is the SOAP wikipedia page for more info on SOAP, as well as the W3schools page http://en.wikipedia.org/wiki/SOAP
http://www.w3schools.com/soap/soap_syntax.asp.
For a more general article of attacking web services using SOAP check this article by @cktricky http://resources.infosecinstitute.com/soap-attack-1/
As it turned out, there were some methods in this web service that dealt with the filesystem, and I suspected they would be great candidates for a directory traversal attack.
Since this service communicated using XML over HTTP POST's, I would need a tool that helped me efficiently submit requests without having to copy and paste the correct xml to a tool like burpsuite or something every time. I found a firefox addon called SOA Client which can be found here.
This tool loads a page in which you can select each method you want to play with as well as a box for inputting data. The page that SOA Client builds is based on the WSDL (Web Service Description Language) which is basically a roadmap for the service and the types of data it expects/returns, and the names of the different methods. You simply give the add-on the location of this WSDL page and it loads a much cleaner page that you can interact with.
If you are not familiar with directory traversal, it simply utilizes the filesystem special characters to allow a malicious user to jump to directories that they should not be allowed to access. For more info on directory traversal check out OWASP.
As I suspected, after putting in some test strings, these methods were definitely vulnerable to this type of attack. I was able to look at some of the source code for the service and it seemed that this attack was possible due to the path.combine method in .net. Here is the msdn site with the documentation on this method http://msdn.microsoft.com/en-us/library/fyy7a5kt%28v=vs.71%29.aspx.
"If path2 does not include a root (for example, if path2 does not start with a separator character or a drive specification), the result is a concatenation of the two paths, with an intervening separator character. If path2 includes a root, path2 is returned.."
path.combine(path1, path2)
What?! So the application was not even returning the first part of the path that it was suppost to, but was supplying my path since I was specifying a root path. That means that basically any time this method is used and the user input is stored into path2 with no filtering of special characters, it will be 100 percent vulnerable to a directory traversal attack. Why Microsoft made this method this way, I have no idea.
Moral of the story is: DO NOT TRUST USER INPUT, and do not store user input into the second field of the path.combine method. Or for that matter, do not even use the path.combine method if you are dealing with paths in a filesystem. You must, must, must sanitize/filter/scrub/clean whatever you want to call it, just do not assume that the user is going to supply the type of input that is application/service expects to receive.
