Closed Bug 726247 Opened 13 years ago Closed 13 years ago

Possible MiTM with releases.mozilla.org in China

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: luweitest, Unassigned)

References

()

Details

Download files from releases.mozilla.org. The pages displayed as normal, download success as normal, but in fact the connection is not with Mozilla's server. A sample log (releases.mozilla.org is resoved to 218.6.25.199 at the time, but it's changing): GET /pub/mozilla.org/thunderbird/releases/10.0-real/win32/en-US/Thunderbird%20Setup%2010.0.exe HTTP/1.1 Host: releases.mozilla.org User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en Accept-Encoding: gzip, deflate Referer: http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/10.0-real/win32/en-US/ Cookie: WT_FPC=id=2bb0cb0e84cc108c6511274053975974:lv=1328562797045:ss=1328562796719; dloadday=65.49.68.155.1325471858384717; wtspl=219427DNT: 1 Connection: keep-alive HTTP/1.1 200 OK X-Backend-Server: cn-web01 Last-Modified: Mon, 30 Jan 2012 01:43:57 GMT Accept-Ranges: bytes Content-Length: 16811832 Content-Type: application/octet-stream Date: Fri, 10 Feb 2012 05:11:29 GMT Server: Apache Powered-By-ChinaCache: MISS from CHN-WZ-V-3CA Powered-By-ChinaCache: HIT from CHN-PT-2-336 Connection: close MZ......................@...............................................!..L.!This program cannot be run in DOS mode. $........H...)u..)u..)u...~..)u.75{..)u......)u...q..)u..)t. )u.w&(..)u...~..)u.s/s..)u.Rich.)u.........PE..L...fJ.D..... ...
Assignee: nobody → server-ops
Component: General → Server Operations
Product: Mozilla Services → mozilla.org
QA Contact: general → cshields
Version: unspecified → other
This attack is raised in TB support group: http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/a960a10ec01f1272/2d973d9ebe4e2f33 All chinese users and maybe other areas which under GFW's influence are affected. releases.mozilla.org is affected. Other release channels not checked, but may be attacked as well. The fix, I think, is to enable HTTPS by default on all release channels.
(In reply to LU Wei from comment #1) > The fix, I think, is to enable HTTPS by default on all release channels. And, to prevent GFW from even hijacking HTTPS, I think Bug 542689 should be re-opened too.
Group: websites-security
LU, Can you run an md5sum on the downloaded binary? cn-web01 is a webserver in a Mozilla datacenter in China. I'm not a 100% sure, but I think in order to comply with local governmental regulations, we're supposed to send traffic from China to China for downloading firefox. We use ChinaCache as a CDN to help with the traffic. Also, releases.mozilla.org is a "pool" of servers, not a single machine. I don't think there is any cause for concern here at this point.
Group: websites-security
Below is the result of a DNS lookup from a RoadRunner connection in the U.S. (Los Angeles area). You will note that the IP address cited in the description -- 218.6.25.199 -- does not appear in this list. 218.6.25.199 is the IP address of 199.25.6.218.broad.pt.fj.dynamic.163data.com.cn. That IP address is owned by China Telecom. The domain 163data.com.cn is listed by the CNNIC WhoIs server as "inactive". NSLookUp - Friday, February 10, 2012 22:09:38 Query: releases.mozilla.org Type of Search: Use Winsock Function GetHostByX Protocol: UDP Verbose: Yes Recursion Desired: Yes Hostname: releases.geo.mozilla.com IP Address: 128.61.111.9 IP Address: 64.50.236.214 IP Address: 131.188.12.212 IP Address: 216.165.129.141 IP Address: 149.20.36.135 IP Address: 202.177.202.154 IP Address: 129.101.198.59 IP Address: 204.246.0.136 IP Address: 155.98.64.83 IP Address: 156.56.247.196 IP Address: 204.152.184.113 Alias: releases.mozilla.org
David, That is correct. We still don't know how LU got that IP (that information isn't on this bug). It is quite likely there is an issue on his end vs all of our users in China (which is what this bug claims). Also, the resulting backend he's hitting (even after getting that IP) *seems* to be Mozilla owned, based on the headers he pasted.
Summary: Mozilla under middle-man attack - please enable SSL on releases channel → Possible MiTM with releases.mozilla.org in China
releases.mozilla.org is a cname to releases.geo.mozilla.com. The nameserver which resolves *.geo.mozilla.com will look at your source IP and give you different results depending on where in the world you're doing the lookup from, by looking up your source IP in a database that maps IP addresses to a location. The answer you get in the US will be different than the answer you get in China. In China the correct result is a CNAME to releases.mozilla.chinacache.net, which is a CDN that we purchase bandwidth from to help distribute the files in China. ChinaCache uses releases.cn.mozilla.com as its origin server, which is a load balancer in our data center in Beijing. cn-web01, as listed in the headers of the above response, is one of the back-end servers behind that load balancer.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
And ChinaCache does lease IP space from ChinaNet (which is who the above-listed IP address belongs to) as well as about 4 other ISPs in China.
(In reply to Shyam Mani [:fox2mike] from comment #3) > I'm not a 100% sure, but I think in order to > comply with local governmental regulations, we're supposed to send traffic > from China to China for downloading firefox. It wasn't anything to do with regulations but more for performance because getting traffic in and out of China is really slow. If we host it in China people can actually download at a decent speed, and since we happened to have a data center there anyway...
FWIW, if you would like to use https to download Firefox or Thunderbird, you can use https://ftp.mozilla.org/pub/mozilla.org/
Thanks for all of you explained to me. Seems I am over panic under GFW. I have the habit to check file's signatures (if it has), and I have not encountered any fake files until now. The IP addresses I got is from Wireshark's log, besides 218.6.25.199 above, 113.107.107.176 and 59.57.12.141 have been recorded too. It is reasonable that they are all cache servers for load balance. Anyway, for an old user who knows signature checking, downloading from non-official place does not form any threat. It is user's responsibility to learn about security if he concerns about it.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.