1313052 - Host Header Injection - location.services.mozilla.com

Status: RESOLVED FIXED

(Cloud Services :: Server: Location, defect)

Description

[guilhermescombatti]

An attacker can manipulate the Host header as seen by the web application and cause the application to behave in unexpected ways.

Very often multiple websites are hosted on the same IP address. This is where the Host Header comes in. This header specifies which website should process the HTTP request. The web server uses the value of this header to dispatch the request to the specified website. Each website hosted on the same IP address is called a virtual host.

But what happens if we specify an invalid Host Header? If Apache receives an unrecognized Host Header, it passes it to the first virtual host defined in httpd.conf. Therefore, it's possible to send requests with arbitrary Host Headers to the first virtual host.

Another way to pass arbitrary Host headers is to use the X-Forwarded-Host Header. In some configurations this header will rewrite the value of the Host header. Therefore it's possible to make a request like:

Request:
GET http://location.services.mozilla.com HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.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
Connection: keep-alive

Response:
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Wed, 26 Oct 2016 12:51:09 GMT
Location: https://google.com/
Server: nginx/1.6.0
Content-Length: 184
Connection: keep-alive


Normally, most apps will reject any request that doesn't originate from the same origin . To fix, the application should reject anything that doesn't match the target domain. This may also be an error in the rewrite functions of the back-end web server as well.


Regards,

Guilherme

Comment 1

[guilhermescombatti]

Attachment: Capture1233123.JPG

Comment 2

[Simon Bennetts [:psiinon]]

Do you have an actual attack that causes any problems for either the service or the users?
The way its documented it looks like that if you specify an alternative host then you get a 301, which isnt going to cause any real problems is it?

Comment 3

[Simon Bennetts [:psiinon]]

For info - a curl script to demonstrate this issue:
curl -H "Host: www.google.com" -i "http://location.services.mozilla.com/"

Note that if the request is made to the https URL then https://location.services.mozilla.com/ is returned rather than the 301:

curl -H "Host: www.google.com" -i "https://location.services.mozilla.com/"

So its looking like this is an nginx config problem

Comment 4

[Jeff Bryner [:jeff] (use NEEDINFO 😉)]

ckolos have you had a chance to take a look at this?

Comment 5

[Daniel Veditz [:dveditz]]

The severity of this bug doesn't not qualify for the bug bounty.

Comment 6

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

(In reply to Jeff Bryner [:jeff]  (use NEEDINFO) from comment #4)
> ckolos have you had a chance to take a look at this?

missed it in queue. On it now.

Comment 7

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

This should now be fixed.