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.