View Issue Details

IDProjectCategoryView StatusLast Update
0022690mantisbtsecuritypublic2017-04-16 19:44
Reporterhyp3rlinx Assigned Todregad  
PriorityimmediateSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.0-rc.2 
Target Version1.3.10Fixed in Version1.3.10 
Summary0022690: CVE-2017-7615: Account verification page allows resetting any user's password
Description

John Page AKA hyp3rlinx reported the following security issue by e-mail:

I want to report and make you aware of following security issue, attackers can hijack accounts if only supplying the user ID and username.

In verify.php we find:

if( $f_confirm_hash != $t_token_confirm_hash ) {

If supply empty string we easily bypass security check.

e.g. go to this URL in browser after you logout of mantis.

http://127.0.0.1/mantisbt-2.3.0/mantisbt-2.3.0/verify.php?id=1&confirm_hash=

This will then allow you to change passwords and hijack accounts.

For credits use:

John Page aka hyp3rlinx / ApparitionSec
hyp3rlinx.altervista.org
TagsNo tags attached.
Attached Files

Relationships

parent of 0022738 closeddregad CVE-2017-7615: Account verification page allows resetting any user's password 
parent of 0022739 closeddregad CVE-2017-7615: Account verification page allows resetting any user's password 
related to 0022736 closedatrol Strange e-mail from: vboctor@mantisbt.org about Critical Issue 
related to 0022737 closeddregad CVE-2017-7615 bugfix needs to be made public as soon as possible 

Activities

dregad

dregad

2017-04-08 10:11

developer   ~0056441

On 8 April 2017 at 00:32, @atrol wrote:

This is really a very bad one.

Independent from the fix itself, what's the best practice to publish the information after the fix is available?

Of course, we should not publish how this security issue can be used to hijack accounts.

On 8 April 2017 at 02:24, @vboctor replied:

That is terrible. Sometimes I hate PHP for these things!.

I’m not familiar with best practices in terms of disclosure for such easily exploitable issues. Out of all the security fixes we had, this is likely the worst.

I wonder if we can make the fix not obvious. For example, have a change that would include username and user id in verification links to reduce chances of brute force, and as part of that change != and !==. It will also make security better in general.

Then maybe after we have pushed out the release we can disclose. I also wonder if we may can go with the option of never disclosing. Damien has probably researched the security disclosure process more than me, so let’s see what he recommends here.

In the meantime, I have patched mantisbt.org/bugs/

dregad

dregad

2017-04-08 10:12

developer   ~0056442

Last edited: 2017-04-08 10:13

I confirm that the vulnerability has been introduced in 1.3.0-rc.2, commit MantisBT master ac8939db - sorry @cproensa, it seems it's you again ;-)

atrol

atrol

2017-04-08 10:15

developer   ~0056443

@dregad, you set target version to 2.3.1, shouldn't it be 1.3.10?

dregad

dregad

2017-04-08 10:31

developer   ~0056444

Out of all the security fixes we had, this is likely the worst.

I agree, this one's really bad.

I wonder if we can make the fix not obvious
I also wonder if we may can go with the option of never disclosing.

I really don't see the point in hiding the fact that we have a security problem. What we must do is patch it (which is easily done), and disclose it responsibly, i.e. making sure the fix / new releases are available before we go public about it.

Considering the severity of this issue, I would suggest e-mailing our users to personally inform them about it, and instruct them to upgrade or patch their system immediately. I guess that could be done with the release announcement to the mailing list.

include username and user id in verification links

I'm not convinced this would be so useful; in fact it may cause verification errors if users mistype their real name in verify.php ?

cproensa

cproensa

2017-04-08 12:17

developer   ~0056446

damn.
The changes at ac8939db are subtle, i can see why we didn't notice it.

dregad

dregad

2017-04-10 10:22

developer   ~0056476

Last edited: 2017-04-10 10:24

Proposed patch for review (Note, this is against master branch, so it applies to 2.0.0-beta.3 and later)

0001-Verify-account-only-if-a-request-is-in-progress.patch (913 bytes)   
From afeaeb4a4bc25b08e1cb986a99464bfe73a0e16f Mon Sep 17 00:00:00 2001
From: Damien Regad <dregad@mantisbt.org>
Date: Mon, 10 Apr 2017 14:17:14 +0200
Subject: [PATCH] Verify account only if a request is in progress

The account verification page should only proceed and allow updating the
user's profile (including resetting their password) when there is an
active activation token.
---
 verify.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/verify.php b/verify.php
index 6c17059..abd0328 100644
--- a/verify.php
+++ b/verify.php
@@ -69,7 +69,7 @@ if( auth_is_user_authenticated() ) {
 
 $t_token_confirm_hash = token_get_value( TOKEN_ACCOUNT_ACTIVATION, $f_user_id );
 
-if( $f_confirm_hash != $t_token_confirm_hash ) {
+if( $t_token_confirm_hash == null || $f_confirm_hash != $t_token_confirm_hash ) {
 	trigger_error( ERROR_LOST_PASSWORD_CONFIRM_HASH_INVALID, ERROR );
 }
 
-- 
1.9.1

hyp3rlinx

hyp3rlinx

2017-04-12 13:01

reporter   ~0056512

Tested and patch looks good to go... when is "pre announcement" and have you notified anyone yet? my policy is disclose upon fixed.

hyp3rlinx

hyp3rlinx

2017-04-13 14:42

reporter   ~0056535

FYI, I will plan on disclosure April 17 ...

dregad

dregad

2017-04-13 18:11

developer   ~0056536

has anyone emailed any known users yet

Not to my knowledge.

plan on disclosure April 17

Ideally your disclosure should happen around the same time (or after) we cut the releases including the fix.

Note that this is Easter week-end, and many European businesses are closed for the holiday so it may not be the best timing for this. I personally won't be available on the 17th due to a family event. I would suggest to delay at least until 18th, especially if there is any action required on my part.

In any case, I'd like to hear from @vboctor before committing on a date, as he's the only one who can take care of the required activities (e-mailing users, i.e. the so-called "pre-announcement", and publishing the new releases).

It would be nice also if you could give some details about your disclosure process (communication channels, timing...)

atrol

atrol

2017-04-14 04:34

developer   ~0056545

Just to be sure
$f_confirm_hash !== $t_token_confirm_hash means
value of $f_confirm_hash != value of $t_token_confirm_hash or
type of $f_confirm_hash != type of $t_token_confirm_hash

If so, I prefer this one

if( $t_token_confirm_hash == null || $f_confirm_hash !== $t_token_confirm_hash ) {
hyp3rlinx

hyp3rlinx

2017-04-14 08:55

reporter   ~0056549

@dregad agree with your disclose outline, yes will post to sites / mailing lists. Reminder April 20th I am disclosing.

hyp3rlinx

hyp3rlinx

2017-04-14 10:00

reporter   ~0056550

FYI, in my own advisory I will be using term "Pre-Auth Remote Password Reset" as it is clear on impact and the severity, letting you know so we are on the same page.

atrol

atrol

2017-04-15 04:12

developer   ~0056556

Last edited: 2017-04-15 04:13

Seems there is no other plan as @hyp3rlinx will disclose on Thursday 4/20.

I preferred ~0056546

Friday 4/21: send the pre-announcement
Tuesday 4/25: publish releases

hyp3rlinx

hyp3rlinx

2017-04-15 13:09

reporter   ~0056568

@atrol I know the timing is bad, but its also really bad to have this vulnerability out there for extended period of time don't you think?

atrol

atrol

2017-04-15 14:53

developer   ~0056569

its also really bad to have this vulnerability out there for extended period of time don't you think?

Of course, it is.

The vulnerability is out since about 10 months, so I am not sure if it would be that bad to have it for some more days.
IIRC there was no user on IRC, Gitter, forum, mailing lists or our bug tracker telling about hijacked user accounts.
So it seems that not that much - if any, fingers crossed - installations are affected until now.
I expect to see some hijacked installations after our pre-announcement and a lot more after the disclosure.

We will reach n percent of our users with the pre-announcement on 21st.
I hope to reach n+x percent of our users using the roadmap from 0022690:0056556 and to see less hijacked installations.
This is certainly just theory, some kind of gambling and completely wrong if someone starts hijacking today.

hyp3rlinx

hyp3rlinx

2017-04-15 18:45

reporter   ~0056571

according to sourceforge activity 1.3.0 (beta) has been out since two years ago, anyway, you been really lucky. Luck runs out and I don't like to gamble. Your statement to me says it all "if someone starts hijacking today" My goal is not to push the "pre-announcement" and disclosure but I feel waiting you risk losing it ALL vs losing some, and to make it worse your sitting on a fix. If were my application I would do it immediately upon receiving and fixing the issue. Your call... let me know.

dregad

dregad

2017-04-16 12:56

developer   ~0056582

@hyp3rlinx as I feared, the cat is now out of the bag http://www.openwall.com/lists/oss-security/2017/04/16/2, so I guess there is no point in further delaying your own announcement.

Related Changesets

MantisBT: master-2.3 cfbc5e54

2017-04-10 04:17

dregad


Details Diff
Verify account only if a request is in progress

The account verification page should only proceed and allow updating the
user's profile (including resetting their password) when there is an
active activation token.

Fixes 0022690
Affected Issues
0022690
mod - verify.php Diff File

MantisBT: master-2.2 46880ef6

2017-04-10 04:17

dregad


Details Diff
Verify account only if a request is in progress

The account verification page should only proceed and allow updating the
user's profile (including resetting their password) when there is an
active activation token.

Fixes 0022690

Backported from cfbc5e54af6c2e9fc9ca7b72fa7b31aa284625f1
Affected Issues
0022690
mod - verify.php Diff File

MantisBT: master-1.3.x 14c61a8c

2017-04-10 04:17

dregad


Details Diff
Verify account only if a request is in progress

The account verification page should only proceed and allow updating the
user's profile (including resetting their password) when there is an
active activation token.

Fixes 0022690

Backported from cfbc5e54af6c2e9fc9ca7b72fa7b31aa284625f1
Affected Issues
0022690
mod - verify.php Diff File