by Israel G. Lugo, Don Parker
In http://www.securityfocus.com/infocus/1839 ">part one 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.
Connected the router we have the main switch, which in turn has several departmental switches, and in our case a quasi DMZ setup as explained below. Behind the firewall is the corporate web server plus a Microsoft Exchange server. Beyond that are normal workstations found in the various corporate departments, as well as their internal LAN servers.
The attacker has scanned this network and his results reveal that there are several ports open. Ports 22, 25, 53, 80, 110 are open, and presumably have services listening for connections. The next step our attacker takes is in to send one SYN packet only to port 80 in an effort to determine what operating system is hosting the web server. With the resulting SYN/ACK result, he can reasonably deduce that he is looking at an IIS web server by looking at the packets metrics such as TTL, Win Size, and other metrics.
The attacker has developed a tweak of an existing IIS exploit, which will result in system level access. Now the attacker at this point simply initiates the attack, and gets the desired system level access. It is here that the attacker sends over his LSP Trojan. Our attacker is not a fool, however, and he realizes his TFTP activity will be easily detected by an intrusion detection system if present -- however, this may be a chance he is willing to take. With the LSP Trojan and several batch scripts transferred, the attacker now has his Trojan in place. Though our attacker now has system level access to the server, it is far stealthier to communicate to it via the LSP Trojan to decrease the chance of detection at any point in the future. Stealth is of course a primary concern to a malicious hacker.
Remaining undetected - who's watching your IDS?
With this scenario in mind, and bearing in mind how an LSP Trojan works, the question we need to ask ourselves is: will the defensive measures in this network contain the attack? As we already know from the information we have discussed above, the firewall itself is woefully inadequate to protect against this type of exploit. However, the method of transfer would be detected as TFTP activity by any competent IDS out there today. The problem is that many of these other defensive appliances are rarely monitored. That is a sad but true statement in many cases. Furthermore, even when these appliances are monitored there is a strong possibility that the person who is reading the output does not have the requisite training, or knowledge, to understand the information they are seeing. In some cases, large networks receive hundreds of thousands of alerts every day.
The problem of an intrusion detection system going unmonitored, or misinterpreted is unfortunately an all too common one. Too many corporations invest in the technology yet do not invest in the human side of the equation to manage and monitor the equipment. In a standard corporate network environment the IDS would be placed at the main switch so as to parse all inbound and outbound traffic. This is standard practice. Much like the placement of the firewall, it is found behind the router itself so as to lighten its load.
So we have the typical problem of a malicious hacker communicating with a computer that he has compromised, and that activity sails clear past all of the defensive measures in place. The firewall doesn't see the malicious traffic and the TFTP transfer that showed up in any IDS wasn't properly monitored. The question now becomes, do we have a way of reliably detecting this communication between the hacker and the compromised computer? Sadly the realistic answer is no.
In this specific case our hacker is using a legitimate session that they have established, to both feed instructions and covertly receive their responses. Doing so they have neatly side-stepped the outbound filtering capabilities of the firewall. After all, the session has been established, and sitting in the middle of the TCP/IP stack is our little LSP Trojan helper doing his masterÂ’s bidding. The normal detection methods are in this case useless. It is not only the firewall in this case that has been rendered useless but now the IDS as well. Ideally the attacker has done some simple encoding of his command sequence through some of the means detailed above, so even looking at individual packets would not immediately reveal the Trojan's commands.
Detecting the attack
Now knowing in concrete terms a method of bypassing all of the security in place exists, the question that begs an answer is, just how do we detect this malevolent presence? This is a very good question for which presently there is no definitive answer.
If an attacker used a known and public LSP Trojan, it could very well be detected by an up-to-date local A/V scanner, assuming of course that that particular malware in question is found as a signature in the A/V scanner's database. However, in most larger corporate situations, the use of a public LSP Trojan by a skilled hacker would be the exception, rather than the rule. A skilled hacker is far more likely to create his own Trojan to suit his needs -- or modify an existing one just enough that it is not detected by existing signature-based A/V scanners.
In addition, it is entirely possible to write a Trojan so that it is very difficult to detect or, if the attacker is skilled enough, almost impossible. Using advanced methods, it is possible to create an executable without absolutely any uniquely identifiable signatures. A very skilled attacker can thus make A/V companies very hard pressed to devise a way of detecting his tools, even if they get their hands on a copy -- which in itself is unlikely, as the corporate attacker will usually code his tools specifically for the job at hand, and not give them out to the public.
Once again, we are back to the bigger issue of detection. The fact is that if a malicious hacker of sufficient talent targets a specific organization, in realistic terms that organization may simply be out of luck with any efforts to detect them.
This article highlights the ongoing trade-off between network security and network usability for users. It is possible, given enough resources and in-house talent, that one could write custom IDS signatures to take into account a fair number of high level stealth exfiltration attempts. Doing so, however, takes a lot of time and knowledge. It is not every organization that can afford to do so, let alone hire someone to educate them to the myriad of security circumvention techniques. The answer, as always, seems to be defence in depth. Not only does your organization need to have a standard firewall and intrusion detection system, you now need more layers. A promising technology is the intrusion prevention system (IPS). That, plus some promising research based on statistical analysis of packet flows, could make a big difference in the detection of such problems as an LSP Trojan.
What can you do once you're infected with an LSP Trojan? There are tools available for removing LSPs and disabling LSPs in various ways. However the reader must remember that the first step with dealing with the threat is not the removal process but rather one of detection, and therein is the problem with LSP Trojans.
There is no perfect, or magical solution to protect your networks from stealthy Trojans. Remember that a LSP-level attack is merely one example of an attack vector when other sophisticated attacks also exist, as mentioned in the first part of this article. All that a well-funded organization can do is to continue to layer their approach and the levels of security available on their network. And as always, administrators and users alike must stay as educated as possible. The firewall is not as impregnable as one might think.
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.