Shulou(Shulou.com)06/01 Report--

Great Wall Broadband uses the next three indiscriminate means to hijack the download address of executable files, and then guide them to other sites. This operation is ill-intentioned and can contain malicious files.

Look at this 220.112.194.135. This ip address belongs to http://www.ip.cn/index.php?ip=220.112.194.135.

If you can't see the big picture above, please continue to read the following example of http://www.bing.com/test.zip

Follow-up, after the complaint to the long and wide customer service, contacted a number of people to deal with (only the www.7-zip.org of my feedback, how to deal with it, is to add the cache), hoodwink, followed by complaints.

Evidence:

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 而如果用浏览器访问则显示：

When using wireshark to grab packets:

The packet numbered 488 is the request packet that I sent http://www.bing.com/test.zip.

302 Found is returned, and the content of the package is location: http://211.162.74.233:9011/www.bing.com/c3pr90ntc0td/test.zip

490 due to the discovery of 302, we replied to bing FIN,ACK to close the connection.

The other party responds to the packet of FIN,ACK and sends it back to ACK.

We ACK each other's ACK.

500 this packet is very special, it is a late return packet of real bing, but due to the previous reasons (in step 3-5), this packet is considered to be a retransmitted packet and has been ignored by the application. Although the protocol shows that tcp, the actual packet does not decode http, the message after decoding http is as follows

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

Conclusion:

The hijacking of Great Wall Broadband is the hijacking of http and is aimed at specific Url modes, such as the suffix zip,rar,exe,apk,mp3, etc. Some large domestic stations seem to use caches or proxies rather than hijacking.

If you look at the address of location after hijacking, you can see that the reverse proxy of nginx has been cached, but it seems that hijacking and reverse proxy do not cooperate well, or the reverse proxy technology is relatively bad. The site should have been cached on ngnix, but nginx does not have cache (nor reverse configuration), so if you throw it to an address like http://220.112.194.135:9011/www.jsfund.cn/c3pr90ntc0td/cert.zip, there will be no content to return.

It's easy to test whether you've been hijacked. You don't have to grab the bag, just use curl-v http://www.bing.com/test.zip (this is a fake address. If you find that the response is 302 instead of 404 or 301, it's all hijacking. Hijacking usually allows you to jump by rewriting location or returning a js). My dns parsing is fine, although there may be DNS hijacking (DNS defaults to UDP protocol, or you can go TCP. But if you can hijack without encryption) here is http hijacking (did you notice that the ip parsed by dns in the interface I grabbed the package is correct, because I checked the foreign dns directly), then there is no problem with ip, and my package is also sent to the correct ip, but the response content has been replaced.

Precautions:

OK, now that we know the whole process and the means of hijacking, can we only admit it in such a situation? Is there a better way to deal with hijacking. The explanation of grabbing packets above fully shows that the http hijacking of length and width only throws you a fake 302 packet before the return of the target website, and it doesn't bother to throw a rst to the target website, so the target website still sends packets to you, but you will ignore it.

So we just need to identify the fake 302 packet and discard it. So what tool can do this? obviously, it is a firewall function, and it is a tool that can write packet matching rules and operate on the package. Iptables on linux does exactly this thing. IPtables contains a string module that can match the string in the package, because there is this keyword in 302 packets thrown back by length and width: 9011 /. And this 302 Found is very typical, so I use multiple filter conditions to filter.

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 "302Found"-- 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

The above iptables rule checks the packet whose source port is 80 and tcp-flags is PSH,ACK. If the return packet contains "302 Found" and then throws it to check_for_9011 chain, the chain will have another rule extra processing, which will match whether it contains the word ": 9011 /". If the packet is found to be discarded.

Note: above I used iptables's string extension and tcp extension, I used tcp-flags to match the PSH,ACK flag bit of the package, string extension from the package's 45 bytes to 80 bytes to find "302 Found", if found to jump to the check_for_9011 user table, and then the check_for_9011 table has rules to match whether it contains ": 9011 /", I used offset from70 to 180 to prevent too many matches. You can use wireshark to assist this offset. For example, the bottom left side of the wireshark screenshot above is hexadecimal, and the right side is ASCII decoding interface. On the far left, there is a 0010 line, 0020, and 0030, each line is 16 bytes, so you can calculate the approximate offset (about 40 bytes of the TCP header).

Note that the rules of iptables are executed from the top to the bottom. If there is a rule, such as the rule for releasing packets with packet status ctstate RELATED,ESTABLISHED, you need to adjust the iptables above to top (the Iptables command above me uses-I, which inserts the rule to the front)

The effect of adding 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 --->

Network Settings-> Firewall-> Custom rules, and then restart the firewall.

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 "302Found"-- 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

If you like the command line, please ssh your broadband routing (assuming an openwrt system), please modify / etc/firewall.user to add the above, so that these policies will still be applied after the route is restarted.

So if the rules are released, how can we see if the rules are in effect?

1. The client accesses it using curl or browser to test the current url

two。 Use iptables-L INPUT-xv & & iptables-L FORWARD-xv & & iptables-L check_for_9011-xv on the firewall to see the status.

3. If the openwrt web version, available status-> firewall view, such as the following figure:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.