Software Firewalls: Made of Straw? III

July 2, 2005

In part one and two of this article series we looked at how a personal firewall actually works and where it taps into the network stack to do its filtering. In part two we look at how easily the firewall’s operation can be circumvented by inserting a malicious Trojan into the network stack itself.
Fooling the firewall: LSP Trojan over port 80

Let’s look at one case where a personal firewall’s functionality can be circumvented. By inserting a malicious LSP (Layered Service Provider) into the protocol stack, a malicious application could effectively become a part of the protocol stack itself, able to borrow valid connections made by valid processes and ride on top of them, altering outgoing or incoming data at will. What a better way for an attacker to send commands to his Trojan, and receive its output, than simply opening a valid and legitimate connection to, say, a valid public HTTP server running on the target machine?

In order to accomplish this, all the attacker would need to do is implement a rogue LSP and insert it into the WinSock protocol chain. Just as any LSP, the rogue one will be able to see all legitimate network traffic going in and out, and alter it to meet its own purposes before passing it along the chain, or even choose not to pass it along. Even more interesting, it can also generate fake traffic and feed it to the lower layers as if the traffic came from a legitimate application. Or it could feed fake traffic to the upper layers as if it came from the network. Therefore, this becomes the perfect place for a man-in-the-middle attack.

Let’s consider the following example: we have a corporate network, properly protected by a secure gateway, that exposes a public HTTP web server to the public. The web server is fully patched and secured; it has a local software firewall that has closed all ports except port 80. Only the HTTP server process has permissions to listen on port 80. Now, say this machine becomes infected with a custom-made LSP level Trojan, or a modified version of an existing one such as Trojan.Riler.D or Daqa.A, which is set to piggyback on communications over port 80. Can an external attacker successfully communicate bi-directionally with this Trojan from the Internet?

The answer: a most definite yes. How? By using an ordinary browser request from the outside to the public HTTP server. Remember, network data is being viewed by the LSP Trojan on the server. Now, the attacker will initiate a connection to the HTTP server and send some HTTP requests, intermixing within the request an encrypted command to be interpreted by the Trojan (for example, the string “GET /index.htm HTTP%%givemeadmin%%/1.1″). The gateway will route the request to the server box, since it is a valid connection request on port 80. At the server, the local firewall’s packet filter will see a valid incoming packet belonging to an established connection, so it will let the connection through. At the TDI interface, the per-process filter will see this is a packet meant for a port in which there is a valid, legitimate process listening (the HTTP server), so it will also let it through. Inside the protocol stack, the LSP Trojan will analyze the packet’s data and recognize “%%givemeadmin%%” as a command to be acted upon. It will strip that part off the packet, and pass it along to the upper layers of the protocol stack. Meanwhile, it will do whatever the command means (perhaps, it may start cracking the password hashes stored in that computer).

When the packet gets to the web server, all it will see is the remaining part of a valid HTTP request: “GET /index.htm HTTP/1.1″. It will answer with the contents of index.htm, or it will give an error. Let’s assume the server replies “HTTP/1.X 404 Not Found”. It will send that error through the WinSock APIs, where our LSP Trojan will intercept it. The Trojan, knowing this is a “malicious” connection, will use this opportunity to send back whatever output it wants to (for example, the Administrator’s password once it has been cracked). It will insert its encrypted output into the server’s reply, before passing it to the lower parts of the protocol stack. In other words, the output will become something like,”HTTP/1.X %%thepasswordisGOD%%404 Not Found”. From here, the local firewall will see this is a valid process sending data to an allowed port for a valid connection, and will allow it, as will the gateway. The result? One very happy attacker, one very compromised network.

Naturally, this is only a simple example. A more complex example that involves hijacking a binary protocol instead (such as FTP or HTTPS), coupled with encryption of the Trojan’s data, would render detection incredibly difficult. Even with packet sniffing at a chokepoint in the network, the chances are very good that this form of communication would go undetected.

Finally, as abstract as the possibilities portrayed here may seem, they are very much practical, and are feasible in the hands of a skilled attacker. Available space in this article does not allow broadening the examples to a step-by-step discussion, but it should be clear that with this type of communication, no one product can offer absolute protection. There is no magical security solution; firewalls and anti-virus application are but tools to cover a very small portion of a very big hole. Especially in a corporate environment, where the rewards (and motivation) for an attacker are the greatest, nothing can ever be taken for granted.

A real-life example: IIS compromise results in a stealthy LSP Trojan installed

As we have seen, there are a variety of ways a skilled attacker can bypass conventional firewall technology. The weakest point here is that of the outbound filtering rules. The personal firewall simply ensures that a process is checked against existing processes currently running. If it matches up then it is allowed to egress the network. However that clearly leaves a gaping security hole when the aforementioned LSP Trojan comes into play.

We now describe a scenario in which a well protected network is breached. That will allow us to visualize just how weak most firewall technology really is. First, let us analyze the layout of the network that is attacked.

In our corporate network, there is the edge router as the first layer of security. This is where all ports except those absolutely needed are closed and other security modifications can be made. In this case, the admin has decided to disallow outbound ICMP messages from the router. Behind the router is an enterprise class Cisco PIX firewall. This firewall is placed behind the router so as to minimize its load.

Posted in WhitePapers