Tricky exploit - a penetration test puzzle

In a recent application security audit for a web-site I came across a big, blaring breach.
while it's always fun to find a good vulnerability, it turned out to be quite tricky to actually exploit it. The trickiness was not due to good security practices but to pure (un)luck (depending on whose point of view). It seemed every angle I tried was off by just a tiny bit.

Eventually I managed to find an interesting multiphase exploit vector, and I think it makes for some interesting tinkering/reading.  I've created a mock-up replica of the vulnerable web-site to allow for testing and analysis. After reading the introductory section about the vulnerability, you may wish to try your wit against the mock-site and find it yourself, before reading on to the detailed exploit write-up.





The Target Site
This was your ordinary small company site.
It had 3 sub-systems:
1. a public site, available to any user.
2. a client site, requiring a login.
3. a printing system, requiring its own login.

After login to the client site, the user was shown a menu that contained a link to the printing system. In order to facilitate the user, the link to the printing system from the menu would try to use the previously given credentials from the client login and pass them on to the printing system for authentication. A poor man's SSO so to speak.



The Breach
It turned out that this "facilitating" method would pull the user credentials and post them to the printing system unencrypted via a client-side redirect!

Initially the user supplies the login credentials to the client site (login.php).
If successful, a menu is presented (menu.php).
A click on the "Go to Printing" link directs the browser to an intermediate page (printAutoLogin.php) that contained the user credentials in a pre-filled form that is immediately  auto-submitted to the printing system login page (printSystem.php) which checks them for validity.

 Click image to enlarge

Figure 1. Client side SSO. First redirect fetches user credentials and passes them to Print System.


The breach is crucial and apparent: the URL printAutoLogin.php returns the current user's name and password in clear text! This information is of course very valuable to the attacker. The only question remaining is, how can he get it??



Exploitation Problems
Finding a breach is one thing. Showing a functional proof-of-concept attack exploiting it is sometimes quite another. While the breach is what the client actually pays for, it is the exploit that gets his respect and admiration. Usually getting a working exploit takes some dull, dirty work of fitting loose ends in place, but in this case it turned out to be an interesting puzzle.

What I wanted to do was leverage an XSS vulnerability I had found in the site to get the user credentials. One way to do this would be to obtain the session cookie and use it to access the tell-tale URL impersonating the legitimate user and obtaining his credentials (assuming no IP checks are done). The cookie was set http-only which made this vector harder.

Another option was to get the credentials on the client side (using an xmlhttprequest) and have them sent directly. This would overcome the http-only problem, and would also be much cooler...


In practice XSS flaws were abundant. I found several around the site, but they were all just a bit off. Two were in different sub-domains, so they didn't have the session cookie set, and were prohibited from making cross-(sub)-domain xmlhttp calls. Another XSS was actually in the same sub-domain but used HTTP whereas the rest of the site was in HTTPS, so again no cookie (it was secure) and no cross-protocol calls.

Close but no cigar. Yet.



Playground version
Before I continue describing the exploitation method I found, I offer you the chance to play around and find it yourself: I've recreated the relevant parts into a simplified mock-website that you can play around with.

The website home page is: http://www.g1.playground.quaji.com/
Valid user credentials are : Name:user123 Password:pass123

You are welcome to stop reading and try your wit against it.
Note that this is not an armchair pen-test riddle. You'll have to get your proxies dirty to find some relevant details that I didn't describe yet to figure it out.

Your goal is to find and craft an XSS payload that will cause the user credentials to be sent to the attacker (an alert box with the info would do).




Feel free to leave your comments.
Please post only non-spoiler comments here, and the rest on the solution entry.


Solution
The detailed exploitation is provided in a separate blog entry.