Network Intrusion Detection Signatures, Part Four
by Karen Kent Frederick
|Network Intrusion Detection Signatures, Part Four
last updated March 5, 2002
This is the fourth in a series of articles on understanding and developing signatures for network intrusion detection systems. In part one we discussed the basics of network IDS signatures and then took a closer look at signatures that focus on IP, TCP, UDP and ICMP header values. In the second installment we looked at some signature examples. In the previous article, we began to examine the topic of protocol analysis, which means that the intrusion detection system actually understands how various protocols, such as FTP, are supposed to work. In this article, we will continue to look at protocol analysis and how it can overcome attempts by attackers to obfuscate their exploits so that they cannot be detected by simple intrusion detection signature methods.
Protocol Analysis Review
Let’s quickly review what protocol analysis means. In protocol analysis, the network intrusion detection system (IDS) sensors examine TCP and UDP payloads, which contain other protocols such as DNS, FTP, HTTP and SMTP. The sensors understand how these protocols are supposed to work, based on RFCs and on real-world implementations of the protocols, and they can fully decode them. This allows a much larger range of signatures to be created than would be possible through simpler signature techniques. Some IDS sensors can only utilize “packet grepping” signatures, which do character-by-character or byte-by-byte matches within a TCP or UDP payload. Although packet grepping signatures are useful for identifying certain types of attacks, they lack the flexibility to identify many types of attacks. In particular, packet grepping signatures are typically unable to handle the obfuscation techniques that attackers often use to attempt to evade detection by IDS sensors.
In the previous article, we reviewed a simple example of how an attacker can attempt to obfuscate an attack through the use of extra white space. If an intrusion detection system uses a packet grepping signature that looks for the FTP “SITE EXEC” request, it will be looking for that exact match in the TCP payloads. However, most FTP servers ignore extra white space, so an attacker could place an extra space between “SITE” and “EXEC”, and the packet grepping signature would fail to make a match because of the space. Protocol analysis signatures would break the whole “SITE EXEC” command into its components, the command name “SITE” and the argument “EXEC”, making the extra white space irrelevant. This is probably the simplest way by which attackers obfuscate attacks; now let’s dig in and look at some more interesting examples of attempting to evade detection.
Another simple IDS evasion method that many attackers use is path obfuscation. The idea of this technique is to alter the path so it has a different appearance but the same meaning. This technique is most frequently used within URLs to hide HTTP-based attacks. Here are three of the ways that attackers commonly use to obfuscate paths. In these examples, we’ll assume that we want to alert whenever we see
Backslashes are substituted for regular slashes. Most Web servers don’t care whether backslashes or regular slashes are used to separate directories. So the Web server will treat the URL excerpts
Single-dot sequences, like
A slightly more complex technique utilizes double-dot sequences, such as
Of course, an attacker may mix and match these methods. She can use multiple instances of any of these methods within a URL, as well as using multiple methods in a single URL. For example, the attack could be hidden as
Protocol analysis is able to handle these techniques because it performs much of the same processing on URLs that a Web server or operating system does. When HTTP traffic is being monitored, the IDS sensor extracts the path from the URL and analyzes it. It looks for backslashes and single-dot and double-dot directories, and it handles them appropriately. After it has “standardized” the URL, it can then search it for likely suspicious directory content, such as
Hex encodings can be used to represent characters in URLs. You may have seen URLs that contain
Let’s use our
Double Hex Encoding
In September 2001, the Nimda worm spread throughout the Internet. It took advantage of a vulnerability that was named the Escaped Character Decoding Vulnerability, which involves double hex encoding. An attacker could craft a URL so that it contained special hex-encoded sequences. When a vulnerable Microsoft IIS server received a URL, it performed one round of hex decoding on the path in the URL. It performed a security check on the URL at that point, but afterwards performed a second round of hex decoding on it. Let’s look at an example from the Nimda worm to illustrate how this worked.
The Nimda worm used 16 different URLs to probe Microsoft IIS servers for known vulnerabilities, including the double hex encoding one. One example of the relevant part of the URL is
The final obfuscation method that we will look at in this article is Unicode (or, more correctly, UTF-8). This is another alternate way of representing characters and is most infamously known for being used for various HTTP-based attacks. When you first look at Unicode, you might think that you are really looking at hex encoding. For example,
An example of a URL path excerpt containing Unicode is
Now that we understand why handling obfuscation is so important, let’s look at an example of how we would make a signature for a particular attack. This signature will be composed not only of the de-obfuscation methods we have already reviewed in this article, but also on the other signature principles we studied in earlier articles in this series. Let’s go through the steps that the IDS sensor and signatures would perform to identify URLs that include
This is a great example of how intrusion detection, and protocol analysis in particular, is really done. What sounds like a simple signature – looking for
In this article, we have continued to examine the topic of protocol analysis, where network IDS sensors understand how protocols such as FTP and HTTP are supposed to work, and decode and analyze them accordingly. Protocol analysis-based signatures provide a superior intrusion detection solution, compared to other signature methods, because they can detect a much wider range of attacks, including known and unknown attacks. As we have examined in detail, protocol analysis-based signatures are also far more resistant to attackers’ obfuscation attempts than other signature techniques.
The next article in this series will continue to examine protocol analysis, focusing on the concept of stateful protocol analysis. Stateful protocol analysis is when protocol analysis is performed on an entire protocol session, and key attributes are tracked throughout the session. For example, the IDS sensor can pair a command with its corresponding response, and it can verify that commands are issued in the correct sequence. Stateful protocol analysis is an incredibly powerful signature technique that we will examine in depth in the next article.
Karen Kent Frederick is a senior security engineer for the Rapid Response Team at NFR Security. She is a graduate of the University of Wisconsin-Parkside and is currently completing her master's in computer science, focusing in network security, through the University of Idaho's Engineering Outreach program. Karen has over 10 years of experience in technical support, system administration and information security. She holds several certifications, including SANS GIAC Certified Intrusion Analyst, GIAC Certified Unix Security Administrator, and GIAC Certified Incident Handler. She is one of the authors of “Intrusion Signatures and Analysis", and she is a contributing author to the "Handbook of Computer Crime Investigation".
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.