We have all heard about the never ending series of computer compromises occurring on a daily basis. While the Intrusion Detection System likely picked up the attack, what about those compromises that the IDS did not pick up?
Outbound filtering signatures
For those of us who are lucky enough to do what we love i.e. work in computer network security, there is one inescapable truth. You will likely have your network penetrated at some point or another. Playing defense like we do is never all that “sexy” like the malicious hacker who seems to get all the press in newspapers and online e-zines. Well, where the malicious hacker only needs to be lucky once, we on the other have to be working at peak efficiency every day. Like the saying goes “defense wins the game every time”.
There is an article series that I wrote a little while ago which shows you how a semi-skilled hacker might operate. Though that setting was a malicious hacker attacking home users, the same could easily happen to a corporate network. In reality there is far more for the attacker to gain by targeting the corporate network. This could be a corporate spy who is trying to pilfer some proprietary data or other valuable information. What do all these attackers have in common though? Well most of them will always target a service which is then required to have a port open on the firewall, as well as the router.
What that open port on the router/firewall is, simply put, is an open door. While we may have the best defenses put in place, and also have them layered, there is always that most fearsome of opponents i.e. the truly skilled hacker. Is there anything that you can do to defend yourself from this digital Samurai? Yes there is actually! While an attacker may be very clever, they will almost always leave some residue behind them. By that I mean the attack will almost always be visible at the packet level. Typically your IDS will have flagged this buffer overflow, format string, canonicalization attack, … for what it is. Even if the attack was obfuscated enough to bypass the IDS by say fragmenting the exploit, something will happen afterwards. That something is generally predictable.
What do I mean by “something” and it being predictable? Well let’s think about what the “end state” of a hack is. Typically the attacker will want to get a DOS prompt through which to run arbitrary commands on the victim computer. Preferably at the SYSTEM level access as well. Realistically this is done via what is called a “reverse shell”. What that means is the now victimized computer will send a cmd.exe shell back to the hacker’s computer. There is also what is called the forward shell. This is where the hacker would themselves connect to a waiting socket on the victim computer. Of the two, the reverse shell is preferred simply because it will bypass many firewalls outbound filtering rules.
What’s your point?
You may be asking yourselves just what the heck does all of the above have to do with writing egress filters for your IDS? Well it has everything to do with it actually. To defend effectively you must be able to anticipate what an attacker may do. Like I have said before and I will say again “to defend you must know how to attack”. By knowing what an attacker may do when they have compromised a computer you will be able to defend against it. Specifically, you will be able to write effective outbound IDS signatures. You really should assume that you will eventually be suffering from a network breach and begin putting in effective counter-measures.
Now as I mentioned above the “Holy Grail” of most hacks is to obtain a shell by which to control the victim computer. Well being a win32 world (Windows NT, 2K, XP, K3) we know what a DOS prompt looks like. Seeing as most high end exploits result in remote code execution that is done via the DOS prompt, we can write our first egress filter. Hopefully you will have read the article series that I hyperlinked you to above. In that you will see several screenshots which show you what we will be basing our outbound signature on i.e. c:\
The “c:\” is something that you will definitely see exiting your network if a machine has been hacked. Quite often though you will see a variation of the “c:\”. Seen again in the same article series is another outbound signature that we can write i.e. c:\winnt\system32>
This signature is also another one that should be written. Also include variations of it such as simply c:\winnt. What about other activity though? Can we write ourselves some other signatures based on predictable hacking activity? Absolutely! By having learnt how to attack our very own networks in a controlled environment we know that there is one key thing that must happen right after a system breach.
Hackers largely predictable
The “modus operandi” of hackers is largely predictable simply because the goal of the hack is almost always the same. Once on the computer they will now largely start to transfer over their “survey kit”. What’s in a survey kit? Well typically in a survey kit you will see a command line port scanner, a keylogger, a packet sniffer, and other mission specific tools. So with this transfer over of tools to the compromised computer we must ask the question of how is it done? Well unlike Science Fiction where you would “beam over” your survey kit the hacker will almost always use one of two methods. The first one would be done via the use of TFTP, and the second one through the use of FTP.
11:36:37.171875 IP (tos 0x0, ttl 128, id 314, offset 0, flags [DF], proto: TCP (6), length: 74) 192.168.1.104.1046 > 192.168.1.107.4321: P, cksum 0xa4e0 (correct), 2690682812:2690682846(34) ack 1194520483 win 64138
0x0000: 4500 004a 013a 4000 8006 7550 c0a8 0168 E..J.:@…uP…h
0x0010: c0a8 016b 0416 10e1 a060 8fbc 4732 efa3 …k…..`..G2..
0x0020: 5018 fa8a a4e0 0000 7466 7470 202d 6920 P…….tftp.-i.
0x0030: 3139 322e 3136 382e 312e 3130 3720 4745 192.168.1.107.GE
0x0040: 5420 6578 616d 706c 650a T.example.
You will have seen throughout a lot of my articles based on hacking that I have used TFTP to ferry over my “survey kit”. This usage of TFTP via a TFTP server leaves a nice trail of residue for us to write a signature on. We can see that in the packet I have included above, the “tftp” is clearly visible, and something you can easily write a signature for. The same can also be said for FTP as well. Typically FTP will be used via an “anonymous” login, or if the hacker is smart they will have setup an FTP server on another hacked computer and password protected entry to it. So beyond the ASCII letters to key off of we can also write into the signature the outbound ports that are typically associated with these two services i.e. UDP port 69 and TCP port 21.
Loose or tight?
My one biggest complaints about vendor supplied IDS signatures is the “looseness” of them. The vendor wants to write a signature that is broad and hopefully will catch the exploit and perhaps variants of it. Well that is a laudable goal, however it also results in a boat load of false/positives. I would highly suggest that you write tight signatures and compensate by writing tight variations of them. This will help you cut down on those hated false/positives. One last piece of advice I would give is to also write signatures for all of the high end trojans out there. Trojans such as Optix-Pro amongst others. Many of them come with default ports written into them, and often attackers will not even bother to change those.
Conclusion
As you can now see there is a lot more to IDS’s then inbound signatures. There is a lot you can do with egress filtering in an effort to further harden your network. Well that is it folks, and as always I welcome your feedback. Till next time!
