Now, let us see with a real world exploit example from Emergingthreats.net.
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.