Tunneling Through the Great Firewall of China Again

Nearly two years ago now, I wrote about tunneling through the Great Firewall of China (GFW). I recently revisited this topic and wanted to give a more detailed walkthrough of the process I took to make everything work.

Before I dive into the “how,” I first wanted to mention why I recommend SSH tunnels over standard VPN connections. There is really only one reason — China likes to mess with VPN connections (e.g.: here and here). By using SSH tunnels, we avoid this known issue with VPN solutions for circumventing the GFW. Additionally, even if China chose to try and prevent SSH tunneling, this would be nearly impossible due to one simple fact: VPN providers are publically known and a limited number of IP ranges, your personal SSH server is not publically known and could be any IP anywhere.

If you are convinced that this is the right approach for your tunneling needs, I highly recommend that you have multiple servers available. You never know when a server will go offline or when the Middle Kingdom will opt to block an IP and you do not want to find yourself stranded with no tunnel available. Redundancy is a must.

PuTTY Configuration

The first step is configuring the various PuTTY connections you plan to use. When setting up accounts on your server(s), I recommend making these accounts highly restricted as they only need to be able to port forward. This can be easily achieved using rbash, as described in Creating a Restricted SSH User for SSH Tunneling Only. Once your servers are setup with appropriate tunnel user accounts, you’ll want to configure your PuTTY settings as follows:

  1. Session: Set the host IP address (not hostname) and port number.
  2. Window -> Behavior: Uncheck “Warn before closing window.”
  3. Connection: Set “Seconds between keepalives” to 30 (or some other number as appropriate)
  4. Connection -> Data: Set “Auto-login username” to the user you’ve setup on the target server.
  5. Connection -> SSH: Check “Don’t start a shell command at all” and “Enable compression.”
  6. Connection -> SSH -> Tunnels: Set “Source port” to 8080, select “Dynamic” radio button, then click “Add”; you should now have “D8080” listed in the “Forwarded ports” box.
  7. Go back to Session, under “Saved Sessions” type the name you want this configuration saved as and click “Save.”
  8. For each of your remaining servers, change the hostname/port on Session tab and set the username on the Connection -> Data tab, then re-save with a new name (this avoids repeating all of the above steps for each server).
  9. * If you are doing this setup for a non-technical friend and cannot be at their computer for some reason, you can configure PuTTY with all of the servers to be used on your machine, then send the configurations to the friend. Unfortunately, PuTTY stores configurations in the registry, making it a bit tricky to access, but I used the export PowerShell script show here to create a reg file after doing all of the necessary configurations. I then sent the reg file to my friend, who can simply double click the file to merge the PuTTY settings into their registry.

Once PuTTY is configured, you’ll probably want an easy way to launch PuTTY each time you need to browse. There are many ways to do this, by my solution was a one-line batch file:
start "Proxy" "%~dp0putty.exe" -load hello-china -pw ******

In the above line, “hello-china” should be replaced with the name you saved your server configuration as in step #7 above. If you configured multiple servers, you can just create multiple batch files, one for each configuration. Note that this script expects putty.exe to be located in the same directory as the batch file. If it’s somewhere else, you should modify %~dp0putty.exe accordingly.

Firefox Configuration

As of writing this, Firefox is still the only mainstream browser I know of where SOCKS5 proxying is supported, which is necessary for remote DNS resolution — a requisite for this approach. Since I wrote the first post on this topic, Firefox has made the necessary settings much more accessible, no longer requiring searching through about:config settings.

To enable proxying through your SSH tunnel, perform the following steps:

  1. Launch Firefox and go click the top right button with three horizontal bars and in the resulting menu click “Options.”
  2. Go to “Advanced” in the left navigation bar, then click “Network” in the top navigation.
  3. Under the Connection header, click “Settings…”
  4. Select the “Manual proxy configuration” radio button and fill in SOCKS host as “127.0.0.1,” port as “8080,” then check the “Remote DNS” box.
  5. Click OK.

With all of this setup, launch one of your configured SSH tunnels and in Firefox visit ipecho.net and verify that your IP is reported as the IP address of the SSH server your are using to proxy connections. Further verify that if you kill your PuTTY connection and try to browse anywhere in Firefox you get a proxy error.

And that’s it. Happy browsing!

Tunneling Through the Great Firewall of China

Among the things that the People’s Republic of China is known for is the Great Wall of China, however, we tech nerds also associate the country with the Great Firewall of China (GFW). The GFW, officially known as the “Golden Shield Project,” is an ever-growing effort by the Chinese government to implement strict censorship of the Internet content accessible to its citizens. Sites that are or have previously been blocked include Google, Facebook, YouTube, and WordPress, plus many more.

Chinese flagRecently, a friend of mine was planning a trip to China in order to teach an ESL course. In addition to his understandable desire for some level of privacy in his internet access, he also needed access to YouTube in order to do some of the segments in his curriculum. When he asked for recommendations on how best to circumvent the GFW, my first thought was to use a VPN, but, after doing some reading, I discovered that the GFW has added technology in recent years to detect and block IPs associated with VPNs (see here and here).

With a true VPN no longer a reliable option, the next best thing I could think of was to use an SSH tunnel as a VPN alternative. Instructions for running an SSH tunnel on a Windows OS using PuTTY are scattered over the web, including here and here. The “gotcha” that you may well run into (as my friend did), is that you must enable remote DNS lookup, otherwise the URLs you are requesting will be visible to the GFW.

In order to do this, you only need to navigate to about:config in your Firefox browser (unfortunately, no other popular browsers currently support SOCKS5, which is required). In config, search for “dns” and double click on the line called “network.proxy.socks_remote_dns.” Once this value is set, Firefox will resolve all queries through your SSH tunnel, returning the encrypted content for your viewing pleasure.

So that was my experience tangling with the GFW. This great technological wonder is ever-evolving and has begun to defend against VPNs, one of the newer forms of secure access to the web. It is possible that the GFW could also detect and block the SOCKS5 protocol in the future, but for now at least SSH tunnels are still a viable option for tunneling through the GFW.

The Importance of Sanitizing Input Strings

As a young programmer, it’s easy for me to forget that, unlike in the academic programming environment, it is vital that I protect my programs against any and all potential attacks. Recently I realized just how easy it is to leave a gaping hole in a program’s security. I am posting this today as both a reminder to myself and a warning to any who might run across it: sanitize your program input!

Recently I was working on a personal project: a little web app that displays the machines in the Computer Science department lab based on active OS (since they are dual-booted with Ubuntu and Windows XP, the OS will regularly change on any given machine). You can see a snapshot of an older version of the map that was released a few months ago here.

The map worked fine, but it had a lot of overhead and required root privileges to run, so I decided to rewrite the backend using netcat instead of my previous solution which utilized nmap‘s OS detection. With netcat’s z flag, determining whether a machine is listening on a given port is trivial and since the labs are all extremely homogeneous it only requires a test of port 22 to determine if the machines are booted into Ubuntu (which will accept SSH connections) or into Windows (which will deny port 22 connections) or offline (in which case the connection will be dropped).

In any event, I wrote a PHP script which accepts three parameters based on the names of the lab machines, “prefix,” “start,” and “end.” If I were to call the script with the following query string: ?prefix=dog&start=1&end=62 then the script would scan the machines between dog01.cs.utsa.edu and dog62.cs.utsa.edu.

In order to make this magic happen, the program must make a shell call to netcat for each machine to be scanned. This can be completely safe, but only if you sanitize your data. Since the prefix will be used in each shell call and, unlike the numeric values for “start” and “end,” will remain static, it is perfect for inserting malicious code by the user. Before I released the script, I did one final sanity check and realized that I had not sanitized this value. Before closing the hole, I decided to play with the exploit a bit and the following is what I did:

First, I considered how the input strings were used in my program. The following string was passed to the shell for each iteration through the machines: /bin/nc -zv -w 1 $mac 22 2>&1| /bin/cat -. The value for $mac was defined as the user-entered $prefix and the sanitized integer value somewhere between $start and $end. As a proof of concept, I decided to do an ls of the /home directory to see who was currently mounted on the web server. Obviously, a user who wanted to do more damage could conceive of much worse things, but I was not inclined to foo-bar the server for the sake of this test.

It turns out, all that was required was to insert the URL-encoded value of “;ls -l /home;” as the value for $prefix. It breaks the netcat call, but that’s OK. The output returned was the following:

total 28
drwx-----x 45 bwright students 4096 Apr 22 12:17 bwright
drwx--x--x 86 drossite students 4096 Apr 28 19:59 drossite
drwxr-xr-x 137 lmaddox students 20480 Apr 25 20:03 lmaddox
sh: 01: command not found

(That last bit about command not found is the shell trying to figure out what to do with the integer that was given after our second semicolon.)

To resolve this security hole, all that is required is a regex replacement of all special characters. In this particular instance, anything other than letters is not going to represent a valid prefix, so, after pulling the prefix from the user, I simply apply the following: $prefix = preg_replace( '/[^a-zA-Z]/s', '', $prefix ). For my specific implementation, I am also able to limit the length of the value passed in (not shown). And that’s it. The program is now secure against malicious users compromising the server, through user input, at any rate.

If you have a similar almost uh-oh, feel free to share in the comments below!