Analysis and solutions for the hijacking of Netcom users to access P2P websites such as VeryCD

Today, I finally got idle and sorted out some analysis records and Solutions of VeryCD hijacking a few days ago. I believe this document is of great reference value to my webmaster.
By the way, I would like to recommend an article written by Caoz. I hope everyone can understand the bitterness behind the website:Starting from the hardships of being a webmaster

Today, I finally got idle and sorted out some analysis records and Solutions of VeryCD hijacking a few days ago. I believe this document is of great reference value to my webmaster.

By the way, I would like to recommend an article written by Caoz. I hope everyone can understand the bitterness behind the website:Starting from the hardships of being a webmaster

====
In other words, the hijacking continued on the second day after VeryCD and other websites were hijacked. I am bored in the QQ group and caught by Dash and xdanger. I am very honored to be a user of Beijing Netcom. This great task can only be handed over to me.

Access VeryCD in the normal way and obtain the following results.
Sam @ Bogon :~ $ Curl-v-H www.verycd.com * 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: www.verycd.com> <HTTP/1.1 200 OK <Content-Type: text/html; charset = gb2312 <Content-Length: 182 The returned results are directly hijacked and replaced. Unlike Trojans, the hijacking code is inserted at the beginning or end of the webpage content.

Then, enter the VeryCD IP address directly. The returned result is the default page of the squid server of VeryCD, which indicates that the IP address is not considered as the hijacking criterion. It should be the domain name of VeryCD or a feature on the webpage that causes the hijacking device to replace the content. (The result is omitted here)

Since the domain name is one of the criteria for judgment, you can try to replace the Host method in the HTTP protocol to test
(1) Sam @ Bogon :~ $ Curl-v-H Host: www.veryc.com www.verycd.com * About to connect () to www.verycd.com port 80 (#0) * Trying x. x. x. x... connected * Connected to www.verycd.com (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: www.veryc.com> <HTTP/1.1 200 OK (omitted) (2) Sam @ Bogon :~ $ Curl-v-H Host: verycd.com www.verycd.com * About to connect () to www.verycd.com port 80 (#0) * Trying x. x. x. x... connected * Connected to www.verycd.com (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 Four test methods are used in this example.
1. Send a request with the Host Header www.veryc.com to the server of verycd. You can see that the data is returned normally and is not hijacked.
2. Send a request with the Host Header verycd.com to the verycd server. You can see that the data is hijacked.
3. A request with the Host Header www.veryc.com is sent to the verycd server using the GET method to obtain the/verycd.com file. The data is returned normally and is not hijacked.
4. To send a request with the Host Header "cmdverycd.com" to the verycd server, we can find that the data is not hijacked.

The above conclusion shows that the device used for hijacking only judges the host part of the domain name.

Let's try another interesting test: What if I send the host to the bbn.com.cn of China Netcom?
Sam @ Bogon :~ $ Curl-v-H "Host: www.vercd.com" www.bbn.com.cn * About to connect () to www.bbn.com.cn port 80 (#0) * Trying 202.106.195.131... connected * Connected to www.bbn.com.cn (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: www.vercd.com> <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"> (omitted)
We can see that nothing will happen. This indicates that the hijacking device should be at the exit of Beijing Netcom.

In order to confirm that the device was on the exit of Beijing Netcom, I tested the device on different lines in Beijing and found that the access was normal. However, a small ISP rented the outlet of China Netcom and was hijacked.
In order to confirm my conjecture, I installed pptpd and rinetd on a server located in an unaffected ISP in Beijing. First, I tested using VPN to link to pptpd on this server, all data packets are sent through the server and accessed to VeryCD.com. Everything is normal and the data is not hijacked.
Then, point the host's hosts to the server and forward the packets to the VeryCD server through the server's rinetd. the packets are hijacked.
Conclusion: encrypted data is not hijacked.

I tried to find a server from the outside. The server has nothing to do with VeryCD and is not in the same physical location. The result is as follows:
Sam @ Bogon :~ $ Curl-v-H Host: www.verycd.com 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: www.verycd.com> <HTTP/1.1 200 OK <Content-Type: text/html; charset = gb2312 <Content-Length: 182 After analyzing this step, the things are clear:
At the exit of Beijing Netcom, a Wall-like device was intentionally or unintentionally placed to hijack all P2P websites in the list. I personally prefer to believe that this is China Netcom testing a new device. Because it is obvious that the data returned after hijacking uses a warning (warn) title, the robbers have a clear understanding of the traffic of these hijacked websites, I didn't use my own servers to support this traffic (based on my data, the traffic of these websites, even static html files, also requires more than a dozen servers ), instead of bringing any code for splitting or counting to Baidu (the code for Baidu statistics and splitting is tn = xxxx ). (Some traffic was allocated to information.com on the third day of the hijacking, and information.com was directly suspended ).
Baidu is also hard to say. So many invalid traffic, resource consumption, and a nickname. As far as I know, Baidu is also looking for ways to contact the affected website after the accident.

====
Solution:
According to the above conclusion, there are several solutions to this problem:
1. Change the domain name to meet the demands of the victim. Low Cost for website owners, but it may lead to the loss of a large number of users who do not know the new domain name. But it can be solved through Baidu Post Bar.
2. Use the BGP protocol to change the route between the Beijing Netcom user and the website server, and skip the hijacking device. The disadvantage is that the cost is too high.