As far as I know, and at least according to Google, this is the first sessation-fixation vulnerability found in the information security history. Typos make you famous! ;)
Due to the fact the target web portal I was testing used the Joomla! built-in session management capabilities, before and after authentication, it was vulnerable. An attacker can exploit this vulnerability to hijack a user's session and gain unauthorized access to the protected portions (those requiring authentication) of the affected application.
Joomla! versions 1.5 through 1.5.15 are affected. Although I discovered the issue on version 1.5.14, and notified the Joomla! Security Strike Team (JSST) appropriately, through the Joomla Security Center and by e-mail on early November 2009, the fix couldn't get through the next version. The issue was fixed on version 1.5.16 (while the last available version as of today is 1.5.17).
As an exercise for the reader, you can review the Joomla! source code if interested on the fix; start with the "libraries/joomla/session/session.php" file (other files are affected too). The Joomla! session cookies are of the form "cookie_name=cookie_value", where both cookie name and value are MD5 hashes. Example:
Set-Cookie: f2345657e5f302e02d18922ba903a4ef=74d0a95cfdf16feb8a9678510686ba63; path=/
Although some public sources reflect session-fixation vulnerabilities can only be exploited by tricking the user into logging in after following a specially crafted link, this is not completely right. There are multiple methods and scenarios that a clever attacker (or pentester) can use to exploit it while combined with other vulnerabilities:
- The most commonly used method is the one referred above: an attacker can craft a web link that contains the attacker's session id. This is only possible if the application parses GET parameters to set the session id value, instead of, or as well as, cookies. During my tests I confirmed the target Joomla! application was vulnerable to this scenario.
- If the attacker can add or modify the contents of the vulnerable web server, or a web server on the same domain (depending on the scenario), she can potentially add contents to set the session id to her preferred value.
- Although XSS vulnerabilities are commonly demonstrated by stealing the victim's cookies, they can be used for the opposite action. An XSS can be leveraged to set the victim's cookie on an unauthenticated state, and gather higher privileges through the session-fixation vulnerability afterwards, once the victim has been authenticated.
- Another common scenario to exploit session-fixation attacks is focused on intercepting and modifying the victim traffic (unencrypted HTTP session) through MitM attacks. Due to the fact the victim is just browsing an unprotected portion of the site, he is not authenticated yet, the web application uses HTTP (vs. HTTPS). An attacker can easily inject a new cookie header ("Set-Cookie:") on that traffic, and its value will be accepted and used by the victim web browser.
Finally, there are a few lessons we should learn, and things we can improve, regarding the management of web application vulnerabilities (some of these also apply to other types of vulnerabilities). As I'm currently dealing with similar issues in other open-source and commercial web applications, I want to share a few thoughts:
- The resources and procedures available on lots of open-source projects and commercial companies to be notified and act upon security vulnerabilities can be clearly improved. I will suggest a few specific recommendations on a future post.
- Session-fixation vulnerabilities are extremely prevalent in lots of web applications and web-based products still today (wait for future related posts on this blog :).
- Although in theory, session-fixation issues can be simply fixed by using a different session id before and after authentication, it turns out that fixing session-fixation (as well as other session management) vulnerabilities is not an easy task. It typically affects multiple portions of the application, other related applications and modules, such as the authentication and authorization code. As a result, fixing it sometimes requires to fully redesign the web application.
- Based on the previous assertion, session management countermeasures must be planned and tested during the application design phase, unless you really want to feel the pain of fixing them afterwards.
UPDATE: This finding has been assigned Taddong's vulnerability id TAD-2010-001 for any further reference. A Taddong security advisory won't be released for it unless we identify enough demand from the infosec community.
Posts
3 comments:
Nice finding!
If i describe this as "the session token is set prior to authentication and does not change following authentication" are we talking about the same vulnerability ?
If so, it looks like its still in the current version Joomla 2.5.
Anonymous, yes, it looks like we could be talking about the same vulnerability but only that single fact does not ratify it. I recommend you to fully test it! Use a couple of web browsers, one acting as a client and the other one as an attacker.
Connect to the target web-app running Joomla 2.5 with the attacker browser, record the session ID, authenticate with a legitimate user ("attacker"), and check the session ID again (it should be the same, as you have already mentioned).
Then, connect to the target web-app with the client browser while intercepting his traffic. Modify the initial request to set the session ID the attacker obtained previously, authenticate with a different legitimate user ("victim"), and recheck that the session ID has not been changed.
Both browsers should be using the same session ID at this point. Now, go back to the attacker browser and interact with the application. Verify if the attacker gets access to his session ("attacker") or to the victim's user session ("victim"). If the latter, then it is vulnerable.
Post a Comment