Backdoors, Back Channels and HTTP(S)

Guess what? Data that would normally be blocked by a firewall can typically be tunneled through HTTP(S)--and reach its destination with no trouble at all.

 By Kurt Seifried | Posted Feb 16, 2001
Page of   |  Back to Page 1
Print ArticleEmail Article

As a network or system administrator, you usually desire the ability to limit what goes into and comes out of your network. People achieve this through a variety of methods, the most common by far being firewalls. However, most firewalls and networks in general do have one service they will allow no matter what — the ability for users to surf the Web. HTTP is a very simple (compared to, say, FTP) and well understood protocol, and almost every workstation on any given network is allowed to send out HTTP requests, and usually servers are as well.

HTTP can be proxied. However, this only works well for cleartext HTTP. SSL-encrypted HTTP (HTTPS) is usually not proxied, and systems can talk directly to the Web server without any fear of being eavesdropped. HTTP(S) is also a somewhat interactive protocol. You send a request to the server, and the server sends a response; it is quite typical for these exchanges to continue for some time and transfer large amounts of data. The pervasiveness of this protocol means that data that would normally be blocked by a firewall or other device can typically be tunneled through HTTP(S) so that it can get to its destination unmolested.

There are many legitimate uses for this technique. Microsoft, for example, now uses HTTP to move RPC calls between systems. Normally Microsoft RPC (port 135) is blocked both incoming and outgoing at most firewalls. Now, by tunneling it through HTTP(S) you can move the RPC calls around with no trouble. This allows developers to use RPC calls which are very easy, instead of some other technique that would require a lot of work and some reinvention of the wheel.

In Microsoft's defense, it is probably better in most cases to create some facility to slip RPC calls around a firewall rather than make programmers create their own solution — which will cost development time and money and be prone to errors and security problems. This is only one example of a growing trend. As people become more security-conscious and start blocking ports needed for various services, there will be a growing use of HTTP to tunnel protocols.

Two extreme examples of these are HTTP-Tunnel (a commercial solution for Windows) and GNU httptunnel (an open source solution for Linux and others). HTTP-Tunnel lets you bypass pretty much any firewall. You can use most instant messengers (AIM, ICQ, Yahoo, etc.) over it, and it supports TCP, SOCKS5 (a circuit level proxy), Napster and more. The GNU version of HTTP-Tunnel is similar. To quote their Web page (http://www.nocrew.org/software/httptunnel.html):

This can be useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use httptunnel and, say, telnet or PPP to connect to a computer outside the firewall.

The obvious implications are:

  • Users can connect to outside systems in a manner that is supposed to be blocked at the firewall
  • Users can use software that would normally not work properly when firewalled (ICQ, Napster)
  • Attackers can use these techniques to maintain control remotely (after sending in the malicious code via email, for example)

There are also a number of backdoor programs that use HTTP(S) to connect out to an attacker-controlled machine to request instructions and can also be used interactively by the attacker, making it the equivalent of a telnet shell (which most firewalls would block).

To make matters worse, now that SSL-secured HTTP is becoming popular and commonplace for many sites, the attacker (or insider) can avoid any monitoring, since any existing IDS system will be unable to decrypt the data and examine it. This means anyone relying on an IDS system to catch outgoing HTTP-tunnels will be rendered impotent.

So what can you do to prevent or detect this type of activity?

The first step you should probably take is a modification of your security policy. In it you should state something to the effect of,

Installing software to tunnel protocols such as AIM or ICQ over other protocols such as HTTP is forbidden. If you are unsure whether or not a piece of software violates this policy, please contact Network Security at xxx-xxx-xxxx.

You might then list some examples of the software (such as HTTP-Tunnel for Windows). Generally speaking, if a person legitimately needs outgoing access to some service, they should contact whoever is in charge of security rather than trying to circumvent the systems in place that are designed to prevent it.

The next step would be to tighten control (if you haven't already) on outgoing WWW access. The best method to do this is by installing a proxy server and firewalling outbound HTTP access so that users are forced to go through the proxy. Doing this for HTTPS is more difficult and does create some other potential security issues, but as most HTTP tunneling software is not yet HTTPS-"aware" you can probably get away with it for now.

One proxy service capable of doing this is Microsoft Proxy server. You can restrict access to protocols on a per user or per group basis. Restricting it by machine is also a good option, but then users might be able to log in at a "trusted" workstation and gain outbound access.

If you can, you should log the outgoing requests. This will allow you to look for long HTTP requests, or a series of HTTP requests in rapid succession, and other odd patterns. You can also look for odd usage patterns. Most workstations should not generate outgoing HTTP traffic unless a person is sitting at it. Correlating user logins and logouts with HTTP proxy logs would allow you to spot machines that may be compromised. In addition, by logging direct outbound access and requiring people to use a proxy, you may catch software that is not proxy-aware, allowing you to quickly find suspect machines.

Clients can also use the POST method instead of the GET method, meaning you won't be able to easily log the outgoing data at your proxy. (I'm not aware of any that support logging POST data, since the data can be an executable, images, text, and so forth.) For the truly paranoid, logging all outgoing HTTP data is a potential solution, although in a large environment you will need a lot of space to store this information — and of course, if the site uses SSL, you won't be able to log it.


As always, computer security is a rapidly evolving beast. New threats appear and old threats go away (but never completely, it seems). In former times you could successfully block services based on their port numbers. However, as this has become popular it has forced software vendors (such as Microsoft) whose software and programming languages depend on being able to move data around "insecurely," to find other solutions. Unfortunately, by choosing to move data over popular protocols such as HTTP, especially when it can be easily encrypted, the software firms will make life extremely difficult for corporate network administrators who want to control what services and types of information enter and leave their networks.

As network administrators (or corporate security, etc.) you need to maintain an up-to-date security policy to address these new threats, as well as maintaining multiple layers of security. It is unlikely that software companies (and individuals) will stop building products that circumvent, intentionally or otherwise, your security measures.

Related Links

GNU httptunnel

HTTP RPC Security

HTTP Tunnel software for Windows

Placing Backdoors Through Firewalls

Reverse WWW shell

SecurityPortal is the world's foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.
The Focal Point for Security on the Net (tm)

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter

By submitting your information, you agree that enterprisenetworkingplanet.com may send you ENTERPRISENetworkingPLANET offers via email, phone and text message, as well as email offers about other products and services that ENTERPRISENetworkingPLANET believes may be of interest to you. ENTERPRISENetworkingPLANET will process your information in accordance with the Quinstreet Privacy Policy.