How to bypass your personal firewall outbound detection
Game Over: An exercise in futility
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 (18.104.22.168) 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:
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...
Things to try
Why it may not workThis program isn't perfect. It was written quickly just to prove a point, so if it fails to connect and send the message it could be for several reasons. If your firewall spots the transmission then it will be obvious that it hasn't worked. Maybe you have configured your firewall to always prompt you when your web browser start up, or maybe you even have it prompt you for every connection it makes. If you do this then you are certainly in the minority and are being extremely vigilant and careful. If your firewall does not spot the communication but the program claims not to have worked then perhaps it has not recognized your web browser.
Finally...I want to reiterate what I said right at the start of this article. This, and all similar techniques rely on a rogue program getting onto your system and executing. If you can stop this then you are safe. If you can't stop it then it is game over - the rogue program has your computer completely under its control. So keep your antivirus program up-to-date, keep your email client locked down with correct security zone settings, never open attachments that can contain executable content and maybe restrict the ports that your web browser and other commonly used applications can talk on.
AddendumFrom paragraph 4 above:
But wait, there more!...
For you techies out there:
FireHole In The NewsNewsBytes
Information Security Magazine
Robin Keir. 11/6/2001 9:03PM
[ Home | What's New | Software | Links | About | Email | Donate ]