1586241 - Improper Session management can cause account takeover

Status: RESOLVED DUPLICATE of bug 961775

(Websites :: Other, task)

Description

[u646983]

Attachment: Description: in this vulnerability , when a user login the cookies were generated in which the session id and password are generated .so when user login or logout the cookies change every time. but in most sites there is a issue in which the site token or

hello, Im Mahendra Purbia Security researcher and pentester and i found a bug in your site in which the attacker can login with cookies.

Description: in this vulnerability , when a user login the cookies were generated in which the session id and password are generated .so when user login or logout the cookies change every time. but in most sites there is a issue in which the site token or cookie not expire every time when login or logout.
so with this vulnerability attacker can login with cookies with all permissions that a user have.
Vulnerable domain: addons.mozilla.org

steps to reproduce:
1.create a account in addons.mozilla.org
2. then verify and login
3. when user login the cookies were generated so use the cookie editor extension to copy the cookies
4. now logout form that session
5. now login in another browser and then with the use of cookie editor paste the copied cookies in that broswers
6. hurray! you logged in successfully

{ in this scenario the cookie not changing every time so attacker easily takeover the account of users.}
i hope you understand and i attached poc below. for more detail ping me.
attacker can also able to exploit html scripts with cookies .

i hope this time my report is valid

Comment 1

[u646983]

pls check this report

Comment 2

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Mahendra: If I'm understanding you correctly, you have a single user, where you copy session cookies from that user to a new profile and can then authenticate as that user. If that is true, this is functioning as designed, assuming the session cookie is only valid for the specific time window in which it was created. Please correct me if I'm misunderstanding, I'm marking this as invalid for the time being until we understand this better.

Comment 3

[u646983]

no you not understand properly
in this vulnerability there is a critical issue is that the cookie not changing everytime when a user logout
so its easy for attacker to takeover the account
if you need refrence pls reply

Comment 4

[u646983]

https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication
in this link given refrence about the attack scenario

Comment 5

[u646983]

you can check this attack also in bugzilla.mozilla.org for checking that how its work
i test this in bugzilla but this domain is secure with this, every login logut change the cookies every time
if cookies not change properly they attacker edit this cookies and then exploit this as html injection

Comment 6

[u646983]

What information you need pls ask me

Comment 7

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Mahendra: if memory serves, AMO (addons.mozilla.org) utilizes FxA (accounts.firefox.com) as it's auth provider, so what might be happening is that the session is simply re-used on the app layer until the cooke session expires, rather than at log out. I'll investigate a bit closer and report back, thanks!

Comment 8

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Mahendra: I went to AMO, went to login, got redirected to FxA (for authentication), then redirected back to AMO with an authenticated session. In this session my 'session' cookie assigned is a JWT (JSON Web Token), which has a validity window. If I then logout, the JWT is removed from the browsers cookie store and then when I login again, I receive a new JWT for the session cookie. When I compared those keys, they were not the same. Additionally, it does not surprise me that the logout operation does not invalidate the JWT, the JWT has it's own validity window, which will likely expire in due time. Could you provide more specifics as to what you think the problem is? Is it possible we're talking about different cookies?

Comment 9

[u646983]

i attached a poc in my report pls check that what i do

Comment 10

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

(In reply to Mahendra purbia from comment #9)

i attached a poc in my report pls check that what i do

Mahendra: we don't accept video PoC's, they introduce too much risk for the bounty triage team and it's much more helpful to denote information in text. Please see this section of our bounty guidelines for the snippet about video submissions (https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/#bug-reporting)

Comment 11

[u646983]

ohk then i will explain you with text
bug give me time.

Comment 12

[u646983]

https://hackerone.com/reports/6504
pls read this report so u understand what im talking about, this vulnerability is verified by Hackerone & bugcrowd

Comment 13

[u646983]

The problem is that the cookies stored on the browser are not getting expired after logging out from the platform

Comment 14

[u646983]

https://hackerone.com/reports/263873 see this also

Comment 15

[u646983]

Attack Scenario :-- If The Attacker Got his Hands Upon Users Cookies he can Get Access To the User Account.An attacker can get the user session cookies by any means Session Spoofer, Cookie Stealer etc.As the user cookies are not expiring so an attacker can directly inject the stolen cookies of a victim in a request from browser and thus can have access to the victims account.
So expire the cookies once a user is logged out of the website.

Comment 16

[April King [:April]]

Please note that session fixation bugs are not covered by our bug bounty program, as noted on our web bug bounty page:

• Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)

https://www.mozilla.org/en-US/security/web-bug-bounty/

Comment 17

[u646983]

But its a critical vulnerability and I'm not mention that it is a session fixation
I reported you more than 4 times but every time you reject my report either is valid .
But every time im not wrong
So pls you don't want to give me bounty no problem
But pls give me my right a HOF swag

Comment 19

[u646983]

Hey my report is not related to session fixation
Pls give my right to me my hof

Comment 20

[u646983]

You cheated with us

Comment 21

[u646983]

Hey anyone here

Comment 22

[April King [:April]]

It is a duplicate of the bug above, and falls into several categories of ineligibility as per our bug bounty program, particularly requiring you to have access to a user's local cookie store.

Please note that if you continue to badger the people who are handling these bug reports that you will be disqualified from future participation in the Mozilla bug bounty program.

Thank you for your understanding.

Comment 23

[u646983]

Reply and give my right
Otherwise I will disclose my report in public
Bcoz you doing with me this 4rth time

And it's enough

Comment 24

[u646983]

I'm disclosing my all report which I reported to you via medium

Comment 25

[April King [:April]]

I have removed the security sensitive flag from this bug, so it is now publicly visible.

Comment 26

[u646983]

No I have more bugs but now I. Not report it to you
I directly public the bugs
Bcoz I know again give me a duplicate and fix the bug
Yo don't do good with me
It's only a HOF but you don't give me

Comment 27

[u646983]

(In reply to April King [:April] from comment #25)

I have removed the security sensitive flag from this bug, so it is now publicly visible.

Hi Team, can you please private this report.I don't want to disclose this because its effecting my work and judged by peoples because of this old report.
<<<Privacy concern>>>

Comment 29

[u646983]

Can you please private this report. Its a request

Comment 30

[Frida K [:frida]]

Hello,

Please do not modify the status of the bugs. If you think this bug should be re-opened, please let us know and we will look into it.

I will check with the team whether we want to make this report private.

Thanks,
Frida

Comment 31

[u646983]

Hi Frida,
this report affecting my reputation and getting judged by peoples around me. so please its a humble request to private this report.

Thanks.

Comment 32

[Daniel Veditz [:dveditz]]

(In reply to XOX from comment #27)

Hi Team, can you please private this report. [...]
<<<Privacy concern>>>

Unfortunately no -- as it says when you sign up for an account here bugs are eventually made public because of the open-source nature of our project.