High This is a general authentication security hole with Confluence tested in version 2.10.2.
Here is how the attack works:
1.Attacker logs in via the login page and two things happen:
a.A cookie gets stored on their browser with name=JSESSIONID, value=cookie_val, path=/, domain= whaterver the domain is (perhaps A.B.example.com).
b.A record gets stored to some database tying the attackers account to cookie_val.
2.The attacker logs out via the logout.action script.
a.The record on the database tying the attacker's account to cookie_val gets deleted or inactivated.
b.The cookie on the attacker's browser doesn't get deleted (but even if it did they could restore it since the attacker has complete control over their own browser).
3.The attacker stores a cookie to the victim's browser:
a.The cookie that is stored has name=JSESSIONID, value=cookie_val, path=/, domain= the most general parent doman (perhaps .example.com) under which Confluence is located (this cookie will be submitted to every page in any subdomain of that parent domain and can be set in any subdomain of that parent domanin).
b.The most common way that an attacker would store a cookie on a victim's browser is through an XSS hole (http://www.owasp.org/index.php/XSS), but other vectors exist such as header injection.
4.The victim clicks on a link that the attacker provides (which stores the cookie on the victim's browser and redirects them to the login page) and then the victim logs in normally.
a.When the victim logs in, a record gets stored to some database tying the victim's account to cookie_val passed in.
5.The attacker (who has the same cookie as the victim now) goes to dashboard.action and can act as the victim.
- causes
-
CONFSERVER-18120 Unable to use HTTPS for login only
-
- Closed
-
[CONFSERVER-15108] Session Fixation attack using JSESSIONID in Confluence
It should be noted that the latest reviewed implementation only invalidates the session on login. Given that the credentials of a privileged user can only be passed to an attacker via login, it was deemed sufficient to patch this critical path only.
This is still exploitable using confluence-project-3.0-stable
(demoed to Dave)
Ben L Broussard
added a comment - While unrelated to Confluence, a similar issue to this may exist in JIRA. Through some initial testing, I have some reason to believe that a similar session fixation does exist in JIRA, although it may require IP spoofing.
Ben L Broussard
added a comment - While unrelated to Confluence, a similar issue to this may exist in JIRA. Through some initial testing, I have some reason to believe that a similar session fixation does exist in JIRA, although it may require IP spoofing. The patch files CONF-15108-patch-2.10.3.zip and CONF-15108-patch-3.0.1.zip (above) can be applied to 2.10.x and 3.0.x versions of Confluence to fix the vulnerability.
Stop your Confluence instance and extract the appropriate zip file into the WEB-INF/classes directory of your Confluence installation. The seraph-config.xml should replace the existing one, while the SessionInvalidatingLoginInterceptor class is new.
Restart your Confluence instance.
Any reason not to add logging to SessionInvalidatingLoginInterceptor at the point of invalidating the session? If the attack is made and stopped it might provide information leading to the provider of the bad cookie.
Fixed.
Implementation notes:
- any session record associated with the client's JSESSIONID (real or injected) is invalidated when login.action is accessed
- a user's session is invalidated on logout.action. A successful attack requires that the attacker log out (otherwise, when the victim accesses login.action they won't get a login dialog, but a message reading "You are currently logged in as <insert attacker's name>."). Invalidating the session here will render the JSESSIONID used in the injection attack useless.
Ben L Broussard
added a comment - Can admin@wikis.utexas.edu be added as a watchers on this task? I found and reported this vulnerability, but they run the Confluence instance here.
Ben L Broussard
added a comment - Can admin@wikis.utexas.edu be added as a watchers on this task? I found and reported this vulnerability, but they run the Confluence instance here. Ben L Broussard
added a comment - The more direct safeguards part at the bottom is what I would suggest with some clarifications.
- On logout, destroy the session record associated to the cookie. You can't force a malicious user to delete a cookie stored on their browser.
- On login, always set the JSessionID cookie to some default value. This will overwrite the current cookie of the user. Two points that are important here are: If you effectively log someone out every time the hit the login page, then there could be some usability concerns (although this is pretty standard), also when you get a cookie in the Cookie request header, you get only the name and value, not the domain, path, or anything else. The Set-Cookie response header contains the various cookie parameters like domain.
- Correlating a session with an IP address can be very powerful but will force certain routing systems not to be able to use your software. This is primarily a problem with Onion Routing, certain ISPs, and people with cycling IPs like dialup users.
Generally steps should be destroying the session record on logout and setting a null cookie at the login screen. Correlation is more case-by-case, and since you want your product to have the largest market share, you may not want to do IP correlation.
Ben L Broussard
added a comment - The more direct safeguards part at the bottom is what I would suggest with some clarifications.
On logout, destroy the session record associated to the cookie. You can't force a malicious user to delete a cookie stored on their browser.
On login, always set the JSessionID cookie to some default value. This will overwrite the current cookie of the user. Two points that are important here are: If you effectively log someone out every time the hit the login page, then there could be some usability concerns (although this is pretty standard), also when you get a cookie in the Cookie request header, you get only the name and value, not the domain, path, or anything else. The Set-Cookie response header contains the various cookie parameters like domain.
Correlating a session with an IP address can be very powerful but will force certain routing systems not to be able to use your software. This is primarily a problem with Onion Routing, certain ISPs, and people with cycling IPs like dialup users.
Generally steps should be destroying the session record on logout and setting a null cookie at the login screen. Correlation is more case-by-case, and since you want your product to have the largest market share, you may not want to do IP correlation. 
The fix works correctly for the default configuration of tomcat. However if you configure emptySessionPath="true" for a tomcat connector, the session HttpSession.getSession(true) still returns a session with the old/attacker's session ID even after it's invalidated: https://jira.jboss.org/jira/browse/JBAS-4436, http://stackoverflow.com/questions/8318/resolving-session-fixation-in-jboss.
This is applicable for both Tomcat 5.5 and Tomcat 6. The default Tomcat configuration works correctly as the default value for the emptySessionPath parameter is false.