Signature Writing - 102

As mentioned in the previous post, we look for some repetitive commonness in the malicious packets, once we know that it could only come in the malicious packets for sure. But what are false positives and false negatives in this case. So, if "This is" is not specific to malicious packets alone and if that trace can be seen in good data too, then we call it a false positive. This is because, our signature would trigger alerts not only on the bad data, but on the good ones too. Now if the combination of "This is" and "." is not seen on the same packet then our signature might not trigger an alert. This is a false-negative.

Now, let us see with a real world exploit example from Emergingthreats.net.

Example1:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB TellTarget CMS Remote Inclusion site_conf.php ordnertiefe"; flow:established,to_server; uricontent:"/site_conf.php?"; nocase; uricontent:"ordnertiefe="; nocase; classtype:web-application-attack; reference:cve,CVE-2007-2597; reference:url,www.milw0rm.com/exploits/3885; sid:2003705; rev:2;)


In this example, we see the 2 content's to be the

uricontent:"/site_conf.php?"; nocase; uricontent:"ordnertiefe="; nocase;

and both are case-insensitive. This is the file-frame and the variable that are vulnerable according to CVE-2007-2597. NVD has a good list of CVEs that are linked to other external resources that could give more details on the vulnerabilities. For example, the above CVE links to milw0rm exploit for this vulnerability, the BID number and so on.

Now, further looking into above signature, we see

flow:established,to_server; 

This means that the connection is established and the direction is "to server".

In this case, we do not require any PCRE(Perl Compatible Regular Expression) since this is a remote file inclusion and this combination alone would be sufficient to catch the vulnerable function when entering the network. But what if there is some developer using this combination in their site and if someone inside the org is accessing that page. It is a false positive in that case, though it is sometimes best for the developers to understand that it is not good to code with the vulnerable variables or file-frames. But this will not happen in the near future as devloper and secure coding is different from a developer having knowledge on intrusion defense.

Rest in the next blog.

- EF