Software Firewalls: Made of Straw? Part 1 of 2
2005-06-08
Article continued from Page 1
There are other methods as well. For example, the WinSock API, the set of functions the vast majority of applications use to access the network, is built upon a layered model that allows for third party extensions to be inserted between the application interface and the base network protocol. Such an extension can be added by implementing a Layered Service Provider (LSP), and inserting it into the LSP chain. An LSP is a standard Windows DLL that obeys certain design specifications, and has the specific function of being inserted in the WinSock protocol chain. In the WinSock model, all networking data goes through this chain, with each LSP being responsible for passing it along to the LSP immediately above (or below, depending on whether the data is incoming or outgoing), after having optionally processed or altered the data according to its own function. Quality of Service (QoS) is an example of one such extension, implemented as a LSP. The firewall's per-process filter could be implemented as an LSP, sitting inside the protocol chain and selectively passing data on to the rest of the chain or silently dropping it according to its own criteria.
The LSP method, however, is not the most thorough filtering solution, as it relies on applications using WinSock to communicate. To bypass the LSP per-process filter, a rogue application would just need to use a driver of its own to communicate directly with the protocol driver through the TDI, thereby bypassing WinSock. The first described method, wrapping the upper edge of the TDI itself, is a better alternative, as it works at a lower level.
The job of the per-process filter is to analyze communication attempts by applications. It will look at the process ID (PID) of the process attempting to send or receive data, and analyze its characteristics against the rule set, under a more or less complicated set of criteria, depending on the thoroughness of the firewall's per-process filtering implementation. The crucial question, of course, is to ask, "is the executable that generated this process allowed to perform the action it's trying to perform?". This is a matter of finding out the executable file from the PID, optionally performing a hash to verify the file's integrity against a known hash, looking for the file in the rule set, then checking if it is allowed to perform that action or not.
Problems with per-process filtering
There are concerns with this implementation, however. For example, it would be desirable to check whether the process has any modules (DLLs) attached, and if so whether these modules are supposed to be there or not. This makes sense since the code in attached modules will execute from within the context of the process they are attached to, so if an illegitimate process attaches EVIL.DLL to good process X, good process X will in effect be running the code from EVIL.DLL along its own. The solution for this requires enumerating the loaded modules, finding their image files (path and filename of the attached DLLs), then checking against a table of modules allowed to attach to that process. Firewalls often check for this and ask whether to allow the module; but obviously this is only a placebo in a sense. The firewall can't possibly know all possible present and future DLLs, good and bad, that might exist, and therefore it is up to the user to guess whether a given DLL is good or not. Yet another concern is whether the process has had its code altered in memory (a process can alter another process' memory region, changing it's code on the fly to alter its behaviour). Or if the process was launched by a malicious program (which would also allow the malicious program to alter the process' behaviour). And the list goes on.
Only a few of these problems are adequately addressed in today's firewalls. The truth is there are simply too many ways for malicious code to disguise itself in order to fool a software firewall's process filtering, ranging from the simple to the very complex. An illegitimate process could patch another legitimate process in memory. It could take advantage of a legitimate program's behaviour, for example by launching a browser with a command line telling it to load a given malicious page. Even in the advent of the process filter scanning for parent-child relationships, multiple levels of indirection could be used (the illegal process could launch cmd.exe with a command line telling it to launch another cmd.exe, which will then launch the browser with the intended page). Or the rogue application could adopt aggressive tactics against the firewall, disabling it altogether, faking mouse clicks to click through the alerts... Remember, anything the user can do, a program can do for him (within this context, obviously).
And all of the above is just focusing on fooling the per-process filter. A whole other world of opportunities opens up when the attacker realizes he doesn't even need to go through the process filter at all. Remember, below the process filter, information about processes is lost. Information just becomes data coming in or out of the machine, and that is as it appears to the other filter, the packet filter. All the attacker has to do is use a driver to inject the packets below the level where the process filtering is being done, and then he only has to worry about the packet filter. As long as he uses an already allowed port (say port 80, 25, or whatever), the packet filter will happily allow it. Not even to mention the possibility of just going under the packet filter...
Conclusion
In this article we've looked at how a software firewall actually works, by implementing both a packet filter and a per-process filter. We also looked at the problems with this approach, and how the per-process filter in particular can be tricked into allowing malicious code access to the network anyway. Next time, in the second and final part of this article, we look at ways of circumventing a software firewall's modus operandi altogether, effectively making the firewall look as if it were made of "straw."
