A look into IDS/Snort part 3 of 3 by QoD

Well this article was featured in the Antionline newsletter 11 but i decided to post it here as well, because some people do not know where on the world it is, any ways lets dive into this article (tutorials whatever you wanna call it).

------------------------------------------------------------------------------------------------------------------------------------

A look into IDS/Snort

By: Q.o.D
<[email protected]>
Januray, 7th 2004


Introduction:

Over the years IDS has gained popularity amongst organizations, with the rise of security risks, we needed a methods of detecting and possibly stopping intrusions. Last year alone (2002) we were hit with many viruses which could have been avoidable. In this paper we will discuss some of the concepts behind IDS, an infant technology that till recently has saw demand in businesses.


Disclaimer and Copyright:

Copyright © 2004 , 2005 Q.o.D <[email protected]>
This document is free software; you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.



PART III


Introduction:
In part II you saw some of the basics of Snort, what it offers, and why do people prefer it. In this part we are going to talk about some of the challenges of IDS especially NIDS. Techniques described here are general, and most ID systems should have found ways to stop them.


3.1 Architectural problems with NIDS

Many problems face IDS, and were mostly discussed in the disadvantages of NIDS in part I. We will be focusing some more on these ways, and discuss ways to fix the problems.


3.1.1 Switches

Switches work by making each port act as its own network segment, so if you send something to PC1 it is not going to send to PC2. This is much different and effective than the hubs, that is why switches are sometimes called intelligent hubs. This is a problem for NIDS that rely on sniffing the network, the reason is that if you put the sniffer on a port on the switch it will only see packets sent to it, and nothing else. There are two main ways to go around this problem:

1) Using spanning ports
Some of the high end switches currently have SPAN ports on them. Span ports are port that are a mirror of the traffic passed through the switch. As you see in the following exhibit:



2) Installing Taps or Hubs
Similar to the concept of telephone taping implemented by the FBI, taps take all the traffic from the wire before it even goes to the switch. Hubs could be used as taps, as in the following network:



Both solutions have disadvantages. For example using span ports degrades your switch's performance dramatically, and getting the switches could be costly. Hubs on the other hand are half duplex so implementing a hub as you tap will slice your network performance by 50%.


3.1.2 Fast Ethernet

Gigabyte and 10 Gigabyte Ethernet are not a dream now, and many people are starting to use them. Because of the NIDS architecture, and the way it has to pickup each packet and analyze it, Gigabyte or 10 Gigabyte networks could be nearly impossible to Handel by an out of the box IDS. The only way for the NIDS to function at such high speeds is by tweaking it to your network's need, and follow the steps outlined in the reduce false positives section. One thing to note is that a properly configured Snort IDS will be able to Handel 1 Gigabyte Ethernet almost no problems.


3.1.3 Encryption

Since NIDS function at such a low layer (network) they have no means of decrypting or understanding encrypted packets. Therefor encrypted attacks are never detected by the IDS. The best way to combat this is by installing a HIDS on important machines that are commonly attacked such as web servers, or by installing the encryption keys on the NIDS itself so for every encrypted packet it would decrypt it and then check for a signature match.


3.2 Evading the IDS

Evasion is a technique that eludes the IDS from detecting a real attack, and thus rendering a false negative, thus defeating the purpose of implementing an IDS in the first place. Evasion techniques work by making the packet appear not to match an attack signature (while in fact it is the attack), and thus fooling your IDS. Although there are some evasions that work against HIDS we will be mostly focusing on NIDS since they are more popular. Some of the techniques that are described here have been presented in a paper called "A look at whisker's anti-IDS tactics" written by Rain Forrest Puppy(RFP) which is available at his website at www.wiretrip.net/rfp. The techniques are also implemented by a CGI vulnerability scanner program by RFP called whisker (discussed later). Although we are not going to talk about how to use the tools, I would heavily recommend that you test them against your IDS, if your IDS is deceived then it might be time to update or switch to another IDS since these tools have been around a while. We are also not going to discuss each and every commands, but rather some of the common and effective ones.
Throughout the examples we will be showing you multiple ways that an attacker could evade the following rule (signature):

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS /etc/shadow access"; flow:to_server,established; content:"/etc/shadow"; nocase; sid:1372; classtype:web-application-activity; rev:4;)

Which basically says to alert when a request for the /etc/shadow file comes from an external network to the web server on http ports. The reason we chose this rule is because not only it is simple but also is a common file that an attacker will go after.


3.3 Evasion through URL

We have all heard about the traversal attack against IIS, these are common attacks against unpached web servers. These evasion are problematic to NIDS in particular because NIDS operate at the network layer and does not make much sense of the application layer or how the target machine will interpret the attack. If you do not understand how HTTP requests work, here is an overview from "A look at whisker's anti-IDS tactics" by RFP (www.wiretrip.net/rfp):

It is important to understand the components of an HTTP request. As defined by RFC 1945:


1. The method of request; typically GET, HEAD, POST, etc. Indicates what data format the server should expect and provide.
2. The URI, which is otherwise the page you are requesting. It can be relative ('/some/file') or absolute ('http://server/some/file'). Sometimes referred to as URL, but URL typically denotes an absolute URI (includes scheme--ftp:, http:--as well as server name).
3. The version, which is always in the format of "HTTP/x.x". Common versions are 0.9, 1.0, and 1.1. v0.9 is otherwise known as "simple requests".
4. All three components make up a 'request'. Each component is separated by a space.
Most IDS vendors currently are not fooled by these kinds of evasions, Snort for example has a preprocessor called HTTP_decode to deal with these kinds of evasions.


3.3.1 Self referenced directory

This technique is quite simple, in its simplest form it would look something like this:

GET ./././etc/./././shadow HTTP/1.0

Because the signature will not match the attack GET /etc/shadow HTTP/1.0 the attack will pass undetected by the IDS.


3.3.2 Reverse transversal

By using the same idea as the transversal attack. Attacker found out that by going into a directory and getting back out they would be able to evade the IDS. The attack evasion would look something like this:

GET /etc/kevin/../john/../shadow HTTP/1.0

The directory could be anything, even none existing directories will work. Keep in mind that this could go on just going into a directory and out forever.


3.3.3 Long URL

Most ID systems have some sort of a maximum limit that a packet could be kept in memory, when that quota goes beyond the limit then the packet is discarded. Long URL functions by making the attack go beyond that maximum limit. For the sake of brevity i will not put an entire evasion but rather a stopped down version on what it would look like:

GET /etc/wade/../museum/../walkingetc.../shadow HTTP/1.0

This attack would be as long as the attacker wants it to be, but usually they will send the attack long enough to evade most ID systems.


3.3.4 Double slashes

Since it is introduction HTTP has undergone many changes, and by far has become on the most popular protocols in use. Because of this popularity, many diversities have occurred. Web server take input that were never defined by any standard. This popes a great challenge for IDS as they will not know if a packet is an attack or just a user not knowing what he is doing. One of the many inputs that web servers accept is double slashes in place of a single slash. So although // would look different from / , they will be both interpreted the same way by the web server.

GET //etc//shadow HTTP/1.0

Triple slashes could also be used

GET ///etc///shadow HTTP/1.0


3.3.5 Extra spaces

Putting an extra space between parameters sometimes would fool the IDS

GET /etc/wade/../themusium/../walkingonthestreetwhenimetyou/../shadow HTTP/1.0

Note: There are two spaces between GET and /etc/shadow


3.3.6 Tabs

Just like IDS are sometimes fooled by extra spaces. They are also sometimes evaded by using tabs instead of spaces.

GET /etc//shadow HTTP/1.0

Note: There is a tab between GET and /etc/shadow


3.3.7 \ (Backward slashes)

*nix bases OS use forward slashes(/) when representing directories, the Internet also uses /, but Windows does not use forward slashes, instead they use backward slashes(\). Web servers such as Microsoft IIS Server will accept backward slashes instead for forward ones.

GET \etc\shadow HTTP/1.0


3.3.8 Case sensitivity

Web servers interpret both the words WiLL, WIll, and will the same, while ID systems sometimes do not. You might be able to evade the IDS using this method.

GET /ETc/shADOw HTTP/1.0


3.3.9 URL encoding

Many people from around the world use the Internet, and most of them do not speak English. The web offerers such language to coexist on the Internet by using a universal language such as Unicode. Attackers found that by changing some of the letters or numbers of the attack to there equivalence of ASCII or Unicode they could successfully evade the IDS.

GET %2f%65%74%63%2f%76%68%61%64%6f%77 HTTP/1.0

This attack is the same attack as GET /etc/shadow HTTP/1.0 in ASCII format. And since there are multiple ways to encode each letter (usually 4 or more) an attack would be able to find at least 1000 ways to present the attack to the target system, this is not counting Unicode.


3.3.10 Other evasion techniques

There are many other evasion techniques that are not discussed in this paper, here are just some that you might find interesting for research:
1) Padding
2) Parameter hiding
3) Premature URL ending
4) Fake parameters
5) Null method
6) Session splicing
You could also use any of the previously discussed evasions with each other.


3.4 Whisker

Whisker is one of the very few tools that use evasion techniques in there scans, lets take a moments and ask what is whisker. From the whisker README:
“
What is whisker?

The primary purpose of whisker is to be a URL scanner, which is used to search for known vulnerable CGIs on websites. Whisker does this by both scanning the the CGIs directly as well as crawling the website in order to determine what CGIs are already currently in use.
“
Whisker is officially listed as deprecated, and RFP suggests that you check out tools like Nikto (www.cirt.net/code/nikto.shtml). Other tools that actually make use of whisker is Nessus (www.nessus.org) which has an option (through the libwhisker) to try to evade the IDS in its scan by using some of the ways described before.


3.5 Denial of Service (DoS)

Denial of service attacks serve mainly focus on two weaknesses in IDS.
1) The human factor
Some tools designed specifically to DoS IDS do that by generating tremendous amounts of false positives that the administrator cannot handle. Think about getting 20K of alerts each day, you will not be able to go through each one of them and analyze them carefully. They also work by burring the real attack between those false positives and thus masquerading the real attack. The disadvantage in this method is that the attack is somewhere in the logs, but it might take some time to find it.
2) The IDS it self
DoSing the IDS it self on the other tries to take the IDS off line by flooding it with too much false positives. This would cause the IDS to run out of memory, or run out of disk space all that would ultimately lead to an IDS crash. Some also try to keep the IDS busy with too much false packets that the IDS will start dropping any new ones and thus making the attack pass by undetected.
There are two tools that currently do just that.


3.5.1 Stick

From the http://www.eurocompton.net/stick/projects8.html:
“
Stick - This is an IDS stress tool used to evaluate the bottle neck point in an IDS in an operational environment. Stick will not be released anytime soon for the exception of IDS vendors.

During testing it was discovered that ISS Real Secure v5.5 would turn itself off via error. I have sent the code to ISS (Chris Rollard) via a friend to insure that it went to a knowledgeable group in ISS. I have on my own accord contacted other vendors, some of which are not affected by this technique.

Over the last couple months I've been finishing up work on stick. I was planning to release a paper in the coming week and the tool in a month or two from now when IDS vendors have had time to make modifications to handle it.

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.
“


3.5.2 Snot

from the Snot README:
“
Snot is an arbitrary packet generator, that uses snort rules files as its source of packet information. It attempts at all times to randomize information that is not contained in the rule, to hamper the generation of 'snot detection' snort rules.
It can be used as an IDS evasion tool, by using specific decoy hosts, or just something to keep your friendly IDS monitoring staff busy.
It has been tested to run on *BSD, Linux, Win2k, NT4.0 and Win98.

Snort 1.8 has stream4 tcp state code. This will defeat TCP attacks with single packets. Use UDP or ICMP rules instead for the moment :)
“

So is Snort vulnerable to these type of attacks, yes and no. From the Snort FAQ
“
1.9 Is snort vulnerable to IDS noise generators like "Stick" and "Snot"?

It is now possible to defeat these kinds of noise generators with the (see FAQ 3.17) preprocessor. Even without the stream4 preprocessor enabled, snort will weather the alert storm without falling over or losing a lot of alerts due to its highly optimized nature. Using tools that generate huge amounts of alerts will warn a good analyst that someone is trying to sneak by their defenses.
“


3.6 Fragmentation

Although we are not going to talk about this type of evasion in this paper we will just introduce the idea. Fragmentation is when a big packet gets chopped up(fragmented) into smaller ones. Each Fragmented packet contains a sequence number to be assembled in the correct order. Fragmentation occurs naturally on every network, but sometimes they are used to hide the attack. Take this for example.



When this attack is sent the IDS will see RCAKTA which does not match the real attack ATTACK. There are some tools that automate that for you, the best and well known fragroute is one of them. Also note that in Snort the frag2 preprocessor handles fragments.


Looking at the above examples and the many ways that IDS is challenged you might have a second thought about implementing IDS on your network. If your IDS is implemented correctly you should not worry or run in any of these problems.





--------------------------------------------------------------------------

neat PDF copy is attached