gljr999 2008-11-12 19:17
网通-------VeryCD域名被劫持事件
自11月5日晚起,有网通ADSL业务客户发现,当他们登录VeryCD、BTChina等 P2P网站时,网页内容会被篡改为跳转到百度首页的一段代码,同样遭遇的还有Emule、BTChina以及部分国外的P2P网站.随后,VeryCD在 网站上发布公告称遭到北京网通劫持.昨天,网通发布消息称与此事无关.下午2点左右,网友反映P2P网站已恢复正常登录.
VeryCD称遭劫持
家住崇文区的王先生是一个老网民.11月5日晚,王先生打开VeryCD准备看看有什么好东西可供下载,但他发现在IE地址栏中输入网址后,却直接跳转到了百度首页的页面.“我还以为VeryCD服务器出了问题.”王先生说,与此同时,BTChina、Emule等P2P网站也出现了同样的跳转情况,无法打开.
6日晚7点多,网友们发现P2P网站VeryCD在其首页显著位置发表公告,称遭到网通劫持.公告中称,自11月5日起,部分北京网通(联通)用户无法访问VeryCD、Emule、BTChina以及部分国外P2P网站,页面内容遭到篡改,自动跳转到百度首页的一段代码,这与受影响网站的服务器及DNS无关,是网通线路的某一层路由,人为地对特定域名的内容进行了劫持,并篡改为了自己的代码.
同时,VeryCD也在公告中表示,正在采取更换临时地址等方式进行补救.6日晚11点,VeryCD先后更改了两个临时域名beta.VeryCD.com和secure.VeryCD.com,但临时措施大多数人并不知道.
网民疑运营商封杀P2P
在公告发布后,仅一天左右的时间,网友留言就超过207条.有网友将矛头直指网通,一名网友在VeryCD公告后发帖称,“很多网站,都曾经被劫持到运营商的搜索网站去.这是一个阴谋,运营商利用手里的路由资源,侵占很多中小网站站长的重要虚拟财产——流量.”
而与此同时,众多网友开始向网通的客服反映此问题,但得到的答复均为技术原因,稍后可以得到恢复.但此说法遭到网友质疑.“为什么别的网站没问题,独独拥有P2P资源的网站会这样.”一名网友说.
在一家知名门户网站关于此事的网络投票中,截至昨天下午1点,已有3600多名网友投票,其中93%以上的网友认为,“VeryCD等P2P网站域名遭跳转”的原因为运营商意欲封杀P2P.
网通称与此事无关
昨天上午,记者致电网通10060客服进行询问,网通客服人员表示由于“线路故障”,目前工程人员已在修复中.随后,北京网通发布消息称,经了解不只网通宽带用户出现该类现象,北京网通从未做过导致该现象的任何行为.“互联网是开放的网络,出现该现象的原因较多,用户中木马或网站受到攻击等情况均可能导致此现象.”网通表示,公司将继续密切关注此事,并希望该类P2P网站能客观正确反映情况.
中华全国律师协会信息网络与高新技术专业委员会研讨员郭秀华律师说,在互联网时代,域名是专属性的识别标志,与商标、商号一样具有某种特定的财产属性.“域名的权利人拥有对该域名的实际管理所有权,权利人可以起诉劫持单位.”郭秀华说,但如果劫持单位是非人为的技术故障,那么该单位也不构成侵犯域名.即使是人为劫持,也要分为两种情况:第一,劫持是为了禁止侵权传播,那么该行为是合法的,第二,如果劫持是为了谋取自身利益,则属于侵犯域名行为.郭秀华说,由于目前并未有专门法律出台,所以此类情况还难以界定.
昨天下午2点左右,VeryCD发布更新显示,网友反映已能通过该网站原域名进行直接访问.
-----------------------------------------
被劫持的分析和解决方案
话说VeryCD等网站被劫持的第二天，劫持还在继续。我闲着无聊在QQ群里胡扯，被Dash和xdanger逮到。正好我非常荣幸的是北京网通用户，这个伟大的任务就只能交给我了。
先用正常方式访问一下VeryCD，得到下面的结果
Sam@Bogon:~$ curl -v -H [url]www.verycd.com[/url] * About to connect() to x.x.x.x port 80 (#0) * Trying x.x.x.x... connected * Connected to x.x.x.x (x.x.x.x) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: [url]www.verycd.com[/url] > < HTTP/1.1 200 OK < Content-Type: text/html;charset=gb2312 < Content-Length:182 < <html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html> * Connection #0 to host x.x.x.x left intact * Closing connection #0 Sam@Bogon:~$
可以发现返回的结果直接被劫持并替换。并不像一般的挂马等行为是在网页内容的最前或者最后部分插入劫持代码。
之后直接输入VeryCD的IP，返回的结果是VeryCD的squid服务器默认页面，说明IP并没有成为劫持的判断标准。应该是VeryCD的域名或者网页中某个特征导致劫持设备对内容进行替换。（此处省略结果）
既然域名是判断的标准之一，那么就可以尝试替换HTTP协议中Host的办法来测试
(1) Sam@Bogon:~$ curl -v -H 'Host: [url]www.veryc.com[/url]' [url]www.verycd.com[/url] * About to connect() to [url]www.verycd.com[/url] port 80 (#0) * Trying x.x.x.x... connected * Connected to [url]www.verycd.com[/url] (x.x.x.x) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: [url]www.veryc.com[/url] > < HTTP/1.1 200 OK (略) (2) Sam@Bogon:~$ curl -v -H 'Host: verycd.com' [url]www.verycd.com[/url] * About to connect() to [url]www.verycd.com[/url] port 80 (#0) * Trying x.x.x.x... connected * Connected to [url]www.verycd.com[/url] (x.x.x.x) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: verycd.com > < HTTP/1.1 200 OK < Content-Type: text/html;charset=gb2312 < Content-Length:182 < <html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html> * Connection #0 to host [url]www.verycd.com[/url] left intact * Closing connection #0 Sam@Bogon:~$ (3) Sam@Bogon:~$ curl -v -H 'Host: [url]www.veryc.com[/url]' [url]www.verycd.com/verycd.com[/url] * About to connect() to [url]www.verycd.com[/url] port 80 (#0) * Trying x.x.x.x... connected * Connected to [url]www.verycd.com[/url] (x.x.x.x) port 80 (#0) > GET /verycd.com HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: [url]www.veryc.com[/url] > < HTTP/1.1 200 OK (略) (3) Sam@Bogon:~$ curl -v -H 'Host: w.verycd.com' [url]www.verycd.com[/url] * About to connect() to [url]www.verycd.com[/url] port 80 (#0) * Trying x.x.x.x... connected * Connected to [url]www.verycd.com[/url] (x.x.x.x) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: w.verycd.com > < HTTP/1.1 200 OK (略)
例子中，分别用了4种测试方法
1为发送一个主机头为[url]www.veryc.com[/url]的请求到verycd的服务器，可以看到数据正常返回，没有被劫持
2为发送了一个主机头为verycd.com的请求到verycd的服务器，可以看到数据被劫持了
3为发送了一个主机头为[url]www.veryc.com[/url]，使用GET方式获取/verycd.com文件的请求到verycd的服务器，可以看到数据正常返回，没有被劫持
4为发送一个主机头为w.verycd.com的请求到verycd的服务器，可以发现数据没有被劫持
通过上面的结论可以看出，用于劫持的设备只对域名的host部分做判断。
我们再来一个有趣的测试：如果把host发送到网通的bbn.com.cn去会怎样呢？
Sam@Bogon:~$ curl -v -H "Host: [url]www.vercd.com[/url]" [url]www.bbn.com.cn[/url] * About to connect() to [url]www.bbn.com.cn[/url] port 80 (#0) * Trying 202.106.195.131... connected * Connected to [url]www.bbn.com.cn[/url] (202.106.195.131) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: [url]www.vercd.com[/url] > < HTTP/1.1 200 OK < Date: Sat, 08 Nov 2008 13:33:06 GMT < Server: Apache/2.0.59 (Unix) DAV/2 < Last-Modified: Thu, 06 Nov 2008 07:21:36 GMT < ETag: "73c63-119c6-259cc000" < Accept-Ranges: bytes < Content-Length: 72134 < Content-Type: text/html < Set-Cookie: BIGipServerweb_pool=107325632.20480.0000; path=/ < <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> (略)
可以看到，什么事情都不会发生。这说明劫持设备应该是在北京网通出口上。
为了证实设备就在北京网通的出口上，我分别用北京不同线路的机器进行了测试，发现访问均一切正常。但某小ISP租用了网通的出口，出现了被劫持的情况。
为了再证实我的猜想，我在一台位于北京某不受影响的ISP的服务器上分别装了pptpd和rinetd，先测试使用VPN链接到此服务器pptpd，所有数据包通过此服务器发送，访问VeryCD.com，一切正常，数据没有被劫持。
然后再把本机的hosts指向此服务器，通过服务器的rinetd对数据包进行转发至VeryCD的服务器，发现数据包被劫持。
结论：加密后的数据不会被劫持。
我再到外部随便找了一台服务器，此服务器跟VeryCD无任何关系，也不位于同一物理位置，结果如下
Sam@Bogon:~$ curl -v -H 'Host: [url]www.verycd.com[/url]' server.outside * About to connect() to server.outside port 80 (#0) * Trying x.x.x.x... connected * Connected to server.outside (x.x.x.x) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: [url]www.verycd.com[/url] > < HTTP/1.1 200 OK < Content-Type: text/html;charset=gb2312 < Content-Length:182 < <html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html> * Connection #0 to host server.outside left intact * Closing connection #0
分析到了这一步，事情已经非常明朗了：
在北京网通的出口，被人有意或者无意放置了一套类似于Wall的设备用于劫持所有在列表内的P2P网站。我个人更加愿意相信这是网通在测试新设备。因为很明显，劫持后返回的数据使用了一个警告（warn）的标题，劫持者对于这些被劫持的网站的流量有一个很清晰的认识，并没有自己使用服务器来支撑这些流量（根据我掌握的数据，这些网站的流量，就算是静态的html文件也需要十几台服务器做支撑），而是不带任何用于分成或者统计的代码跳转到百度（百度用于统计和分成的代码是tn=xxxx）。（被劫持的第三天有部分流量被分到information.com，直接把information.com弄挂了）。
至于百度也是有苦难言。白白来了这么多无效流量，消耗资源不说，还要背上一个骂名。据我所知，出事后百度也在到处找方式接触受害网站了解情况。
====
解决方法：
根据上面的结论，这件事情的解决方法有下面几种：
1.更换域名，跟劫持者耗。对网站所有者来说低成本，但会造成大量用户不知道新域名而流失。但可以借助百度贴吧来解决。
2.使用BGP协议，更改北京网通用户到网站服务器之间的路由，跳过劫持设备。缺点是成本太高，BGP协议可以被网通人为忽略。
3.在劫持设备以内放置一台分流服务器，分流服务器使用VPN或者别的加密链路链接至主服务器进行数据交换。这样用户使用非加密链接链接至分流服务器，劫持设备无法进行劫持。
4.网站使用ssl，用户和网站之间数据均经过加密，劫持设备无法截取。
====
课外作业：
既然这套设备类似Wall，众所周知Wall是双向的，不知道这套设备怎样呢？带着这个疑问，我做了一个课外实验，让外省的朋友使用上面的测试方法访问我的机器
curl -vIH "Host: [url]www.verycd.com[/url]" [url]http://124.64.1xx.xx/[/url] * About to connect() to 124.64.1xx.xx port 80 (#0) * Trying 124.64.1xx.xx... connected * Connected to 124.64.1xx.xx (124.64.1xx.xx) port 80 (#0) > HEAD / HTTP/1.1 > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > Accept: */* > Host: [url]www.verycd.com[/url] > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Thu, 06 Nov 2008 15:28:27 GMT Date: Thu, 06 Nov 2008 15:28:27 GMT < Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l < Last-Modified: Mon, 24 Sep 2007 05:23:06 GMT Last-Modified: Mon, 24 Sep 2007 05:23:06 GMT < ETag: "29d84-17ef-43adad0ba6280" ETag: "29d84-17ef-43adad0ba6280" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 6127 Content-Length: 6127 < MS-Author-Via: DAV MS-Author-Via: DAV < Content-Type: text/html Content-Type: text/html
可以看到，这套设备真不咋地，不支持反向过滤。
====
又及：
在测试的过程中，我发现连续发送N个请求出去，总有几个漏网之鱼，能正确返回数据。这说明了啥？
1.设备是旁路的，失败的截取不会影响到正常的数据传输
2.设备要么是性能有缺陷，要么有防ddos的功能。我更加愿意相信前者。
3.不管设备是性能有缺陷还是能防ddos，我相信一点：在大量数据的攻击下，设备肯定会失去部分作用。
gongdianlong 2008-11-14 21:35
又可以上了，刚登陆了一下，是可以的，前几天也有同事说登陆补了VERYCD
在线客服(1)