Security Laboratory

Security Laboratory

Top 5 Firewall Leaks

Chris Brenton

Executive Summary

Attack techniques have evolved to where traditional packet filtering firewalls, proxies, and even intrusion prevention systems are dramatically less effective at securing a corporate network. The common flaw in most perimeters is that they are designed to thwart inbound session establishment, while being relatively permissive in what they pass towards the Internet. This paper outlines the top five traffic patterns that currently breach most network perimeters.


Figure 1 graphically details the typical problem with most Internet perimeters. The legacy method of designing a network perimeter was to install a firewall that controls Internet traffic. The firewall is typically configured to control inbound session establishment such that access is only permitted to hosts on a screen subnet. Further, since the internal systems are deemed to be trustworthy, little to no control is placed on outbound access. Even if content checking is bring performed, encrypted communication channels such as SSL, SSH and IPSec are not scrutinized as the data stream is already encrypted.

Figure 1: A Typical Internet Perimeter

Figure 1: A Typical Internet Perimeter

Leak #1 - Third Party VPN Solutions

Let's assume for a moment that you have an employee that wishes to gain access to the corporate network from a host out on the Internet. Let's further assume that for whatever reason they do not wish to connect through the corporate sanctioned VPN gateway (they don't like the solution, do not wish to have their activity logged, etc.). Unfortunately there are third party companies that are more than happy to help them facilitate this breech of your security policy for a monthly fee.

A good example is For a monthly fee of $20 or less, provides a VPN solution that can help your employees circumvent your perimeter controls. They simply sign up for the service and install a software program on both their work system as well as the host on the Internet. The two packages work together in order to permit the user to take control of their desktop system located behind your perimeter. While this functionality is similar to Microsoft Remote Access or Citrix MetaFrame, unlike these services the solution is specifically designed to thwart controls implemented by a corporate firewall.

Figure 2 shows how this connectivity is facilitated. When the service is activated on the user's work system, it creates an outbound connection to a server. The outbound target ports used are TCP/80, TCP/443 or TCP/8200. The service will hunt between these ports till outbound access is gained. TCP/443 is typically the most successful as uses a modified SSL session with AES encryption. Since TCP/443 is used to communicate to Web servers via SSL, this outbound session simply looks like an end user accessing a secure Web site. Since the data is encrypted, content checking cannot be performed. The key here is that your perimeter sees an logs an outbound SSL session that looks no different than normal user traffic.

Figure 2: Server Connecting Sessions

Figure 2: Server Connecting Sessions

When the user wishes to connect to their corporate desktop, they simply launch the software on their home system and logon. Servers on the network take care of connecting the two sessions. The end user now has full control of their desktop while the corporate perimeter sees only an outbound session.

There are a number of ways to defeat this kind of activity. The easiest is to simply block outbound access from your internal network to's network ( If you are the whois listed admin or technical contact of your domain, you can also contact directly and ask that their service be blocked for your range of IP addresses. While both of these solutions are easy to deploy, they only prevent from being used for this type of activity and do nothing to address other third party solutions.

The only way to truly take control of this problem is by taking control of the application user's can install on their desktop. This can be done to some extent by locking down all corporate desktops via access control and limiting menu options. A more effective resolution would be to implement a solution that permits you to monitor and control all software installed on a user's desktop. A good example would be Bit9's Parity software, which provides centralized management of all desktop applications.

Leak #2 - Permitting Outbound VPN Sessions

Similar to the last example, permitting any type of outbound VPN session establishment can lead to data leaks. While I will focus on Secure Shell (SSH) in this example, this problem is just as applicable to permitting outbound SSL or IPSec transmissions. All of these VPN solutions can typically be tunneled through any TCP port. This can lead to additional access being provided through a network perimeter without the knowledge of the local IT group.

SSH is a multi-platform VPN solution. While it is typically used as a secure replacement for clear text tools such as Telnet and FTP, for many years it has also had the ability to tunnel any TCP based application. As of the beginning of 2006, support for tunneling UDP, ICMP as well as other IP transports was added in as well.

SSH is not an evil tool per se'. In the hands of a system or security administrator it can be an invaluable tool that helps to augment security as well as simplify many daily tasks. The problem with SSH is that in the hands of a malicious user it can easily be used for breech corporate policy. This can include circumventing content checking as well as exposing internal services to outside attack. The problems revolve around SSH's ability to tunnel other IP applications. These can be forward tunnels (used to forward application information up to the server) or reverse tunnels (used to forward application information from the server to another internal system). Both of these abilities can easily be leveraged to breech corporate access policies.

Assume for a moment that your company utilizes a proxy server in order to screen content access on the Web. Let's further assume that you have an employee that wishes to access a Web site that breaches this policy, but wants to do so in such a way that it will go undetected. Figure 3 shows a possible use for the forward tunnel capability of SSH which would permit this user to circumvent your content checks.

Figure 3: SSH's Forwarding Tunnel Being Used To Circumvent HTTP Content Checks

SSH's Forwarding Tunnel Being Used To Circumvent HTTP Content Checks

To start, the user needs access to an external system running both an SSH server as well as an HTTP proxy server. Both of these services can easily be deployed on the user's home desktop system. The user than runs the SSH client on their corporate desktop with it configured to create a forward tunnel to the proxy server. Once they logon via SSH, its now just a simply matter of configuring the browser to use a proxy server located at the loopback address. When the user browses the Web, the connection requests are sent through the SSH session to the HTTP proxy located on the Internet. As content passes the corporate perimeter, it is encrypted as part of the SSH session. While you can attempt to thwart this activity by blocking outbound access to SSH's well known port (TCP/22), the user can easily configure SSH to run over any TCP port. Again, TCP/443 is usually a good choice, as this port is usually not scrutinized.

SSH's reverse tunnel capability can be even more dangerous. This is shown in Figure 4. In this example when the user runs the SSH client on the corporate desktop they request a reverse tunnel and specify which port the SSH server should open up. Any connection requests sent to the SSH on that port will be forwarded to the corporate desktop. The user then tells the SSH client which internal system should receive these data requests.

Figure 4: TCP/80 Connections Sent To The Home System Reverse Though The Outbound SSH Session

TCP/80 Connections Sent To The Home System Reverse Though The Outbound SSH Session

This example is based on an actual situation I ran into in the field. A client contacted me regarding some forensic work. They had an HR Web site that had been compromised, and all log entries pointed to the attack being performed by an internal system. The Web server was located on the internal network and was inaccessible from the Internet, thus adding credence to the hypothesis that it was "an inside job". In the course of the investigation, it was revealed that the suspected perpetrator was a grandmother in her 50's. Needless to say this raised a few red flags for me, as she did not meet the typical demographic profile of an elite hacker.

Here's what happened. The woman in question was involved with corporate benefits. As part of her job she frequently accessed the HR Web site. She wanted to be able to work from home, but was told she could not as they did not permit VPN access to her portion of the network and she needed consistent access to the HR Web server in order to do her job. Someone (my guess is a friend or family member) told her how to facilitate this access via SSH. First they setup an SSH server on her home system. Before leaving the office, she would launch the SSH client on her corporate desktop system connecting to the home SSH server. As part of the session, she would request a reverse tunnel so that all TCP/80 connections received by the SSH server would be forwarded to the internal HR Web server. Once at home, it was a simple matter of launching the Web browser and giving it the URL of "localhost". SSH would then forward the request to the HR Web server located behind the firewall.

A couple of points here are worth noting. First, the only connection logged by the perimeter firewall was an outbound TCP session on port TCP/443 going to the user's home desktop system. Because this is a reverse tunnel, the inbound connection establishment is masked within the outbound SSH session. Also, from the perspective of the internal Web server, all connection requests originated from the corporate desktop. The true source IP address gets completely masked. Since the SSH server does not log the source IP connecting to its end of the reverse tunnel, all accountability as to who originated the connection is lost.

Unfortunately, thwarting this type of access can also be problematic. One method is to look for SSH being run over non-standard ports. This leaves you free to permit SSH over TCP/22 and control the level of access you wish to provide (for example restrict users from connecting to their home systems). If you run the Snort intrusion detection system, you could add the following two rules to your local.rules file:

 alert tcp any any -> any !22 (msg: "SSH v1 to non-standard port"; flags: A+; content: "SSH-1"; depth: 5; flow: to_server;) alert tcp any any -> any !22 (msg: "SSH v2 to non-standard port"; flags: A+; content: "SSH-2"; depth: 5; flow: to_server;) 

Unfortunately, this solution only cures the problem if SSH is being used. If the user is running SSL or tunneling IPSec over TCP, the above signatures will not detect the access attempt. To truly lock this down we are back to locking down applications on every user's desktop as discussed in the last example.

Leak #3 - Internet Relay Chat (IRC) Used By Zombies

IRC is a text based communication system. Think of AOL Instant Messenger where dozens of people can be conversing with each other at the same time and seeing what everyone else is typing and you will get the idea. Communications are carried out by joining a particular IRC channel. This channel can be serviced by a single server or multiple. IRC also contains facilities for sharing files between systems that have joined the channel.

IRC makes an excellent mechanism for attackers to maintain control of systems they have compromised. The compromise can be performed via a worm, e-mail, malicious code on a Web site, or whatever mechanism is available to the attacker. Once the system is "0wn3d", it is programmed to report in to a particular IRC channel and wait for further instructions. This makes it trivial for an attacker to safely manage their "bot network" because they can bounce through multiple systems all around the world before joining the channel themselves. They can then issue commands, which are quickly received by all of the systems under their control.

Figure 5 shows a typical example of a compromised internal system connecting to an IRC server in order to get its marching orders. Note the TCP ports listed are only the defaults. Blocking access to these ports will thwart a large number of these attacks, but it is entirely possible for the attacker to use a non-standard TCP port. Further, it may be beneficial to not only block access to these ports but alert on access attempts as well since they are an indication that an internal system may have been compromised.

Figure 5: A Compromised System Connecting Out For Orders

A Compromised System Connecting Out For Orders

While blocking port level access is helpful, the only true way to detect this activity is to look for IRC connection attempts on all TCP ports. This can be done by checking the first ten outbound packets for the payload string:
join 0x3A 0x23

If this pattern is detected, an internal system is attempting to join an IRC channel. You can check for this pattern using an existing intrusion detection or prevention system. If you do not run either of these systems, a tool such as ngrep can be used provided it can be run on a system that can see all Internet traffic.

Leak #4 - Banner Grabbing

Most IP application servers will present some form of banner when a client connects to the system. For example our solution to the SSH data leak was to simply look for the banner information displayed by every SSH server. Banners can reveal information that can be extremely useful to an attacker such as which application you are using as well as the application's version.

We obviously do not want to make it any easier than necessary for an attacker to compromise our systems. By displaying banners that identify our software and version numbers, we make it easy for attackers to enumerate if their attack will be successful. Without the benefit of the banners, the only way an attacker can tell if their attack will work is to launch it against our system. If we are vigilant in keeping our systems secure, the attack will fail but now we have an audit trail informing us that someone is attempting to gain access to our systems. This forces the attacker to show his or her hand, which has given us a valuable clue that someone is attempting to gain access to our network. If the attacker could simply check our banners to see if their attack would be successful, we would never see them coming until it was too late.

Its important to not that we are talking about security through obscurity. This means that if we hide our banner information, we really have not increased the security level of our systems. We still need to keep them patched and properly locked down. All we have done is make the attacker's job more difficult and created a situation where we will receive an early warning that someone is up to no good. Look at it this way; the bad guys have been making our lives more difficult for years. The least we can do is return the favor.

Here are some examples of simple banner grabbing attempts:

 [cbren@host cbren]$ telnet 21  Connected to 220 FTP server (Version wu-2.4.2-academ[BETA-18-VR14](1) Thu Feb 25 09:20:02 EST 1999) ready. [cbren@host cbren]$ telnet 80 GET / HTTP/1.0 Server: Apache/2.2.4 (Fedora) 

So assuming I'm an attacker for a moment, if I have access to an exploit that works against Apache 2.2.4, I now know I can successfully compromise the above system. If I have access to an exploit that worked against Apache 2.1 but was fixed in later releases, I know not to bother trying the exploit as it will not be successful and my attack attempt will get logged.

Fixing this problem varies depending on the application. For example fixing this in Apache is as simple as adding the line "ServerTokens Prod" to the httpd.conf file. If you are running IIS, Microsoft hard codes the banner so you cannot change it. Your only option is to run some form of reverse proxy in front of the server.

Leak #5 - Non-Signature Malware

Non-signature malware, as the name implies, is viruses, worms, Trojans, backdoors, etc. to which there is no known signature for detection. While many AV programs make some use of heuristics, the primary method of detection is still pattern matching via signatures. No signature means that we may have no way of detecting the malicious code if it passes into our network.

Over the last few years the paradigm for the release of malicious code has changed. In the past the motivation of virus writers was to attempt to infect as many systems as possible. While we still see script kiddies following this model, the hard-core folks have evolved to the point of turning it into a business model. Rather than attempt mass infection, they perform directed spear attacks for the purposes of financial gain.

How do you make money by writing viruses? One possibility is espionage. Hang out in the right IRC chat channels and you will find folks you can hire to attack your business competitor's networks in order to extract crucial information. This could be financial information, client records, development plans for new products, etc. In short, dropping a call home Trojan on an internal system can easily facilitate attacks that used to require an insider. If the Trojan has not been released in the wild, AV software will not have a signature for it and thus the malicious code will avoid detection.

The other profitable business model is extortion. Attackers have been known to steal critical information from an organization and demand payment for its return. In other words you are extorted into keeping the information from being released into the public eye. Companies have literally gone out of business from not paying up.

You can perform a simple experiment to see just how easy it is to fool perimeter AV software. For example obtain a copy of "VBS Worm Generator" (URL is listed in the reference section at the end of this document). This is a very simple tool for generating self-propagating worms based on Visual Basic Scripts. We will not actually run these worms, so you can perform this test without fear of infecting your system.

We are going to use VBS Worm Generator to create three simple worms. For the first one, simply change the "Your name" field to some value such as "TestUser". Once complete, click the "Generate" button in the bottom right of the window. You will be prompted with an end user agreement and then asked to select a directory location. Name the worm "worm1.vbs" or similar and save it to an empty working directory.

Now, return to the main window and click the "Extras" button. Select the "Encryption" option from the pop up menu. Click the "Use Encryption" radial button within the encryption window, and change the encryption method from "String Encryption" to "Full Code Encryption". Click "Done" to close this window and then select "Generate" from the main window. This time save your work as "worm2.vbs".

Once that worm has been saved, go back to the main window and again select "Extras", then "Encryption". Change the encryption method back to "String Encryption". Select "Done" and then "Generate". This time save your work as "worm3.vbs".

Now comes the fun part. Close VBS Worm Generator and navigate to your test directory via file explorer. Right click the first worm and select you're AV software's option for virus scanning the file. Most AV software will identify the first worm as "Worm.Godog" or some similar variant. Scan the second worm and most AV software will report it as "VBS.Lee" or some variant. Scan the third worm and most AV software will tell you the file is clean!

So what happened? By making changes to the pattern of the worm we were able to change our AV scanning results. The most important scans were the first and last ones. The first is important because this shows us that the worm created by VBS Worm Generator is a known variant with working signatures. The third scan is important because we found that by changing the pattern of a known worm it was trivial to get it to fly under the radar of the AV software.

So clearly it's relatively easy to generate Malware that will not be detected by AV software. Needless to say an attacker motivated by financial gains can easily leverage this "feature" to achieve high-level access to an internal network. A custom worm or even a variation of an existing worm may pass corporate AV checking and be delivered via e-mail or similar to one or more desktop systems.

So how common is this type of attack? Understandably, only a very small percentage of this activity ever makes it into the press. The following URL's discuss some of the more high profile cases that have hit the news wires, but the problem is more wide spread than it appears on the surface.

Neutralizing this leak is far more difficult that all of the previous examples. Our only option is to implement a solution that facilitates centralized control of the applications that can be installed or run on all corporate desktops. Again, a product such as Bit9's parity which can validate all executables by size, date/time stamp as well as MD5 and SHA-1 hashes is our only option for keeping customize Malware from being run on our corporate systems.