View Issue Details

IDProjectCategoryView StatusLast Update
0011296mantisbtsecuritypublic2024-01-31 05:49
ReporterBuffer Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version1.1.8 
Summary0011296: Mantis BT is using fix cookies in the DB
Description

Dear Mantis developers,

During testing Clientless SSL VPN vulnerability, with a malicious webpage to steal cookie through SSL VPN, I found something a little bit bizarre in Mantis BugTracker.

In fact, the cookie for each user is fixed and never changes. As I remember, cookie must change for each server session, and must be unique for each server session.

This is the not the case with your BT application, because cookie is simply fixed and stored in the database. Just for advise, I'm not sure this is the right design, as anyone can steal cookies using XSS or many other attacks' vectors. When the cookie is stolen, even if you click on logout, session never expired.

With Tamper Data or any Firefox plugin, I just logged in as the user I want just by filling HTTP Cookie header with MANTIS_STRING_COOKIE right value, for targeted user (and even if the user logout before!).

Steps To Reproduce
  • Login as a known user
  • Copy the MANTIS_STRING_COOKIE value available in HTTP Cookie Header, or copy the "cookie_string" value for the specified user in the SQL table "mantis_user_table".
  • Click logout when viewing my_view_page.php (normally at this time, cookie string must be destroyed/changed as the session or any authentication value).
  • Set the value MANTIS_STRING_COOKIE when viewing the login page with the stolen cookie, with TamperData/LiveHeaders or any Firefox plugin to alterate HTTP headers/data.
  • Now you're login fraudulently without login / password provided ! Moreover, you can change user options, user password or profile, without providing any form of authentication ... just great for hackers ...
Additional Information

Waiting for your update / ack or patch / release information before Full-Disclosure on SecFocus(BugTraq), as it's an important security issue.

TagsNo tags attached.

Relationships

related to 0010709 closeddhx Use HttpOnly cookie flag to protect cookies from client-side Javascript manipulation/theft 
has duplicate 0012277 closeddhx Cookie tokens are constant for a particular user 
related to 0027976 closeddregad CVE-2009-20001: User cookie string is not reset upon logout 
related to 0033587 closeddregad "MANTIS_STRING_COOKIE" cookie reusable after user logout 

Activities

Buffer

Buffer

2009-12-26 12:41

reporter   ~0023987

Last edited: 2009-12-26 12:44

Any news / ACK to this potential vulnerability ?

If no quick update, will be published next week on SecFocus FD Mailing ...

vboctor

vboctor

2009-12-27 04:31

manager   ~0023988

We've done the work to protect the cookie in 1.2.0rc2 (issue 0010709). We currently change the cookie when the user changes their password. However, we could potentially do that more often, i.e. for each session.

If we do that, we should make sure that a SOAP login doesn't log the user out of a web session.

That would also mean that if a user logs in, the user would be automatically logged out on other browsers / computers.

jreese

jreese

2009-12-27 08:27

reporter   ~0023990

First, there is a user-controlled option already to limit sessions to a single IP address, and is allowed to be disabled by the user in cases where the user is behind a proxy setup with multiple exit points. Secondly, I think the real solution is to not store the user's cookie in the database. This is what the user's session ID is for, and I really think Mantis' existing concept of verifying the user's cookie from a value stored in the database is useless and outdated.

The real question is exactly how do we proceed from this point forward? I personally would like to see the current cookie verification routines replaced by special handling in the session API. Thoughts?

vboctor

vboctor

2009-12-28 03:19

manager   ~0023993

@jreese, I agree with your suggestion and I like the fact that it supports multiple sessions.

However, I like the currently ability for a user to expire all their active sessions independent on the computer / browser by changing their password. The actual change of password doesn't affect the cookie, but at one point I've made this roll a new cookie. This is useful if a user remembers that he/she forgot to logout on some other machine they used.

Hence, I think it would be great if we would be have a solution to support both. But, for simplification, I'm OK with compromising the remote logout feature if necessary.

giallu

giallu

2009-12-28 03:51

reporter   ~0023994

I've just read the Zend_Session class docs, in particular http://bit.ly/5m92La and they suggest regenerating a new session ID at each client request with the regenerateId() static method.

I wonder if we could let our MantisSession class derive from Zend_Session, call regenerateId() early in the page generation and be done with this.

vboctor

vboctor

2009-12-28 04:08

manager   ~0023995

The technique they are using looks good, but I expect that we are looking at fixing this for 1.2.x and maybe 1.1.x and hence we shouldn't be taking a dependency on ZF.

dhx

dhx

2009-12-28 07:51

reporter   ~0023999

One of the problems with using PHP sessions is that the lifetime of the PHP session cookies is (generally) set with a global PHP option. One of the use cases of MantisBT is that someone may leave a message half typed on a Friday afternoon with the expectation that they can finish it off on Monday and submit it. You may have PHP setup differently for another application where you want much shorter session expiry times. I'm fine with requiring them to reauthenticate due to an expired session cookie - as long as the data they're posting isn't lost.

Users may login to the same account simultaneously from different devices (a mobile phone and a desktop computer for example). Therefore we can't just delete a session cookie that may still be in use by another device/login instance. We really need to remember a session key for each session (in the previous example, once for the mobile phone and then again for the desktop computer).

Changing the session ID won't work as giallu suggested because users may open up 10 forms/pages in Mantis and submit them in any random order. We can't assume that users are browsing within their session using a linear one-page-at-a-time approach. Unless of course giallu was just referring to creating a new session key upon a new login, and using this key for all page requests until the user logs out.

PHP's inbuilt session support would be the ideal method to use if we can figure out the maximum session lifetime correctly. In other words, we need to ensure all submitted forms remain intact while re-authentication is occurring.

In the future I'd really like to add user audit logs that are viewable by not only administrators, but the users themselves. This would allow users to see the last 5 times they logged in, where those logins originated from, etc. The users would also be able to view all current sessions they've got open, with the ability to terminate any or all of them.

jreese

jreese

2009-12-28 09:25

reporter   ~0024000

Perhaps we could reuse the existing reauth methods, and combine the existing db-stored cookie with a per-session id. If the user's PHP session get's flushed/expired before submitting a form, we could pop the reauth dialog to make sure the user knows the correct password. This would also solve the underlying security issue, such that when a malicious user starts a new session with someone else's db cookie, it will trigger a reauth rather than simply giving them access.

Thoughts?

giallu

giallu

2009-12-28 09:34

reporter   ~0024001

@dhx: I'm no expert here, but as I understand it, the approach Zend advocates is something like:

  1. login, your browser get a session with a certain ID
  2. browse to another page, your browser is given another random ID so it's nearly impossible to spoof it

@vboctor, 1.1 is tricky but if we think the approach is good and the PHP requirement matches ours I can't see why we shouldn't; I checked and this particular class does not depend on anything else in the ZF.

Alternatively, we could just grab the logic and implement it in our classes.

dregad

dregad

2020-04-18 12:12

developer   ~0063851

Community-proposed PR https://github.com/mantisbt/mantisbt/pull/1653

As per my review comment, I think the proposed change is not acceptable as it prevents simultaneous sessions from multiple devices.

dregad

dregad

2021-02-13 16:01

developer   ~0065103

Last edited: 2021-02-13 17:28

Community-proposed solution (source: https://github.com/mantisbt/mantisbt/pull/1653#issuecomment-707803945)


Currently, when a user logs into Mantis for the first time, or when the user changes their password, Mantis will generate a unique session key, store it in the database, and then set it as a cookie on the client. This has a few unintended security implications:

  1. The session cookie never expires on the server, giving an attacker a theoretically unlimited window in which to steal and take advantage of it.
  2. The session cookie only changes when the user’s password changes, which means that if an attacker is able to steal the cookie, they can use it for a very long time.

To fix this, we need a solution that:

  1. Allows users to log in from multiple devices simultaneously
  2. Assigns a unique session ID to each session
  3. Allows session IDs to expire when they reach a certain age and/or a certain period of inactivity

Current design

In the Mantis database’s user table, there is a “session_cookie” column that stores a single, rarely-changing cookie. The database also stores the date and time of the user’s last visit, but there is no way to know when the cookie was first set, or from where the user logged in.

Proposed design

Create a new table, named “mantis_session_table”, containing the following columns:

  • User ID
  • Client IP address (note: may be IPv4 or IPv6)
  • User agent
  • Session cookie
  • Date created
  • Date last accessed

The user ID, IP address, and user agent will be used to uniquely identify each session, each of which will have a unique, randomly-generated session cookie. The date created and date last accessed will be used to expire session cookies when they become too old and/or when too much time has passed since they were last used.

New options will be added to mantis_config_defaults_inc.php to specify two new settings:

  • The maximum age of a session. After this much time has elapsed, the session will be deleted and the user will need to reauthenticate.
  • Session timeout. If this much time passes without a session being used, the session will be deleted and the user will need to reauthenticate.

Note that it is not necessary to delete sessions immediately when these thresholds are reached. We can wait until the session is next validated, at which point we decide if we continue to use it or delete it.

Related Changesets

MantisBT: master 6f369a5a

2021-02-13 12:33

dregad


Details Diff
Reset user session cookie string upon logout

When a user logs out from Mantis, we clear their session cookie string
(i.e. set mantis_user_table.cookie_string column to an empty string).
This ensures that anyone knowing its value is no longer able to login
with it.

On login, after successfully authenticating the user, when setting
the cookies in auth_set_cookies() we check if the cookie_string is
defined in the DB, and if not a new hash is generated and stored.

While not a complete fix for issue 0011296, this does improve the
situation by providing an easy and logical means for users to
effectively invalidate all their previous sessions.

Additionally, using an empty value to indicate an invalidated cookie
string instead of directly generating a new hash makes it easy to:
- identify user records which should be considered as logged out
(e.g. last_visit older than $g_cookie_time_length)
- invalidate login cookies (set them to '')
Leveraging this is left for future improvements.

Note: an empty string in the session cookie always triggers an anonymous
login (or sends the user back to login page if anonymous login is
disabled).

Fixes 0027976
Affected Issues
0011296, 0027976
mod - core/authentication_api.php Diff File

MantisBT: master-2.24 79a78c09

2021-02-24 08:16

dregad


Details Diff
Set a new random cookie string upon logout

When a user logs out from Mantis, we reset their session cookie string.
This ensures that anyone knowing its value is no longer able to login
with it.

While not a complete fix for issue 0011296, this does improve the
situation by providing an easy and logical means for users to
effectively invalidate all their previous sessions.

Additionally, using an empty value to indicate an invalidated cookie
string instead of directly generating a new hash makes it easy to:
- identify user records which should be considered as logged out
(e.g. last_visit older than $g_cookie_time_length)
- invalidate login cookies (set them to '')
Leveraging this is left for future improvements.

Note: an empty string in the session cookie always triggers an anonymous
login (or sends the user back to login page if anonymous login is
disabled).

Fixes 0027976

(cherry picked from commit d8181a548e5131eede5d3b891bec0df68b472ba9)
Affected Issues
0011296, 0027976
mod - core/authentication_api.php Diff File