Snort Lab: Blinding IDS

IDSs and IPSs can be attacked by generating false positives. If you can generate enough false positives, you can potentially:

• Overwhelm the IDS console tool that collects alerts, forcing it to miss legitimate alerts
• Overwhelm the IDS sensor, forcing it to drop packets
• Overwhelm the system resources of the target device/OS
• Overwhelm the IDS Admin with a hail of false positives
• Hide a real attack amongst thousands or millions of false positives

Let's review what an IDS like Snort does, from the snort.org website:

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

To attack Snort or any other IPS, we can use a tool called sneeze. Sneeze was actually developed by a group of malicious black hat hackers called PHC (Phrack High Council). The released the tool, along with some files from a compromised Unix box, from snort.org in early 2004. Much of what PHC has released is offensive and immature, (warning, if you do decide to read any of the PHC released material, be it is highly derogatory and offensive) but the sneeze tool is a valuable tool for attacking IDSs.

Sneeze is the exact inversion and opposite of Snort. Snort wants packets. Sneeze's job is to send millions and millions of them.

Let's take a look at an example rule file, taken from the snort.org website:

BACKDOOR w00w00 attempt Signature

alert tcp $EXTERNAL_NET any -> $TELNET_SERVERS 23

(msg:"BACKDOOR w00w00 attempt"; flow:to_server,established;

content:"w00w00"; reference:arachnids,510; classtype:attempted-admin;

sid:209; rev:4;)

Summary: w00w00 is a Trojan Horse utilizing Telnet. This event is generated when an attacker attempts to connect to a w00w00 server using Telnet.

Impact: Possible theft of data and control of the targeted machine leading to a compromise of all resources the machine is connected to. This Trojan also can delete data, steal passwords and disable the machine.

This rule states that the data must occur over an open (established) TCP session. The traffic must be sent to one of the telnet servers. TELNET_SERVERS is a snort preprocessor definition which is defined in snort.conf, and is typically defined to be $HOME_NET. The data must be flowing "to_server." The data packet must also contain the string "w00w00." This rule is so simple we could just telnet to the server and type "w00w00" and trigger the snort rule if it's set.

There's not much to this. Let's look at one last example before we get into the code. This example is more complex:

RPC mountd UDP export request

alert udp $EXTERNAL_NET any -> $HOME_NET any

(msg:"RPC mountd UDP export request"; content:"|00 00 00 00|"; offset:4; depth:4; content:"|00 01 86 A5|"; offset:12; depth:4; content:"|00 00 00 05|"; distance:4; within:4; reference:arachnids,26; classtype:attempted-recon; sid:1924; rev:4;)

We have multiple fields to keep our eye on. Here the packet contents are offset by '|' so we know that the result will be packed as a hex string. Hex strings can be 1, 2, or 4 bytes, depending on whether or not there are 2, 4, or 8 adjacent hex string bytes. For example, 03 is one hex byte, 00003 is a short hex word, etc. The offset field denotes what offset from the start of the packet the specified (byte) string will be found at. After an initial match, the "within" keyword specifies a minimum number of bytes from the last match that the current match should be found within.

Here is a partial list of keyword sneeze won't parse:

• Preprocessors such as HTTP decode,
• Keyword directs such as Icmp_id

Since the Snort rules give vague notions of how data should be arranged in a malicious packet (apart from the fixed fields specified by the "content" directive), sneeze can easily create a polymorphic engine which can repeatedly send all sorts of fake snort triggers, with randomized data content and data lengths.

In order to run sneeze, you must first determine which ports are open on the target machine. Sneeze requires that a port be open on the target in order for it to complete the sending of the false attack. Now, you need to match a listening service with a snort .rules file. Each snort rule will only trigger an alert if the traffic comes into the target on the specified port:

alert tcp $EXTERNAL_NET any -> $TELNET_SERVERS 23

(msg:"BACKDOOR w00w00 attempt"; flow:to_server,established;

content:"w00w00"; reference:arachnids,510; classtype:attempted-admin;

sid:209; rev:4;)

The above rule will only trigger if Snort sees traffic on port 23. Consequently, when sneeze generates a false positive attack, we must direct the attack based off this rule to port 23 if we expect the alert to be triggered.

In this lab, we will see how Snort rules can be easily tested with sneeze. We installed sneeze already on our Ubuntu Server VM. Open a new terminal shell and change to the sneeze installation directory:

cd sneeze

Next, look at the available options:

sudo perl sneeze.pl

Now, open your local.rules file in a text editor as root.

sudo gedit /etc/snort/rules/local.rules

Uncomment (remove the "#" symbols) all the rules you have in this file at the moment. Save the file and run Snort as root, but this time don't enable the quiet mode (-q):

sudo snort –A console –c /etc/snort/snort.conf –I eth0

Wait until you see "Commencing packet processing," then go to the sneeze terminal shell and run it using the IP of our Windows Server 2012 R2:

sudo perl sneeze.pl –d 192.168.132.143 –f /etc/snort/rules/local.rules

You see that Snort generated several alerts. However, we can see that alerts were only generated for some of the rules, not for every single one. Press Ctrl+C to stop Snort. Session stats will be displayed. Scroll up to examine the results. In the image below, you can see that Snort analyzed 63 packets, yet only eight alerts were generated. Your numbers may be different, but proportions should be comparable.

This is thanks to Snort preprocessors that look for completed TCP connections. So, sneeze attacks don't look too bad so far, do they? But keep in mind that a) we have a very small number of rules written, and b) we haven't used sneeze to its full capacity yet. Restart Snort. Go back to sneeze and re-issue the command, this time using the loop option as follows:

sudo perl sneeze.pl –d 192.168.132.143 –f /etc/snort/rules/local.rules –c -1

Now attacks are being generated non-stop, and so are the Snort alerts. Let sneeze run for about a minute, then hit Ctrl+C to stop it. Look at the stats now. In the example (see image below), Snort and sneeze ran for about 1 ½ minute, and Snort generated 85,200 alerts during this time. Quite a difference.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

You could easily "sneak in" a real attack when running sneeze and the alerts for it may go unnoticed.