Get a MacBook Air with Online Courses Now

Intrusion Detection FAQ: Are there limitations of Intrusion Signatures?

Matthew Richard
April 5, 2001

Introduction
Many corporate networks and corporate security policies rely heavily on intrusion detection to alert administrators of intrusion. With all of the features of modern intrusion detection systems there are some tragic flaws inherent in their design. These weaknesses apply to Snort and all other signature based intrusion detection engines. Snort is singled out in this paper because of its popularity and its familiarity amongst the SANS community.

What is Snort
Snort is an intrusion detection system written by Martin Roesch. Snort is was written as an open source project and is available for free under the GNU public license. The software is based upon a signature comparison engine optimized for speed. Snort offers many features that make it an ideal choice in the battle against Internet intruders. Here is a description of Snort from the Snort website:

Snort is a lightweight network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilizes a modular plugin architecture.

The power of Snort
Snort was written to take advantage of a highly modularized design. The application can take advantage of several different pre-processors to normalize, filter, and categorize data. Snort also has very powerful post-processors, or output plug-ins, that can be used to log the data generated by Snort in several different ways. Because Snort is an open source project and that it has many users its signature database is updated often and are simple to update.

How Signatures Work
Understanding how signatures work is essential to understanding how to defeat them. When Snort is given an incoming packet from the packet capture driver it compares that packet to its database of known signatures. The signature has some key aspect of the packet that it is compared against to look for a match. If a match occurs than Snort sends the output to a standard output mechanism or to one of the configured post-processor output plug-ins. For example if Snort received the following packet then it would compare it against its database:

03/21-13:02:34.978853 10.1.114.88:1272 -> 10.1.114.220:54320

TCP TTL:128 TOS:0x0 ID:48408 IpLen:20 DgmLen:44 DF
******S* Seq: 0x2BC3D9 Ack: 0x0 Win: 0x2000 TcpLen: 24

TCP Options (1) => MSS: 1460

and match it to rule:

alert tcp $EXTERNAL_NET any -> $HOME_NET 54320 (msg: "BACKDOOR SIG - BO2K";)

This event would trigger an alert message. Most signatures do not just look for what port a packet is to or from, but it also examines part of the payload. As new security holes and exploits are found new signatures are written to counteract the danger.

The problem with signatures
What Snort and other signature based intrusion detection systems count on is that malicious traffic will have unique patterns to it that can be matched against rules in the database. For example Snort uses the following rule to look for the SubSeven Trojan:

alert tcp $EXTERNAL_NET any -> $HOME_NET 27374 (msg: "BACKDOOR SIG - SubSseven 22"; flags: A+; content: "|0d0a5b52504c5d3030320d0a|"; reference:arachnids,485;)
alert

The important part of this rule to note is that Snort is looking for the hex signature "0d 0a 5b 52 50 4c 5d 30 30 32 0d 0a" that is located anywhere in the payload of the packet.

It then seems obvious that there are many ways of circumventing this signature. The first thing that we could do is vary the destination port. This is usually undesirable though since the infected machine is probably using the default port for SubSeven to make it easier to scan for. If the attacker knows what port SubSeven should be running on then they could quickly and easily scan large blocks of addresses for machines listening on that port. The next evasion technique that an attacker could use would be change or scramble the content that the sensor is looking for. This could be accomplished by using some very simple form of encryption. Here is how a simple packet encryption might work:

1st byte of the packet payload is the value to be added to every subsequent byte. If we use 3 then our payload of "0d 0a 5b 52 50 4c 5d 30 30 32 0d 0a" becomes "31 3d 8e 85 83 7f 81 63 63 65 31 3e" which does not mach any of the known signatures. The attacker has now evaded our intrusion detection system. Another twist of this technique could incorporate public key/ private key encryption. The private key for the server and the public key for the client could be sent or bundled with the original install. This would render all communication between the 2 hosts unintelligible and undetectable by intrusion detection systems.

How did that go again?
New techniques are also being developed to change how the executable code that runs Trojans and other applications looks. As reported in a recent ZDNET article:

During a seminar last week at the CanSecWest conference in Vancouver, British Columbia, a hacker named "K2" revealed a program he created that can camouflage the tiny programs that hackers generally use to crack through system security.

According to K2 himself, "This is a way to keep the exploits brand-new, all the time." This raises the possibility that there is not enough time to update the signatures for an IDS as the signatures change. Already freely available to hackers are tools to "repack" the executables that they use. This repacking changes the executable so that it is no longer recognizable to anti-virus and intrusion detection engines.

Attacks on services
Snort and other intrusion detection systems do excel in detecting attacks on services that require an exploit that cannot be encrypted. Attacks like this would include buffer overflows, directory traversal, and scanning attempts. These types of attacks rely on existing flaws within the victim machine. These flaws can typically only be exploited using a certain attack mechanism that will have a certain signature. In these cases signature based intrusion detection does very well at detecting these patterns and alerting or stopping them.

The problem with intrusion detection as it relates to attacks on services is that it may take some time for a new exploit to become known. After the exploit is known then a new signature can be written for it and distributed. This leaves many systems vulnerable to unknowing attack for a certain period of time. It is possible that a well-executed attack will leave no trace of intrusion thereby rendering all of the effort placed into intrusion detection wasted. IDS are also hurt by a lack of supporting data for attacks that were not immediately recognized. The author of Stick, Cortez Giovanni says:

Also, most IDS do not start recording an attack until an alarm is triggered. This means that the original flaw that allowed access will not be recorded. Some IDS buffer that data, so that the IDS will have the last X number of bytes before the alarm to see what occurred before it. Regardless, IDS do not usually record packet in great detail due to the recording requirements on IO and remote management.


Denial of Service
Although denial of service attacks are typically associated with individual machines or networks, it is also possible to apply denial of service techniques against signature based intrusion detection systems. Jerry Marsh states one such possible technique in an article he wrote:

many NIDS systems work by alerting someone when suspected exploits are happening. As was demonstrated at the October 2000 Monterey SANS conference, this can be thwarted by information overload. In this example the attacker created so many "noise" attack attempts that people watching for attacks were overloaded. The real attack was injected in the middle of the noise and completed before it could be determined what the real target was.


This is just one method of implementing a denial of service attack against an intrusion detection system.

Another possible method of implementing a denial of service against an IDS would be to exhaust the resources of that IDS. This denial of service would flood the IDS with traffic that will generate alerts until the IDS runs out of resources. This would cause the IDS to have an incomplete log of the events that took place. Here is the post of an author who claims to have written a tool to automatically overwhelm IDS systems.

The tool uses the Snort rule set and produces a C program via lex that when compiled will produce an IP packet capable of triggering that rule from a spoofed IP range (or all possible IP addresses) into a target IP range. A function is produced for each rule and a loop then executes these rules in a random order. The tool currently produces these at about 250 alarms per second. A Linux based snort will hit 100% CPU and start dropping packets. The stress on recording and disk IO is another problem. ISS Real Secure dies two seconds after the attack begins. This was tested numerous times. Other IDS and even sniffers (especially with DNS lookups) had problems of their own.


Conclusion
Although signature based IDS do provide a useful service to let an administrator know that he/she has been or is being attacked they should not be relied upon. It is far too easy to fool or shut down an IDS machine for them to be utilized as the primary line of defense against intruders. Some recommendations that have been given by Lawrence R. Halme and R. Kenneth Bauer in their article "AINT Misbehaving: A Taxonomy of Anti-Intrusion Techniques" are to use the following practices in conjunction with intrusion detection:

  • Prevention
  • Preemption
  • Deterrence
  • Deflection
  • Countermeasures
Intrusion detection should be part of a defense in depth strategy and no single tool or technology should be relied upon exclusively.

References
[1] Srisuresh, P. and M. Holdrege. "IP Network Address Translator (NAT) Terminology and Considerations." RFC 2663. August 1999. http://www.geektools.com/rfc/rfc2663.txt (20 Mar. 2001)

[2] "What is Snort." http://www.snort.org/what_is_snort.htm (2 Apr. 2001)

[3] Lemos, Robert. "New cloaked code threat to security." April 2, 2001. http://www.zdnet.com/zdnn/stories/news/0,4586,5080532,00.html (3 Apr. 2001)

[4] Marsh, Jerry. "Myths Managers believe about Security." January 25, 2001. http://www.eurocompton.net/stick/ (2 Apr. 2001)

[6] Halme, Lawrence R. and Bauer, R. Kenneth. "AINT Misbehaving: A Taxonomy of Anti-Intrusion Techniques." http://www.sans.org/resources/idfaq/aint.php (2 Apr. 2001)

[7] Posting on Snort users mailing list by Cortez Giovanni.