• Home

Hacking Library Network with IPv6

小龙同学

A free and unlimited public network accessing service?

Yes, you can if you are sitting in a Chinese university library.

I have been playing with the tricks for around half a year. Indeed, it works pretty well and delightful. In this post I would like to show how to setup, but more importantly, the process to figure out why, what's going on under the hood.

Correct me if I'm wrong.

TL;DR jump to requirements and setup sections.

Disclaimer

  • use it for good, not evil
  • depending on your environment, not sure whether it works for you
  • as of this writing(Jan. 2017), it may not work well any more in the future

Last but not least, despite things would tend to be different, why not give it a try with all you knowledge? It's fun and you will learn more along the journey.

Requirements

  • a network service which supports IPv6 in a library
  • a local SOCKS5 proxy utility
  • a remote SOCKS5 proxy server with IPv6 configured correctly

The keyword is IPv6, the version 6 of IP(Internet Protocol) layer which is the workhorse of TCP/IP protocol suite. IPv6 is the furture and we are in transition from IPv4 to IPv6 currently.

As far as I know, IPv6 is only experimented in universities or some institutions in China for the moment. The public network is all about the IPv4.

How to setup

  1. connect to the WIFI(or cable) in a Chinese university library without login and obtain network settings via DHCP(default behaviour)
  2. setup your local proxy and make sure all of the traffic outgoing through proxy
  3. try a site in your browser, if not work, try using all of your network knowledge, it's fun!

What's going on

Supposing you have some network knowledge, if not, feel free to skip, though it's the core of this post.

Obtain network settings via DHCP

Connect the library WIFI hotspot obtaining the network settings(IP address, gateway, DNS, etc.). Note we don't have to login.

Print the network settings we can see both IPv6(2001:250:3c02:500:bcb1:ae02:f2a3:79f) and IPv4(10.4.22.155) address(the first inet6 is an admin-local IPv6 address and it adds nothing to discuss here).

> ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether a4:5e:60:d8:db:65
	inet6 fe80::c0a:9554:5e05:416d%en0 prefixlen 64 secured scopeid 0x4
	inet 10.4.22.155 netmask 0xfffff000 broadcast 10.4.31.255
	inet6 2001:250:3c02:500:bcb1:ae02:f2a3:79f prefixlen 128 dynamic
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active

The DNS,

> cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 101.226.4.6
nameserver 219.223.254.2

Testing network availability with IPv4

Dial a website to test the network availability. Take the qq.com(Tencent Inc., Chinese largest SNS and gaming company) for example,

> curl -v http://qq.com
* Rebuilt URL to: http://qq.com/
*   Trying 101.226.103.106...
* TCP_NODELAY set
* Connected to qq.com (101.226.103.106) port 80 (#0)
> GET / HTTP/1.1
> Host: qq.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 302 Temporarily Moved
< Server: Apache
< Content-Length: 0
< Content-Type: text/html
< Location: http://10.0.10.66/index_1.html?url=qq.com
<
* Curl_http_done: called premature == 0
* Connection #0 to host qq.com left intact

The redirect location(http://10.0.10.66/index_1.html?url=qq.com) is just the library WIFI account login page you usually see. The host(IP address) of the URL is 10.0.10.66 which is one of a private IPv4 address in 10.0.0.0/8 that never appears in the public network normally.

Essentially: since we are dialing qq.com, why it redirects us to the login page?

To see what's going on underlying, we have to go deep down to lower layers, with tcpdump, a packet analytics tool.

Before that, let's look at the DNS of qq.com, for sure 101.226.103.106 is the chosen remote address.

> host qq.com
qq.com has address 14.17.32.211
qq.com has address 101.226.103.106
qq.com mail is handled by 10 mx3.qq.com.
qq.com mail is handled by 20 mx2.qq.com.
qq.com mail is handled by 30 mx1.qq.com.

Now, the fun moment:) Note that each line is prepended a number intentionally for readability.

> sudo tcpdump -n 'tcp and host qq.com and port 80'
 1. 13:18:27.296134 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [SEW], seq 2803524010, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 794963006 ecr 0,sackOK,eol], length 0
 2. 13:18:27.298025 IP 101.226.103.106.80 > 10.4.22.155.58103: Flags [S.], seq 0, ack 2803524011, win 63857, options [nop,nop,TS val 794963006 ecr 794963006], length 0
 3. 13:18:27.298076 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [.], ack 1, win 65535, options [nop,nop,TS val 794963007 ecr 794963006], length 0
 4. 13:18:27.298195 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [P.], seq 1:71, ack 1, win 65535, options [nop,nop,TS val 794963007 ecr 794963006], length 70: HTTP: GET / HTTP/1.1
 5. 13:18:27.299379 IP 101.226.103.106.80 > 10.4.22.155.58103: Flags [FP.], seq 1:148, ack 71, win 63857, options [nop,nop,TS val 794963007 ecr 794963007], length 147: HTTP: HTTP/1.1 302 Temporarily Moved
 6. 13:18:27.299403 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [.], ack 149, win 65535, options [nop,nop,TS val 794963008 ecr 794963007], length 0
 7. 13:18:27.299561 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794963008 ecr 794963007], length 0
 8. 13:18:27.601753 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794963309 ecr 794963007], length 0
 9. 13:18:28.2829 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794963710 ecr 794963007], length 0
10. 13:18:28.604287 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794964311 ecr 794963007], length 0
11. 13:18:29.606856 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794965312 ecr 794963007], length 0
12. 13:18:31.412725 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794967112 ecr 794963007], length 0
13. 13:18:34.815751 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794970512 ecr 794963007], length 0
14. 13:18:41.423821 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794977113 ecr 794963007], length 0
15. 13:18:48.040094 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794983713 ecr 794963007], length 0
16. 13:18:54.667170 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794990313 ecr 794963007], length 0
17. 13:19:01.288139 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 794996913 ecr 794963007], length 0
18. 13:19:07.912725 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 795003513 ecr 794963007], length 0
19. 13:19:14.528603 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [F.], seq 71, ack 149, win 65535, options [nop,nop,TS val 795010113 ecr 794963007], length 0
20. 13:19:21.159575 IP 10.4.22.155.58103 > 101.226.103.106.80: Flags [R.], seq 72, ack 149, win 65535, length 0
  • 1-3: TCP three-way-handshake connection establishment
  • 4: client HTTP request
  • 5: server HTTP response
  • 7-19: client would like to close TCP connection, but server never ACK client's FIN, so it sent a serials of retransmission segments continuously
  • 20: all retransmissions timeout, so client gave up and sent a RST to reset the connection, leaving the server in a half-open state.

The last segment is interesting, a normal TCP server/client would always like to perform connection termination both side. The tail of curl output also indicates that. It seems the server not work normally. We can guess the server lies us. It's not the real qq.com host but a kind of dispatcher which intercepts your packets flow to see whether you have the networks access authority. If not, it redirects you to do login page by cheating you as if the qq.com.

We just test the web, how about HTTPS(or other non-HTTP services)? It would ends up with a TCP timeout if you try. As a result, we learn that the interception system only talks HTTP protocol.

Another testing with IPv6

As a nature, you may curl your own site occasionally for testing, if any, however, it's where magic things happen. We've got the desired output.

Note the local proxy URL is http://127.0.0.1:8123/

> curl -v xiaolongtongxue.com --header "Connection: close"
* Rebuilt URL to: xiaolongtongxue.com/
*   Trying ::1...
* TCP_NODELAY set
* Connection failed
* connect to ::1 port 8123 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8123 (#0)
> GET http://xiaolongtongxue.com/ HTTP/1.1
> Host: xiaolongtongxue.com
> User-Agent: curl/7.51.0
> Accept: */*
> Proxy-Connection: Keep-Alive
> Connection: close
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.10.2
< Date: Thu, 23 Jan 2017 12:29:54 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: close
< Location: https://xiaolongtongxue.com/
< Strict-Transport-Security: max-age=15768000
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.10.2</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Closing connection 0

This is my DNS,

> host xiaolongtongxue.com
xiaolongtongxue.com has address 160.16.213.54
xiaolongtongxue.com has IPv6 address 2001:e42:102:1808:160:16:213:54
xiaolongtongxue.com mail is handled by 30 alt3.gmr-smtp-in.l.google.com.
xiaolongtongxue.com mail is handled by 40 alt4.gmr-smtp-in.l.google.com.
xiaolongtongxue.com mail is handled by 5 gmr-smtp-in.l.google.com.
xiaolongtongxue.com mail is handled by 10 alt1.gmr-smtp-in.l.google.com.
xiaolongtongxue.com mail is handled by 20 alt2.gmr-smtp-in.l.google.com.

Then tcpdump,

> sudo tcpdump -n 'host xiaolongtongxue.com and tcp and port 80'
 1. 12:29:54.012866 IP6 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096 > 2001:e42:102:1808:160:16:213:54.80: Flags [S], seq 976159655, win 65535, options [mss 1440,nop,wscale 5,nop,nop,TS val 792064441 ecr 0,sackOK,eol], length 0
 2. 12:29:54.349707 IP6 2001:e42:102:1808:160:16:213:54.80 > 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096: Flags [S.], seq 3662062200, ack 976159656, win 14280, options [mss 1440,sackOK,TS val 3285189015 ecr 792064441,nop,wscale 7], length 0
 3. 12:29:54.349759 IP6 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096 > 2001:e42:102:1808:160:16:213:54.80: Flags [.], ack 1, win 4105, options [nop,nop,TS val 792064778 ecr 3285189015], length 0
 4. 12:29:54.350043 IP6 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096 > 2001:e42:102:1808:160:16:213:54.80: Flags [P.], seq 1:84, ack 1, win 4105, options [nop,nop,TS val 792064778 ecr 3285189015], length 83: HTTP: GET / HTTP/1.1
 5. 12:29:54.747403 IP6 2001:e42:102:1808:160:16:213:54.80 > 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096: Flags [.], ack 84, win 112, options [nop,nop,TS val 3285189356 ecr 792064778], length 0
 6. 12:29:54.747409 IP6 2001:e42:102:1808:160:16:213:54.80 > 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096: Flags [P.], seq 1:434, ack 84, win 112, options [nop,nop,TS val 3285189356 ecr 792064778], length 433: HTTP: HTTP/1.1 301 Moved Permanently
 7. 12:29:54.747457 IP6 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096 > 2001:e42:102:1808:160:16:213:54.80: Flags [.], ack 434, win 4091, options [nop,nop,TS val 792065174 ecr 3285189356], length 0
 8. 12:30:25.466399 IP6 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096 > 2001:e42:102:1808:160:16:213:54.80: Flags [F.], seq 84, ack 434, win 4096, options [nop,nop,TS val 792095804 ecr 3285189356], length 0
 9. 12:30:25.878087 IP6 2001:e42:102:1808:160:16:213:54.80 > 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096: Flags [F.], seq 434, ack 85, win 112, options [nop,nop,TS val 3285220472 ecr 792095804], length 0
10. 12:30:25.878207 IP6 2001:250:3c02:500:bcb1:ae02:f2a3:79f.57096 > 2001:e42:102:1808:160:16:213:54.80: Flags [.], ack 435, win 4096, options [nop,nop,TS val 792096215 ecr 3285220472], length 0

This is a fairly normal and simple HTTP request/response segments flow.

  • 1-3: handshake
  • 4: client HTTP request
  • 5: server's ACK to segment 4
  • 6: server's HTTP response
  • 7-10: termination

The distinction form the previous output is IP6 and IPv6 addresses. It means all of these segments transferred through IPv6. Interesting, does HTTPS or others services(ports) works?

Yes.

Conclusion

So, it turns out: IPv6 packets are NOT intercepted by the system.

It's a bug actually, I suppose.

With this fact, if all our traffic go through IPv6, we can bypass the system and get free network access. Unfortunately, like I said before, no IPv6 services in China currently(i.e. we cannot visited those IPv4-only services, the whole Chinese public network services). Fortunately, we can add a abstraction layer by sending all our traffic to a overseas proxy server via IPv6, letting it be our networking hub.

Suppose the proxy server/client configuration is done,

The local outgoing data flow really is: curl -> http proxy -> socks proxy -> remote handling ...

> curl -i http://qq.com
HTTP/1.1 302 Moved Temporarily
Server: squid/3.5.20
Date: Mon, 23 Jan 2017 04:51:47 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Location: http://www.qq.com/
Expires: Mon, 23 Jan 2017 04:52:47 GMT
Cache-Control: max-age=60
Vary: Accept-Encoding
X-Cache: HIT from tianjin.qq.com

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.6.0</center>
</body>

I won't show the tcpdump output because the protocol payload is encrypted and the filter can be tricky, however, the basic rule is the same as before.

Another interesting thing is that in the HTTP response header, X-Cache: HIT from tianjin.qq.com. It's reasonable since my VPS server residents in Tokyo(Tianjin is not far from Japan).

We have discussed TCP and it works. Another question arisen is that does UDP work? You can figure it out by analytics UDP datagram, like DNS, DHCP, Broadcast, and so forth.

The short answer: since UDP sits above on top of IP layer, UDP via IPv6 is perfectly fine.

In fact, at the very beginning, the DNS from DHCP are public IP addresses and it works, so we can infer DNS with IPv4 is okay(moreover, the system may let UDP go without a word). Further analytics need to be done.

If it's true, another way to achieve by wrapping all TCP traffic into UDP, however, it's tricky.

Bonus

  • a proxy usually copes with network blocking, consider you are now not only free access network but also block network service like Google, Twitter, and the like
  • you can even share your network to other devices around the same network

Reminder

  • again, use it for good, not evil
  • since the remote server is abroad, the latency is likely larger than usual and you have to live with it
  • same reason as above, some content may be different or restricted due to a certain GEO content delivering policy
  • from tcpdump output in the post, we can see the HTTP traffic are plain text(not to mention full protocol decode if enabled), so HTTPS is the prefer way. However, HTTP is easy to debug in the low level anyway

Happy hacking and thanks for reading.

PS: The Chinese Spring Festival is coming, best wishes for you!

🏷 Hacking  🏷 Networking  
© cc-40-by