SoapUI - XML Entity Injection

So another thing that I tried out with some help from the guys I work with was this attack called XML Entity Injection. It has been around for quite a while and there are plenty of resources on it so I won't talk about it too much. Here is an OWASP reference and another link which was quite cool and explained things well.

In my previous post I described how to use SoapUI through Stunnel to test HTTPS web services. So following up on that, I was using SoapUI to test XXE attacks as well. So I followed stuff given above on the link to try and read the passwd file from the remote machine (which I'd confirmed was a Ubuntu box). To my pleasant surprise it immediately worked and the entire /etc/passwd file got displayed in the Soap response. Yay. Victory jig. And all that ;)

I was brought down to earth though when I saw an account called 'arvind' in the response. For some stupid reason, SoapUI was retrieving my own passwd file and displaying it in the response. Huh?

So I set Burp up again and set Intercept to on to see what was happening. To my surprise, the request itself already had my passwd file..and the response was just reflecting it back. So even before hitting my own client proxy SoapUI had done 'something' with my request, expanded my own entities and THEN sent it to Burp. It wasn't ever reaching the server directly. Meaning..if I used SoapUI there wasn't any way to directly test XXE...unless there was some tweak somewhere where I could turn off request parsing.

Anyway since I had Burp as well in my proxy chain before it hit the server, it didn't really matter and I could test it in Burp. Turned out that the server was not vulnerable at all. Oh well. Maybe next time it will be ;)

ASMX Webservices - XSS

I tested a few public Web services recently. 1 of them had a front end so it was easier to visualize but that apart it was quite tough, specially as numerous methods were so complex that the developers had a tough time trying to answer some of my questions.

Now assuming that the application that consumes the web services is not in testing scope, all you have is the .asmx and the .wsdl. At times, these methods might be invokable from the browser itself, via the ASMX web interface like this. Other times invoking is restricted to the local machine alone, in which case you have to use a third party client like SoapUI or write your own using a library. I wrote mine using a library called Suds (Python). Obviously, writing the client is more work and if the arguments that need to be passed are complex, it can be quite tricky.

There are 2 ways to test for SQL Injection or XSS. In my case I could invoke the methods via the browser, so that made it easier and I could find a SQL injection.

a) You can code your custom client and fuzz through that.
b) You can simply write a very simple client, with Burp set as a proxy. You can then use Burp Intruder or its inbuilt scanner to fuzz the application.

I wasn't lucky with the XSS though. The content type of the response was text/xml. I saw a few attack vectors for XSS in xml but all of them involved closing the existing XML tag but for any of them..I'd have to break out of the existing structure. And < and > were getting encoded..to &lt and &gt. So unless I could do that, I couldn't see anything anywhere that would make this vulnerable to XSS.

And much like my Flash post earlier, the content type is text/xml. So unless I could find a way to get a browser to forcefully treat it as text/html, there wasn't going to be a way to do this.

A colleague said this - "...In terms of triggering XSS it will be harder unless you can convince the client to render it using an XSLT" coz that would convert the XML into HTML. But I wasn't sure how I'd go about this. And then I ran out of time :).

So here I am. You guys know of how this is possible?

Update: I posted to the list and had a few ideas here.