Shibboleth Example Login Page: POST Location Hijacking Vulnerability

EDIT: This flaw, according to the lead Shibboleth developer, was discovered and patched in late 2008. It seems that a number of universities are still running outdated copies of the software, which is what I found in my research. If you are running the latest version of Shibboleth (2.2.0), you should be perfectly fine.

Normally I'd be rather happy with myself for finding an XSS flaw in a number of different login systems. However, sometimes it is just icing on the cake. The interesting flaw here is a vulnerability that allows an attacker to control the POST location of login forms in poor implementations of a widely used login system called Shibboleth, thanks to a weakly protected example login page.

Now first, to be clear, this certainly was not entirely the fault of the Shibboleth developers. In fact, they probably knew the example wasn't secure, and assumed that anyone implementing their own login system would surely lock down the page. In addition, most of the implementations are, in fact, secured. That said, the small minority that failed to add proper sanitation of user input left their login systems wide open to phishing attacks.

So onto the vulnerability. Awhile back, my school switched over to Google Apps for their email, and used Shibboleth (as many schools do) for authentication. This wouldn't be a problem, but someone apparently didn't pay enough attention to possible security holes in the demo application, as they should have. And, as it turns out, some other universities made the same mistake.

I found the issue when I got curious one day about how the authentication system worked. I started doing some poking around with TamperData to see where my browser was being redirected to during the process. My attention was drawn to a parameter set on the school's login page named "actionUrl". It's default value, set during a redirect, was "/idp/Authn/UserPassword". Curious, I of course changed the parameter to a remote url, "http://google.com". I refreshed, clicked submit, and sure enough, the form attempted to submit the form via POST request to Google.

PoC:https://myvulnlogin.university.edu/idp/login.jsp?actionUrl=http://google.com

Clearly, not good. To make matters worse, it would also accept a POST variable if the GET variable wasn't set, meaning I could create a malicious link that linked directly to the official login page, POSTs to a webserver that I control, AND is entirely transparent to the user (same website, valid SSL cert, no strange GET parameters). I'm not entirely sure they could have made phishing any easier for an attacker. However, exploiting this through POST requests can be quite difficult through email based methods, so doing things this way requires a rather different approach that I might make a post on later.

For the time being, the GET PoC is more than sufficient to demonstrate how bad the problem is. If you want to prove that it actually works, I recommend using GNU Citizen's simple x.php script, or (like I did) rolling your own in Python. Finding vulnerable servers is a bit annoying, as many of them have indexing disabled in their robots.txt, and some vulnerable servers don't explicitly have the "actionUrl" parameter in their URL, but searching inurl:"idp/login.jsp" still brings up a few vulnerable pages. Chances are though if you are at or have recently attended a university, you have probably used Shibboleth-based authentication at some point, and that the login page is possibly vulnerable.

As stated before, these pages are also vulnerable to reflected XSS attacks in the same parameter, but truthfully there's not too much reason to use it when you can so easily capture a target's username and password in an almost completely transparent manner, unless you'd just rather hijack their session for some reason. Hopefully those who set up these pages will fix these flaws before phishers and the like start taking advantage of their quite serious shortcomings. As it stands, my university still hasn't (over two and a half weeks after I notified them), so I'm hoping this release will encourage them to fix their site, as well as make people aware that there is a problem. More likely, however, it will just encourage them to yell at me. So it goes.


Written by admin in Code, Vulnerabilities on Thu 09 December 2010. Tags: implementation fail, phishing, post hijacking, shibboleth, xss,


Copyright Ben Schmidt 2015