HTTP Tunnels

The computer security world has come a long way over the past decade or so. There are all kinds of programs to mitigate external threats and the ever present spectre of viruses. What about those programs that are initiated from the trusted internal network though? Read on to learn more about the threat of HTTP tunnels.

HTTP tunnels

When people hear the words HTTP tunnels they often think quite literally. To them it is some data being transported inside of HTTP data. This line of reasoning is in actuality not far off from the truth. Data is being transported via port 80 and that port is normally associated with HTTP, but that is where the literal interpretation mentioned above ends. Typically, data is not encapsulated within the HTTP protocol itself, but merely sent over port 80. To understand the whole reasoning behind HTTP tunnels we first need to understand a few concepts and how they impact the usage of these tunnels.

In most corporate networks there is pretty good security in place to prevent breaches from occurring. Some other networks also have even better security in place. This heightened security is composed of various components. One of them is that there are only a certain small number of ports that are left open for outbound connections. Some of these ports could be port 25, 110, and port 80 so that the company employees can surf the web and check email. A lot of other ports that are associated with troublesome applications like IRC are closed on the router for outbound connections. Ports such as 6666 on are typically not allowed for outbound endpoints.

Having your system administrator put together a coherent Internet usage policy goes a long way towards helping secure your network. The router can be used as a powerful first line of defence for both inbound and outbound activity. After having put together such a policy it is not unheard of to see some employees trying to circumvent these security measures. One of the most used and often heard of ones is through the use of HTTP tunnels. All manner of programs can be used via the HTTP tunnel, and that is where the threat comes from. Seen as almost every company has HTTP 80 outbound allowed, do you really know what is going on or more specifically going in or out port 80?

Know the enemy

HTTP tunnels can actually have two uses as it impacts computer security. One of them is that people tunnel over it other applications like the above-mentioned IRC, or that it can be used as a reverse HTTP tunnel. Neither one is desirable, but of the two a reverse HTTP tunnel is a far greater threat. Dealing with a tunnel, which is used for the purpose of say IRC usage is bad enough, but the question is how do you stop or detect it? Having the ports closed for outbound purposes is a very good first step, but having done that may have driven someone to use a tunnel over the allowed outbound port 80.

One can help mitigate the use of HTTP tunnelling programs by having a pre-approved software baseline for the corporate network. Further to this only someone with system administrator privileges is able to install software. These are good first steps to take, but they can be bypassed by someone with a modicum of computer knowledge. Once someone has physical access to a computer all bets are off, and privilege escalation can be done fairly easily. This leads back to the point of detecting the usage of these programs and there are several of them out there. This HTTP tunnelling program is quite brazen about the services that it offers.

Knowing that there are threats out there is good, but you will only get to understand them by actually using them. Whether that be using a POC for a specific buffer overflow or installing and using an HTTP tunnelling program. The vast majority of them are simple to use, hence their popularity.

Detecting HTTP tunnels

Detecting HTTP tunnels is not an impossible task by any means, but it does take some knowledge of the HTTP protocol itself. We know that HTTP observes the client/server model and operates on port 80. One key piece of information that we also know is that typically the web browser will send short packets to the web server. The web server in turn will send back primarily large chunks of data. In other words you will quite often see packet sizes from the web server inbound to the client with a packet size of close to 1500 bytes.

We now have a number to work with. Further to that, if you quickly study packet sizes as sent out by the web client they are typically quite small ie: in the low hundreds. Further to this is the fact that HTTP is not a persistent connection. By that I mean that the web client will not keep an open connection to some exterior site on port 80 for hours. It will likely last in the minutes. Knowing this is a second key metric that we can use to detect HTTP tunnels. Someone using such a tunnel will likely have it open for hours if they are using IRC or some other such program.

Let’s see how

So we now have some rudimentary information to work with in our effort to track down these tunnels. We also have to make sure some other steps are in place to further our efforts. In case you are not running an IDS or other packet collection device I suggest you install windump.exe so that you can take a sampling of data so that you can mine it. This data collection method will allow you to collect only the data you want or collect everything. There is, for this exercise, no use in collecting all internal traffic. You only want traffic that is destined for port 80. You will need to collect this data file on a computer that has a significant amount of memory available to it. Also this will need to be likely plugged into the span port of your main switch so that it sees all traffic exiting your network.

-s 1514 –w collection_file ip and src net 192.168 and dst port 80

The above noted filter, when entered via windump.exe, will capture the first 1514 bytes of packets and write them to a binary log file called “collection_file”. This is assuming that you have not narrowed your bandwidth pipe further upstream. Further to that they must come from a source network of 192.168/16, and be going to port 80. This helps narrow the focus of your collection.

You could expand on this and write up a bitmask for the “Total Length” field in the IP header. If you think about this it is quite useful for the purpose of finding such covert tunnels. A normal HTTP session would only generate small packets to a web server. Illegal usage of an HTTP session or tunnel would likely generate large outbound packets to port 80. This would be one defining method in which we would likely discover the usage of HTTP tunnels. The syntax for such a filter would be as follows below:

-s 1514 –w collection_file2 ip and src net 192.168 and ‘dst port 80’ and ‘ip[2:2] > 200’

Wrapup

When it comes to securing your networks you must always have situational awareness. That comes in many forms and for some us we help maintain that by subscribing to various mailing lists. It also helps in understanding how programs and protocols themselves work. By knowing how an HTTP tunnel works and what they look like at the packet level is very helpful. You will also have noticed that collecting packets off the wire is also an excellent means of understanding what is going on within your network.

While the above noted filters are a starting point they also still need to be refined. Not all traffic going over an HTTP tunnel will conform to the norms of the HTTP protocol. With this information in hand about the behaviour of HTTP tunnels you can begin your search in rooting them out. I hope this article was of use to you and as always welcome your feedback. Lastly, please remember that to truly understand something you really need to recreate it or do it yourself.

Sumber:http://www.windowsecurity.com/articles/HTTP-Tunnels.html