Bypass Intrusion Detection/Prevention Signatures

Bypass Intrusion Detection/Prevention Signatures

*Please note that this does not include the multitude of configuration errors (disabled by default checks like POST search/bad preprocessor configurations like minimum fragment length) nor network vs. host-based issues like fragment reassembly.
For configuration errors by default, please check http://cvs.snort.org....cgi/snort/doc/ and read appropriate preproc documents for disabled checks. By host, please check snort.conf. By network vs. host based issues, please google ids evasion.*

Today we're going to be taking a look at Snort signatures that are pushed by the public (amateur/community) and by professional signature writers. This paper will take a look at how to bypass these signatures once we have access to them and prove that modern signatures are as useful as modern antivirus engines. In particular, Snort signatures will be looked at as it is likely the most popular ids/ips solution and a lot of its content is made publicly available. We will start off with the mentality of signature writers and the mistakes they usually make. While this focuses on Snort, consider other IDS/IPS solutions and how these techniques may benefit you in other secured environments.



### Amateur/Average User Signatures ###

First off, before any kind of details against specific signature arguments are seen, let's get generic. People writing signatures are typically on a timeline. Also, people writing these signatures aren't necessarily vulnerability researchers and may not even understand the vulnerability or bug being presented to them. Because of this, it should be obvious that your attack should deviate from the public exploit as much as possible. Sometimes there are community exploit detections that are released just to say you have a signature so some company can keep feeling secure (happens ALL the time) against the skiddles. Look at the recent overlapping ranges DoS attack on Apache for a perfect example. When the new technique for this bug came out everyone was scampering for rules to appeas corporations and/or the public. So some of the newest content that comes out will likely be pushed to production in haste.

On to the bug itself, the overlapping ranges attack is rather humerous. The attack pattern is something like:

Range: bytes=0-,0-20,1-20,2-20,3-20...

These ranges can be added any number of times and will generate a new request in memory for every range requested. Any range that is unhandled will request all bytes until end of file. So 0- is 0-EOF. The server code handling these ranges is not very optimized, so hundreds of requests can be made causing high memory utilization. Sending hundreds of packets for hundreds of range requests that is not optmially handled will result in memory starvation rather quickly.

Here is the initial signature discussion on full disclosure:
http://seclists.org/...re/2011/Aug/289

1.) alert tcp $EXTERNAL_NET any -> any 80 (msg:"INBOUND Apache Killer script: Local web server is under attack."; content:"Range:bytes=0-"; classtype: denial-of-service; threshold: type threshold, track by_src, count 5 , seconds 20; sid:3000005;)

2.) alert tcp any any -> any $HTTP_PORTS (content:"Range"; nocase; http_header; pcre:"/(\d\,){6,}/xH"; http_header; msg:"Apache DOShttp://seclists.org/fulldisclosure/2011/Aug/175"; reference:cve,2011-3192 )

3.) pcre: "/^Range:bytes\s+\d+-\d?,\d+-\d+,\d+-\d+,\d+-\d+,\d+-\d+,\d+-\d+,/xH"; http_header;

The first signature is very easy to bypass. This was made for the public exploit and specifying a number other than 0- will allow you to bypass the signature. Not only that, but nocase was never specified. This would mean that ByTes would bypass this signature. Also, spacing between the header and argument is going to invalidate the signature. Spacing is actually a huge menace to signatures trying to be specific for optimization reasons, more on this in later sections.
The second signature would actually not work on any exploit attempt for this bug. The pcre does not check for a dash, only a character followed by a comma six sequential times. As no consideration for the dash is in there, this would never fire. I'm glad this was seen because people do push signatures out to the public that do not work on the exploit in question.
The third signature is more interesting to us in a bypass sense. The regex looks for any amount of digits followed by a dash and any amount of digits. /xH stands for ignore whitespace characters (in the regex expression) and H is specific to Snort PCRE. In the Snort manual H is specified as:

"Match normalized HTTP request or HTTP response header (Similar to http header). This modifier is not allowed with the unnormalized HTTP request or HTTP response header modifier(D) for the same content. For SIP message, match SIP header for request or response (Similar to sip header)."

What normalize does not do is be case insensitive (/i). So mixing case values will invalidate this signature and effectively allow you to bypass it.

**Don't give the guy on the list shit, he gave out free information and made a valiant attempt at detection. That's more than I can say for a lot of people.



### Community/Official Signatures ###

Alright, let's step up our targets and stop picking on amateur/novice writer signatures. Let's take a look at the emerging threats community signatures. A very popular choice for free signatures. Most companies will sign up for these signatures and place them in their environment as is. Also, sometimes people who write their own signatures will see that one is already created for it and not even bother to validate or write their own. These emerging threats community rules are freely distributed at:

http://rules.emergingthreats.net/

We'll take a look at the same vulnerability. There are two rules in emerging threats related to this attack:

1.) alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Kingcope KillApache.pl Apache mod_deflate DoS attempt"; flow:established,to_server; content:"Range|3a|bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14"; http_header; fast_pattern:only; classtype:attempted-dos; reference:url,seclists.org/fulldisclosure/2011/Aug/175; sid:2013472; rev:2;)

2.) alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Apache mod_deflate DoS via many multiple byte Range values"; flow:established,to_server; content:"Range|3a|"; nocase; http_header; content:"bytes="; http_header; fast_pattern; nocase; distance:0; isdataat:10,relative; content:","; http_header; within:11; isdataat:10,relative; content:","; http_header; within:11; isdataat:10,relative; content:","; http_header; within:11; isdataat:70,relative; content:!"|0d 0a|"; within:12; pcre:"/Range\x3a\s?bytes=[-0-9,\x20]{100,}/iH"; classtype:attempted-dos; reference:url,seclists.org/fulldisclosure/2011/Aug/175; sid:2013473; rev:1;)

The first one is obviously checking for the public exploit. Not only is it doing that, but it's even more specific (thus worse) to the public exploit than the amateur rule. This just goes to show that just because a rule may be in an 'official' release doesn't mean it's really all that good.
The second one is much more involved to the attack and is close to a hardened detection. There's a lot of junk to look at, but most of the signature is really only used for optimization before it hits the pcre engine as pcre is an expensive luxury to a sensor. The main meat of the signature is "pcre:"/Range\x3a\s?bytes=[-0-9,\x20]{100,}/iH";". /iH means normalize the url and do not worry about case sensitivity. The problem is normalization doesn't remove extra whitespace characters. While we look for valid whitespace in certain areas (between range/bytes and in the range itself), the signature does not check between bytes and the specified ranges. Also, note the valid attempt at checking for a space between Range: and bytes only checks for one whitespace character (\s?). So, to invalidate the regex, simply use "bytes = range-values".



### Professional Signatures ###

How about those companies with the budget for good signatures? Professional signatures usually have very good expressions because the authors work with them all the time. A good idea of professional signature quality lies in SourceFire's own VRT team:

http://www.snort.org/start/rules

New rules are released often and you can get them for free after the initial 30 days of release. This is a great service as it is current and the rules are usually decent. Of course, the rules have problems just like everyone else. Unfortunately, I can't give away any information on VRT rules that aren't past the 30 day mark. The example signature I want to use is in this 30 day, so I can't show their signature. Instead, let's consider a proof of concept attack for my made up protocol:

retrieve /happygoat
argument:nomnom=nom-mem.nom-mem.nom-mem.nom-mem.nom-mem.nom-mem
from pacmanfever.com

Now, let's say a professional pcre would look like:
pcre:"/^argument\x3anomnom=([\w\x20\x2D]+\x2e){4,}/Hsmi";

This would effectively check for the public attack. The regex grouping would catch our nom-nom attack appropriately. /Hsmi is case insensitive, allow . in expression to include a new line, treat string as line of characters, and normalize the url. However, none of these arguments strip or allow for excess whitespace. So, by placing a space between argument and \x31, \x3a and nomnom, or nomnom and =, then we would effectively bypass this signature.
These regex expressions are usually very detailed when it comes to the attack, however there is a lack of detail for variations in the legitimate portion of how it's called.



### depth ###

Now, to get away from rule writers and on to snort specifics. The problems usually lie when the writer wants to optimize their rules so it's not so taxing on snort to validate. A major problem lies in depth. According to the snort manual, depth is:

"The depth keyword allows the rule writer to specify how far into a packet Snort should search for the specified pattern. depth modifies the previous ‘content’ keyword in the rule.
A depth of 5 would tell Snort to only look for the specified pattern within the first 5 bytes of the payload."

I went ahead and just picked a random rule for an example. Here's a good one:

alert tcp $EXTERNAL_NET any -> $HOME_NET 3057 (msg:"WEB-MISC Borland StarTeam Multicast Service buffer overflow attempt"; flow:established,to_server; content:"GET AAAAAAAAAAAAAAAAAAAAA"; depth:25; reference:bugtraq,28602; reference:cve,2008-0311; classtype:attempted-admin; sid:16283; tag:session,5,packets; rev:1;)

There are two interesting bypasses here to look at. The first is with the attempted content match. Depth is stating that the content match must be found within the 25 bytes from offset 0 into the payload (which the author misjudged as the start of the command). However, if something could be inserted into the payload before GET, while causing no problems to the injection itself, then it would bypass the depth limit and invalidate the signature.
So the goal becomes finding a byte or more that can be introduced into the payload before the injection. Unfortunately, \x20 would reveal a bad request error and not allow us to execute the wanted command. However, a new line can be introduced before the GET sequence to bypass the depth restriction. In fact, many new line characters can be used. I tested this out with a simple raw socket python script that looks for return method back. Appropriate line:

import socket
from time import sleep

payload = ("\x0d\x0a"*3)
request = "GET /news.php HTTP/1.1\r\nHost: securityoverride.com\r\n\r\n"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("206.214.216.120", 80))
s.send(payload+request)
sleep(1)
reply = s.recv(25)
if (reply.find("200") != -1):
if (raw_input("200 OK found, verify? (y/n):\t") == "y"):
dumpbuff = s.recv(2048) # increase for verification content
print(dumpbuff)
s.close()


The raw bytes coming across (to make sure the byte is actually coming through in our payload):
0d0a 0d0a 0d0a 4745 5420 2f6e :nR.......GET./n

And, validation response:
HTTP/1.1 200 OK (looked through payload, appropriate page seen)

Of course, a simple fuzzer in the payload portion can find characters that can be placed in front of the method to check for allowed characters to use. We could also see what types of encodings are allowed and see if we can expand our usable characters. This way we aren't getting trapped by (byte){x,} type signatures in the future. Speaking of \x20 (space), we can issue this inbetween the http method and the actual URI request.

GET \x20\x20\x20\x20/news.php HTTP/1.1 is as valid as:
GET /news.php HTTP/1.1

*Originally proved using an FTP signature. These are all over.


### within ###

Within is defined in the snort manual as:

"The within keyword is a content modifier that makes sure that at most N bytes are between pattern matches using the content keyword ( See Section 3.5.1 ). It’s designed to be used in conjunction with the distance (Section 3.5.6) rule option."

Please read the depth section for issues with within modifiers. Take note that both depth and within are highly used in snort signatures.



### Takeaway Lessons ###

Remember, more and more signatures are always being written. Despite what you think or what people tell you, more signatures isn't a good thing. More signatures means that Snort and other systems will have a heavier load while processing, parsing, and analyzing packets. PCRE is an expensive operation as well, so verification will be attempted as much as possible before PCRE is done so it doesn't need to load the engine. Given this, ways to optimize will keep coming out and that will include hard-defined pointers to start looking for specific content and even where to stop looking. Mess with the protocol and see what kind of valid bytes you can throw before/after commands/injections, before/after arguments, in the middle of arguments/commands and etc. Simple bypasses are going to want to include mixing cases, including spaces wherever possible, and obviously deviating from the public exploit as much as possible.
The more interesting mutations are going to be created by fuzzing the protocol the attack is on, inserting bytes into the attack call and seeing if the injection still fires. Of course, depending on how the exploit works, you don't have to test with an exploit but valid commands and see if they still fire. I will be going more into this idea on future articles with backing scripts.

Also, not mentioned above, internal attacks are much easier to get passed ids/ips. Because of said optimization, lots of rules are defined as external traffic coming to internal hosts so they don't have to bother with parsing further into ALL traffic to/from a host in your home network. Internal network attacks against applications (layer 7) are not usually defined to even check for such attacks. Most signatures for such services are like:

alert $EXTERNAL_NET any -> $HOME_NET any
$EXTERNAL_NET can also be defined as !$HOME_NET