长城宽带使用下三滥手段劫持可执行文件下载地址,然后引导到其他站点,这个操作用心不良啊,这可以夹带恶意文件啊。    

   

wKiom1i6MkaDgF4rAAMpQfncfqI028.png-wh_50

 

看看这个220.112.194.135这个ip地址归属,http://www.ip.cn/index.php?ip=220.112.194.135

如果上面大图看不清,请继续阅读下面关于http://www.bing.com/test.zip 的例子        

后续,后面投诉到长宽的客服,联系了多人处理了一下(仅仅把我反馈的www.7-zip.org 处理了下,怎么处理的呢,就是加了下缓存),忽悠吧,后面接着投诉。

   

证据:

yoke@yoke:/etc$ curl -v http://www.7-zip.org/a/7z1604.exe
*   Trying 178.62.49.34...
* Connected to www.7-zip.org (178.62.49.34) port 80 (#0)
> GET /a/7z1604.exe HTTP/1.1
> Host: www.7-zip.org
> User-Agent: curl/7.50.1
> Accept: */*
>  < HTTP/1.1 302 Found
< Connection: close
< Location: http://211.162.127.22/files/61760000031424D9/www.7-zip.org/a/7z1604.exe
<  * Closing connection 0


好吧,似乎location的地址不一样了,这个7-zip 的是可以下载了,但是劫持还在,为什么说是劫持呢?下面证据可以看下,我伪造一个不存在的地址(正常情况应该是返回404 不存在,如果你是用缓存或者代理服务器,那也是应该返回404的), curl –v  http://www.bing.com/test.zip

[yoke@host:/]#curl -v http://www.bing.com/test.zip

 > GET /test.zip HTTP/1.1 

  > User-Agent: curl/7.38.0 

 > Host: www.bing.com 

 > Accept: */* 

> 
< HTTP/1.1 302 Found 
< Content-Length: 0 

< Cache-Control: no-cache 

< Connection: close 
< Location: http://211.162.74.233:9011/www.bing.com/c3pr90ntc0td/test.zip

而如果用浏览器访问则显示:

image

 

使用wireshark 抓包的情况:

  1. 488 编号的包,是我发送http://www.bing.com/test.zip 的请求包

  2. 489 返回了302 Found,给的包内容是location:http://211.162.74.233:9011/www.bing.com/c3pr90ntc0td/test.zip

  3. 490由于发现302,我方回包给bing FIN,ACK关闭连接。

  4. 497对方对FIN,ACK 的包进行响应,发回ACK。

  5. 498 我方ACK对方的ACK。

  6. 500 这个包很特别,是晚到的真的bing的返回包,但是由于前面的原因(3-5步骤里),这个包认为是重传的包,已经被应用忽略了,虽然协议显示tcp,实际这个包并没有解码http,解码http后的信息是下面

  HTTP/1.1 301 Moved Permanently 
    Location: http://cn.bing.com/test.zip
    Server: Microsoft-IIS/8.5 

    X-MSEdge-Ref: Ref A: 5BD13BD03E4A4A62AAB34684A24288F0 Ref B: BJ1SCHEDGE0116 Ref C: Fri Mar 10 23:27:26 2017 PST 

    Date: Sat, 11 Mar 2017 07:27:26 GMT 

    Content-Length: 0

image

 

结论:

  1. 长城宽带的劫持是http的劫持,而且是针对特定Url模式的,比如后缀是zip,rar,exe,apk,mp3等,有些国内的大站用的似乎是缓存或代理,而不是劫持。

  2. 劫持后看location的地址,应该是nginx 的反向代理加了缓存,只不过似乎劫持和反向代理没有配合好,也或者是反向代理技术比较烂,站点本来该缓存在ngnix 上的,但是nginx没有缓存(也没有做反向配置),所以丢到http://220.112.194.135:9011/www.jsfund.cn/c3pr90ntc0td/cert.zip 类似这样的地址,不会有内容返回)。

  3. 测试自己是否被劫持很简单,不用抓包了,只需使用curl -v http://www.bing.com/test.zip (这是个伪造的地址,如果你发现响应的是302,而不是404或者301,都是劫持,劫持一般通过重写location 也或者返回一段js让你跳转) ,我的dns解析没有问题,虽然也可能存在DNS劫持(DNS默认是UDP协议,也可走TCP,但是如果不加密都是可以劫持的)这里是http劫持(你是否注意到我抓包的界面的dns解析的ip 是正确的,因为我直接查的国外的dns),那么ip没有问题,而且我的包也是发往正确的ip的,只是响应内容被替换了。



防范手法:


OK,既然知道了整个过程和劫持的手段,遇到这种情况我们只能认宰了么?有没有更好的办法可以处理劫持。上面抓包的解释充分说明,长宽的http劫持只是在目标网站返回前,丢你一个假的302的包,它也懒得去丢个rst 给目标网站,所以目标网站仍然发包给你,不过你会忽略掉而已了。

 

那么我们只需要识别出这个假的302的包然后丢弃就可以了嘛,那么什么工具可以做这个,显然是防火墙的功能,而且是能写包匹配规则和对包能操作的工具,linux上的iptables 正好做这个事情,IPtables含有一个string module 可以匹配包中的字符串,由于长宽丢回的302包中都有这个:9011/ 的关键字,而且这个302 Found用的很是典型,所以我用多个过滤条件进行过滤。  

iptables -N check_for_9011
  iptables -I INPUT -p tcp -m tcp --sport 80 --tcp-flags FIN,SYN,RST,PSH,ACK,URG PSH,ACK -m string --string  "302 Found" --algo bm --from 45 --to 80 -j check_for_9011

  iptables -I check_for_9011 -m string --string ":9011/" --algo bm --from 70 –to 180  -j DROP

 

以上iptables 规则检查源端口为80,且tcp-flags 为PSH,ACK的包,如果返回包中包含:”302 Found”,然后丢给check_for_9011 chain ,这个chain 会有另外一个规则额外处理,会匹配是否含有":9011/"的字样,如果发现丢弃该包。

注意:上面我使用了iptables 的string 扩展和tcp扩展,我使用tcp-flags 来匹配PSH,ACK标志位的包,string 扩展从包的第45字节到80 字节之间进行寻找”302 Found” ,如果找到跳到check_for_9011 用户表,然后check_for_9011表中有规则匹配是否含有“:9011/” ,我用了offset from70到180来防止过多匹配。这个offset 你可以使用wireshark来辅助,比如上面wireshark 截图中的最下面的左边为十六进制,右边为ASCII解码的界面里,最左边有个0010,0020,0030这些行,每行16个字节,这样你可以计算大概的offset了(TCP头的大概差不多40个字节左右)。

 

注意iptables 的规则从上自下执行,如果前面有规则,比如对包状态ctstate RELATED,ESTABLISHED的数据包放行的规则存在的话,你需要调整上面的iptables 为靠上(我上面的Iptables 命令用了-I,会把规则插入到最前面)

 

加了iptables 后的效果:

yoke@yoke:/etc/iptables$ curl -v http://www.bing.com/test.zip
*   Trying 202.89.233.104...
* Connected to www.bing.com (202.89.233.104) port 80 (#0)
> GET /test.zip HTTP/1.1
> Host: www.bing.com
> User-Agent: curl/7.50.1
> Accept: */*
>  < HTTP/1.1 301 Moved Permanently
< Location: http://cn.bing.com/test.zip
< Server: Microsoft-IIS/8.5
< X-MSEdge-Ref: Ref A: 6150F693AAC74237AE03DBDAE30A17B6 Ref B: BJ1EDGE0216 Ref C: Tue Mar  7 06:47:07 2017 PST
< Date: Tue, 07 Mar 2017 14:47:06 GMT
< Content-Length: 0
<  * Connection #0 to host www.bing.com left intact

 

这样才是正常不被劫持的状态,如果劫持存在,就返回302了。


宽带路由器上拦截的方法:


如果你的路由器使用openwrt 等linux系统,上面iptables 规则应用到路由器上非常简单。只需要把命令改为下面(和上面规则相比,宽带路由上只把INPUT表换成了FORWARD表

下面命令输入到openwrt --->网络设置—>防火墙—>自定义规则中,然后重启防火墙。

iptables -N check_for_9011 
iptables -I FORWARD -p tcp -m tcp --sport 80 --tcp-flags FIN,SYN,RST,PSH,ACK,URG PSH,ACK -m string --string  "302 Found" --algo bm --from 45 --to 80 -j check_for_9011 
iptables -I check_for_9011 -m string --string ":9011/" --algo bm --from 70 –to 180  -j DROP

 

image

 

如果你喜欢命令行,请ssh 你的宽带路由(假设是openwrt系统),请修改/etc/firewall.user 增加上面内容,这样路由重启后依然会应用这些策略。

 

那么规则放了,如何看规则有没有生效呢?

1. 客户端使用curl 或者浏览器访问,测试目前url

2. 防火墙上使用iptables –L INPUT –xv && iptables –L FORWARD –xv && iptables –L check_for_9011 –xv 看状态

3. 如果openwrt 网页版,可用状态—>防火墙里面来看,比如下图:

image