Just wanted to throw this out to the collaborative, as a reminder that sometimes you can try TOO hard to exploit a system, when the keys are really closely within reach.  This isn't always the case, but sometimes it doesn't take rocket science to pwn a system.  Rather, just a little time and minimal effort.  (Note: many of yur customers will overlook very simple things, that can lead to disastrous consequences.  Case in point, the one below.)

This past week, I was asked to assist with a pentest for a customer with multile web applications.  One application, in particular,  was  a prime example of using very basic wsdl enumeration to help gain the 'keys to the kingdom'

Due to the very highly sensitive nature of the customer, I don't have ANY screenshots to post, however, I will give some generalized info, below, as to how the application more or less gave me all the information for complete network compromise.

For this test, I was tasked to do both internal and external testing, but to focus mainly on internal, up front, as they wanted me to focus most of my efforts on a new application, which was to be an employee-only app, deployed for some workflow processes.

I began with some session captures, and traced some local workstation traffic, to see what sorts of data were being passed, and noted a very basic lack of good session handling /validation, specific to this application.  ("No-no" / oops number one)  After a bit of research, I found that the application didn't time out said sessions, either, so I knew that if I could take advantage of anyone's session data / cookies, I could theoretically impersonate them, and gain furter information.  Next, I fired up ethereal, and ARP poisoned the gateway and workstation of a user, and fired up a paros proxy, to see if I could get the data I needed.  A short time later, I had, in my possession all the data I needed:  cookie data for the user session.

I watched and noted that the user pretty much stayed in the application, most of the day.  SCORE!!!  Got my session to ride on.

Now that I had an authenticated session, I hit their web application, resending the session info from my proxy captures, and had an authenticated session.  Now, said application didn't have much 'critical' information, at least in the sense of credit card data ot anything, BUT it did have one very interesting caveat...  The wsdl file.

A very generic description of wsdl scanning (there are multiple tools that can be used to both scan and exploit wsdl) can be found here:

http://minsky.gsi.dit.upm.es/semanticwiki/index.php/WSDL_Scanning

Wsdl scanning can provide some very valuable information.  In this particular case, however, it was enough to completely pwn their network.  Their wsdl exposed an element called 'get_ldap_config'  (Yep, I'm sure you see this coming - injecting data into a request to get_ldap_config returned a full LDAP credentialled account.  Did I mention, the configured account was a Windows 2008 Domain Admin?  :-)  )

Lessons to be learned -

If you're this customer, employ better session handling and validation, as well as changing the LDAP account for the app to one that isn't so critical.

If you're the tester, be sure to closely examine the apps you're testing, because the right opportunity may be just out of plain sight.

One of many articles about WSDL hacking (I advise all web-app hackers to become familiar with WSDL, as web services are becoming the all the rave):

http://www.soapui.org/SOAP-and-WSDL/web-service-hacking.html

Please feel free to expound on this thread, for others who do these attacks regularly.

Thanks for sharing. This is something I'll definitely be looking into. I'd heard of WSDL before but couldn't remember where. Referring to my copy of the The Web Application Hackers Handbook (2nd Edition), web services are only covered on pages 56-57!

Very nice, I sometimes use SoapUI and Burp (the Scanner Module and sometimes the Intruder) to attack WSDL's. It works okay, even though I have to do a lot of manual verification or whether an attack worked or not, plus Burp doesn't check for e.g. case-sensitive authentication, which is a common WSDL flaw plus a few other things I can't remember right now.

Anyway, it seems like the references you provided, pretty much cover the most common vulnerabilities of WSDL's. Haven't encountered any interesting bugs with WSDL's so far, even though it may just be me, but XML responses are boring compared to a website with developer comments, javascript containing sometimes bad functionality, or insecure scripts or backdoors.

The nice thing about both SoapUI and Burp is that they both support certificate based authentication, which is required by some WSDL's.


PS: Sent you a PM

While not a "bug," there may be additional functionality that could be abused. On one of my recent assessments, I found that they allowed entire SQL queries to be submitted in this manner. What!?

And yes, nice write-up, H.

Yeah.  In all honesty, I'd LOVE to find some GOOD training on webapps, all around, since, as everyone is noting, there is a lack in quite a few areas.  WSDL is one of many web-related areas that I find lacking in any training offerings I've seen, or managed to attend.

SANS' courses are great, but I've heard a lot of people say the 542 wasn't as in-depth as they'd like, so I'm cautiously optimistic for 642.  I know Kevin Johnson is da' man, and I'd love to get a chance to take 542 and 642 from him, if for no other reason than to pick his brain on some things (while, I'm sure, still learning a ton!), but affordability, in my situation, isn't there.

So I'm open to any suggestions anyone has.  I'm also currently waiting to see what Joe McCray is putting together, for his updated web app pentesting course, and watching some others, too.  Time will tell.  (But I'm eager to find good web app stuff, while still being less than optimistic, at times...)