Firewall Evasion with UDP (PingTunnel)

by asdfasdfasdfasdf on October 7, 2014

This is a follow up post to using PingTunnel to bypass security controls by tunneling traffic over ping. For this example we will use the same tool but do it over UDP instead. For the background, architecture, and other specifics please see this post here.

The reason you would want to tunnel is well documented in the previous post. The reasons why you would want to use UDP instead of ICMP are;

Maybe ping is blocked and DNS is not.
UDP seemed to perform much faster than ICMP. I’m guessing this is because UDP is better at dealing with out of order packets but wasn’t able to find any evidence to prove that.

When using PingTunnel using UDP the performance was so much better over ICMP. As a result my favorite way to tunnel the traffic is using the SSH proxy method below. You will likely be able to SSH into the system configured as the ptunnel server, which means that no additional HTTP proxy server needs to be deployed or found.

Ptunnel Server

On the ptunnel server you can run ptunnel without any additional options. The -v 4 increases the output which can be good for troubleshooting. The -x allows you to specify a password. The new argument we have added is -udp which switches from the default of ICMP to UDP;

ptunnel -udp -v 4 – x <password>

There are a few ways that you can use the tool to browse websites.

Local HTTP Proxy

In this configuration a proxy is started on the client device. From there what you send to that proxy will go over the tunnel. You still specify the target website, so the limitation is that you need to change the destination address in the ptunnel command for every site you want to get to.

ptunnel -udp -p <ptunnel server IP> -lp <local port to open> -da <target website URL> -dp <open port on website>

So my command looked like this;

ptunnel -udp -p 192.168.55.146 -lp 8080 -da www.thepiratebay.se -dp 80

From there open a browser and browse to http://localhost:8080. This should load www.thepriatebay.se in this example.

Remote HTTP Proxy

In this configuration you can use an HTTP proxy in addition to the ptunnel server.

So traffic will go from your client to the ptunnel server over ICMP to an HTTP proxy specified after -da. The proxy can be one that you setup on the ptunnel server or an open one you find.

The ptunnel server will send the request to the HTTP proxy. The HTTP proxy will make the requests to the target website. The HTTP proxy can be running on the same host as the ptunnel server.

The benefit is that you can set everything up once and browse any website that the HTTP proxy can get to.

ptunnel -p <ptunnel server IP> -lp <local port to open> -da <open HTTP proxy server IP> -dp <open HTTP proxy server port>

The other setup you will need to do is change your browser proxy settings to be localhost on the port you specified with lp.

So my command looked like this;

ptunnel -p 192.168.55.146 -lp 8080 -da 192.168.55.146 -dp 3128

The switch your browser to use localhost for the HTTP proxy on port 8080

SSH SOCKS Proxy

Similar to the way you can proxy through an HTTP proxy, SSH can be used as a SOCKS proxy.

So the traffic will appear to be ICMP traffic from the client to the ptunnel server and then the HTTP requests will be encrypted in an SSH tunnel, and finally the SSH server will make requests to the target server. The SSH proxy can be running on the same host as the ptunnel server.

The other setup you will need to do is change your browser proxy settings to be localhost on the port you specified with lp.

ptunnel -p <ptunnel server IP> -lp <local port to open> -da <localhost> -dp <open SSH server port>

then…

ssh -p 8080 -C -D 8081 <username>@localhost

So my commands looked like this;

ptunnel -p 192.168.55.146 -lp 8080 -da localhost -dp 22
ssh -p 8080 -C -D 8081 remnux@localhost

Then switch your browser to use localhost for the SOCKS proxy on port 8081.

In this case the security appliance used determined this as unknown-udp. The traffic was going over UDP port 53 which is DNS, however because the payload didn’t behave like DNS it was grouped as unknown-udp. This is a good example of why unknown-udp and unknown-tcp should not be permitted in a network. The recommended use of these applications is to identify any of your in-house custom applications being dropped into the unknown, create an app so that it is known, and then stop allowing the unknowns.

The appliance also offered a packet capture because it was unknown so that you can figure out if it is desired or not. Here is that capture. It pretty much looks like garbage because that is SSH tunneled within UDP.