FireHole

or

Updated 3/25/2002 8:23AM

With the advent of personal firewall products such as ZoneAlarm, Tiny Personal Firewall, Sygate Personal Firewall and many others we saw a diversion from the typical concept of a firewall only blocking inbound network traffic by having the product monitoring and blocking outbound traffic. This was a good thing because it alerted the user to potentially malicious or privacy compromising programs running on their systems trying to talk out to the Internet for whatever nefarious deeds they were designed to perform.

In mid 2000 Steve Gibson of Gibson Research Corporation made a much publicized revelation of the poor quality of outbound traffic detection by most of these new breed of personal firewalls with his LeakTest proof-of-concept test utility. Since these firewalls relied on application trust levels provided by the user it was shown that simply replacing a trusted application with a trojan version of the same name the firewall would allow traffic to pass from the program with all the privileges of the real version. This was soon fixed by the firewall vendors by performing checksums of the trusted applications and warning the user if a different copy of the program was detected. All was well with the world.

So forward to today. Well actually forward to many months ago, when it occurred to me that there were probably still many more ways to circumvent the outbound detection processes of personal firewalls. Given the premise of LeakTest in that it simulates a malicious program that has somehow found its way onto your computer (via email for example) then to all intents and purposes you don't stand a chance in stopping the code from doing anything the computer user sitting infront of the machine can do. If you can close down your firewall by selecting a popup menu on the system tray then so can a program. If you can terminate a process by bringing up the Task Manager then so can a program. You don't stand a chance. Game over.

I put the idea of writing code to bypass outbound firewall control to the back of my mind since as stated it was really a futile idea when you thought about it. Of course it could be done in several possible ways so why waste the time. But of course being a programmer I sometimes can't resist just trying out ideas, and with all of the current fuss being made about the claims of various personal firewalls by many people I decided to write a proof of concept tool with the aim of obtaining a covert outbound network connection that would go undetected by the firewall.

First off, I realized that trying to bypass things by delving into low level network APIs probably wouldn't work on all personal firewalls. I wouldn't get away with that. Thinking some more it became obvious. What one piece of network related software do pretty much all Internet users have on their system? What piece of software do they inherently trust to allow unhindered outbound access on at least one port? Why, your web browser of course! ZoneAlarm is even kind enough to place a nice little checkbox on their installation screen asking if you want to give your web browser unconditional access to the Internet. Perfect!

So I chose the web browser as the target. Now, how best to commandeer its use? Well, we could probably use some scripting language or ActiveX nonsense that got loaded up whenever you started the browser. But there had to be a better way...

Flashback: A long time ago I wrote a keystroke logger by using the Win32 function SetWindowsHookEx. This powerful function enables you to intercept many operating system operations such as windows messages being sent to all windows, all mouse movement and button clicking and (for the keystroke logger) all keystrokes. The most powerful feature of this function is that if you place your intercept function inside a DLL that DLL then gets loaded up with any subsequent application and is treated as being in the same process space as that application.

So I went the SetWindowsHookEx route. If I created a DLL that waited until it spotted itself being used by your web browser I could be assured that if I created a network communication channel at that point I'd be safe from detection because at that point in time I was in the process space of the browser and thus almost certainly trusted by the firewall. I could probably communicate out on the network using any TCP port but there might be some paranoid users who've set their firewall rules to only allow their web browser to talk over specific ports. But TCP port 80 was pretty much guaranteed.

The program I ended up with is called FireHole and checks in at a lumbering 13K (uncompressed). Actually this may seem rather large to some (not many!) programmers but it includes the program itself together with the DLL it uses contained as a resource and it extracts this when the program starts up. The program is really only about 7K and the DLL it gives birth to is about 5K.

Flash: Even though I had the program ready and running I was in no hurry to release details of it. I'd thought that maybe the computer security company I work for Foundstone, may have wanted to do something with it in the way of an advisory but I decided it probably wasn't worth the time or effort. A week or so ago I did mention the fact that I'd created a program that could defeat the outbound detection of personal firewalls over at the GRC newsgroups, causing quite a little stir. But while I was away doing "real" work, about a week later I again visited the GRC newsgroups whereupon I noticed a vociferous posting by Bob Sundling entitled "ZoneAlarm and LeakTest are a joke! :-( :-(". Coincidentally(!) he was proclaiming the downfall of personal firewalls with a demonstration tool available that used the system's web browser to transmit information without the knowledge of the user. Although beautifully simple in its approach and similar to my technique in that he used the web browser, that is where the similarity ended. I feel that my method is a lot more powerful and could be used in many different ways. For example if the DLL instead detected being used by the system's email client it could probably safely send out information on TCP port 25 (SMTP) undetected. The same goes for any other commonly used and trusted application. Likewise it is not limited in having to use the HTTP protocol and can send and receive any amount of data.

Click here to download firehole.exe (13K)

Using FireHole is quite simple. Run the program and you will be presented with a window containing a place to enter an IP address and a TCP port to use. By default it is set to talk to keir.net (66.39.30.176) on port 80. Make sure you are connected to the Internet and hit the Start button. This will launch your system's web browser. As soon as the browser has launched, the hook DLL automatically loads into the address space of the browser and the DLL will check to see if it recognizes the window text as a known web browser. If it does it creates a connection to keir.net and sends a small text message containing the currently logged on user's name, the name of the computer, a message claiming victory over the firewall and the time the message was sent. The message will look something like this:

Message from user "rkeir" on computer WIN2K [192.168.1.100] at 11/06/01 19:37:38
***** I have successfully bypassed the personal firewall! *****

Perhaps you think that this message contains too much personal information and is too revealing. Well just think what a trojan program using this technique could send! Files, private documents, passwords, credit card numbers...

You have my personal assurance that FireHole does not perform any other actions beyond those described in this article. It is NOT a trojan but a simulation of what a rogue program could be capable of.

Things to try

• To better simulate how a trojan would work you can choose to hide the web browser window while the program is working. Do this by checking the box at the top of the window. Of course a true trojan wouldn't even have this control window visible; it would be acting totally unseen in the background, commandeering your web browser to send and receive anything it chooses, all the while your personal firewall is saying "Ah, its just the web browser. No problem. I trust it".

• Maybe you'd like to see if you can bypass your firewall by sending the message to a different address over a different port. To send data over a different port to the standard 80 you will have had to have given your web browser permission to talk over any port. Most people are not savvy enough to have configured their firewall to allow their browser to only communicate over certain ports and it will probably succeed. Again, for this to work you will have to have another computer (not specifically trusted by your firewall) listening on the IP address and port you chose. A simple way to do this is to run a Netcat listener. Download Netcat here then run it from a command prompt on the target computer like this :-

  nc -vLp 6666

  In this example we are listening on port 6666. When/if FireHole sends the message you should see it appear in the target system's DOS window.

Why it may not work

Finally...

Addendum

"Of course it could be done in several possible ways so why waste the time..."

Robin Keir. 11/6/2001 9:03PM