View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0027976 | mantisbt | security | public | 2021-02-12 06:37 | 2024-01-31 05:49 |
Reporter | vaibhs | Assigned To | dregad | ||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Target Version | 2.24.5 | Fixed in Version | 2.24.5 | ||
Summary | 0027976: CVE-2009-20001: User cookie string is not reset upon logout | ||||
Description | VULNERABILITY NAME: SESSION HIJACKING. VULNERABILITY URL: https://bugs.kali.org/ DESCRIPTION: Please check this issue I sent this issue on https://bugs.kali.org/ but on there Mr. rhertzog said to send this issue on here that's why I send this issue here...please check and replay back regarding this vulnerability issue. | ||||
Steps To Reproduce | STEPS TO REPRODUCED: | ||||
Additional Information | The Patch: IMPACT: The malicious attacker can enter the server and access its information without having to hack a registered account. In addition, he can also make modifications on the server to help him hack it in the future or to simplify a data-stealing operation. Please check this issue I sent this issue on https://bugs.kali.org/ but on there Mr. rhertzog said to send this issue on here that's why I send this issue here...please check and replay back regarding this vulnerability issue. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Thanks for your report. In the future, please submit security issues as private, which avoids unwanted early general disclosure before we have time to review and possibly patch the issue. I would also kindly suggest you ask the people at kali.org to do the same for https://bugs.kali.org/view.php?id=7044. I need to analyze this, but here are some preliminary remarks:
|
|
Also, as a side note, you're only hijacking yourself here... How would an attacker obtain your cookies (and use them, if you restrict your session by IP) ? |
|
So after a quick check, I can confirm that we do delete the session cookie, when logging out, yet the behavior described does allow to login with the previously stored cookie string. So the problem's root cause is actually the reuse of the cookie string, as discussed in 0011296. Without going for a full rewrite as discussed there, we could probably mitigate the risk by invalidating the user's cookie string upon logout. |
|
Proposed fix: PR https://github.com/mantisbt/mantisbt/pull/1737 Note: I'm setting this back to public, considering that it's basically the same issue as 0011296, which has been out in the open for over 12 years... |
|
Hello Team, Regards, |
|
@vaibhs I don't know what you're talking about. I never said the issue is not valid (I would have closed it if that were the case), in fact I even proposed a fix for it which is currently being discussed.... Also, no idea where this reward thing is coming from. If you're getting paid for it then good for you but it's not our concern. |
|
Changed target to 2.24.5 |
|
CVE Request 1039557 sent |
|
CVE-2009-20001 assigned |
|
MantisBT: master 6f369a5a 2021-02-13 12:33 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 d8181a54 2021-02-24 08:16 Details Diff |
Set a new random cookie string upon logout Per @vboctor's request in PR review [1]. This reverts the earlier implementation, where the cookie string was set to '' and a new one generated at next login. Fixes 0027976 [1]: https://github.com/mantisbt/mantisbt/pull/1737 |
Affected Issues 0027976 |
|
mod - core/authentication_api.php | Diff File | ||
MantisBT: master-2.24 79a78c09 2021-02-24 08:16 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 |