1133442 - Host Header Injection - Open Redirect & Cache Poisioning in pfs.mozilla.org

Status: RESOLVED FIXED

(Websites :: plugins.mozilla.org, defect)

Description

[nitingoplani88]

Attachment: Screenshots.docx

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

1- Access the URL pfs.mozilla.org
2- Intercept the request
3- Change the host header to google.com
4- Observe the 302 redirect response
5- Application redirected to google.com
6- Now access the application pfs.mozilla.org again
7- This time you will observed application automatically gets redirected to google.com


Actual results:

Its redirecting to google everytime whenever a user tries to open the site pfs.mozilla.org


Expected results:

Ideally it should not redirect to google.

Comment 1

[:Gijs (he/him)]

Georg, who's responsible for the server-side infra here?

Comment 2

[Georg Fritzsche [:gfritzsche]]

Good question - Benjamin or Schalk might know?

Comment 3

[Schalk Neethling [:espressive]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #2)
> Good question - Benjamin or Schalk might know?

I have absolutely no idea. I thought pfs was retired :/ I am responsible for the front end part of mozilla.org/plugincheck and to some extent the back-end at plugins.mozilla.org but unfortunately cannot offer any advise in terms of pfs.m.o

Comment 4

[:Gijs (he/him)]

(In reply to Schalk Neethling [:espressive] from comment #3)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #2)
> > Good question - Benjamin or Schalk might know?
> 
> I have absolutely no idea. I thought pfs was retired :/

Ditto. If the server is effectively doing open proxy stuff, can we just shut it down? :-\

Benjamin?

Comment 5

[Georg Fritzsche [:gfritzsche]]

(In reply to Schalk Neethling [:espressive] from comment #3)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #2)
> > Good question - Benjamin or Schalk might know?
> 
> I have absolutely no idea. I thought pfs was retired :/

Bug 836415 killed it on 35.
ESR is still on 31 now.

Comment 6

[Benjamin Smedberg]

wclouser is the closest person I know; this is part of the AMO codebase, though run on a separate server IIRC. I'd like to keep PFS running until we retire ESR31, unless that's horribly expensive.

Comment 7

[nitingoplani88]

Hi,

Let me know if it is a valid issue and you are able to reproduce this issue? 

Thanks,
Nitin

Comment 8

[nitingoplani88]

Hi All,

Could you please let me know if you think its a valid issue?

Thanks,
Nitin

Comment 9

[nitingoplani88]

I am waiting for the update since long time. Could anyone please update?

Comment 10

[Wil Clouser [:clouserw]]

Sorry for missing this.  I think it's a server configuration issue.  I'll needinfo jason.  See below for some curl test cases (note the Location responses):

clouserw@sunshine:~$ curl -i http://www.mozilla.org -H 'Host: www.google.com'
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Wed, 25 Mar 2015 17:24:25 GMT
Location: https://www.mozilla.org/
Connection: Keep-Alive
Content-Length: 0

clouserw@sunshine:~$ curl -i http://pfs.mozilla.org -H 'Host: www.google.com'
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Wed, 25 Mar 2015 17:24:34 GMT
Location: https://www.google.com/
Connection: Keep-Alive
Content-Length: 0

Comment 11

[nitingoplani88]

Hi,

You are right, from the response we can say that the host header is not being validating and redirecting to injected domain. We can validate this by using whitelist.

Below are the few reference links:
http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html
http://carlos.bueno.org/2008/06/host-header-injection.html
http://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/

Comment 12

[Jason Thomas [:jason]]

This was a issue in our https-redirect Zeus traffic script we were using only for pfs.mozilla.org. This is now fixed:

λ master ~ → curl -i http://pfs.mozilla.org -H 'Host: www.google.com'
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Wed, 25 Mar 2015 17:48:59 GMT
Location: https://pfs.mozilla.org/
Connection: Keep-Alive
Content-Length: 0

Comment 13

[nitingoplani88]

Perfect, is this eligible for bounty?

Comment 14

[Wil Clouser [:clouserw]]

I nominated it with the security team.  I expect they'll triage it soon.

Comment 15

[Daniel Veditz [:dveditz]]

Since this is/was a back-end service and not a website people would browse, whether or not it's eligible for a bounty depends on how would you use this to attack a Firefox user. Somehow you have to get the user's browser to make a PFS request and inject a Host: header. The browser only uses TLS connections to PFS so a network MITM is unlikely. You could try a cross-site XHR request, but you can't set the Host: header (http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method).

If you did, however, manage to poison the cache we might accept plugin installation data returned from the incorrect host, which could be pretty bad for the older (but still supported) ESR-31 versions.

Comment 16

[nitingoplani88]

Let me know your decision on this?
 No doubt this is an issue and also mentioned under the scope. The only difficulty is the execution. So it decreases the severity rating because of the complexity involved.

Comment 17

[Daniel Veditz [:dveditz]]

There's more than the question of complexity, it's can you do it at all in a way that affects a Firefox user (by poisoning the cache)? Just an open redirect on the web is not a bug that would earn a bounty. If you can affect a Firefox user's use of the plugin finder service then we care very much.

Comment 18

[nitingoplani88]

Am not sure where exactly this pfs service is being used and thats why the complexity is high but it does not mean that it cant be exploited.
Also Low severity bugs have nominal bounty too.

Comment 19

[Al Billings [:abillings - ex-MoCo]]

Actually, we don't pay on low security security rated issues. I'll leave the determination to Dan Veditz.

Comment 20

[Daniel Veditz [:dveditz]]

So far we have a bug but you haven't demonstrated a vulnerability. All the content on pfs is served over TLS and in order to trigger this bug you have to MITM the traffic. If you can MITM the TLS traffic you can do cache poisoning and worse without needing this bug at all.

Comment 21

[Daniel Veditz [:dveditz]]

Not exploitable in practice against Firefox users, does not qualify for a bug bounty.