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:
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):
Please feel free to expound on this thread, for others who do these attacks regularly.
"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'
OSCE, OSCP , GPEN, C|EH