Software Firewalls: Made of Straw? IV

July 2, 2005

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.

Summary

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.

Posted in WhitePapers