This paper covers a new technique that can help IDS/IPS solution developers to provide more protection against web attacks. The approach is very generic and can be “adopted” by any IDS/IPS solution provider. Presently the approach is just an Idea and it requires more research and experiment to convert it into a working solution. This approach helps in enhancing quality of “signature based IDS/IPS solution” and provides good coverage with respect to the evasion techniques.

1. Abstract
This paper covers a new technique that can help IDS/IPS solution developers to provide more
protection against web attacks. The approach is very generic and can be “adopted” by any IDS/IPS
solution provider. Presently the approach is just an Idea and it requires more research and experiment
to convert it into a working solution.
This approach helps in enhancing quality of “signature based IDS/IPS solution” and provides good
coverage with respect to the evasion techniques.
Introduction
There are some web attacks that can be performed against different applications, let us name them as
“Generic Attacks”. Also these attacks involve evasion techniques to bypass the IDS/IPS signature
based protection mechanism.
Generic Attacks Name:-
1. Cross Site Scripting
2. SQL Injection
3. Shell Code Execution
4. Directory Traversal
5. Buffer overflow
6. Remote File Inclusion
Presently, most of the signature based IDS/IPS solution providers provides one signature per
vulnerability or they may write some more signatures for same vulnerability to cover the evasion
techniques but most of the IDS/IPS solutions are following this approach.
This approach allows the attacker to bypass the IDS/IPS detection using evasion techniques.
There are some other limitations of current approach which are covered below under “Problem”
heading.
Problem
To explain the problem more clearly let me start with an example:-
Threat Information: - Cross-Site Scripting (XSS) vulnerability in the com_search module for Joomla!
1.0.x through 1.0.15 allows remote attackers to inject arbitrary web script or HTML via the ordering
parameter to index.php.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0005
In above vulnerability we can see that “Joomla” application is vulnerable to XSS attack via “ordering”
parameter.
Sample POC/Exploit for above vulnerability
http://attacker.in/joomla1015/index.php?option=com_search&searchword=xss&searchphrase=any&o
rdering=newest%22%20onmousemove=alert%28document.cookie%29%20style=position:fixed;top:
0;left:0;width:100%;height:100%;%22

2. Above mentioned POC is just one XSS type of case and there are many other evasion techniques that
attacker can use to conduct the attack, but vulnerable parameter “ordering” remains the same in
other XSS cases.
To detect the above attack signature developer writes a single signature or multiple signatures to
cover some XSS evasion techniques. But there are very high chances that developer may miss to
cover some evasion techniques or in many cases he/she may not be able to write multiple signatures
due to the performance issues of detection engine, as more number of signatures involves more
processing time.
A sample IDS signature (Snort Rule) that a developer can write to detect the above malicious URL is
as below:-
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"Joomla XSS Attack";
flow:established,to_server; content:"index.php"; nocase; http_uri; content:"ordering="; nocase;
http_uri; pcre:"/ alertx28document.cookiex29x20style /smi"; metadata:policy security-ips alert,
service http; classtype:web-application-attack; sid:15 )
Same approach is followed while developing the signatures for other attacks.
Also one important point here is that the way XSS attack is conducted is mostly common across the
applications, only thing that vary is parameter, argument or function, like in above mentioned
vulnerability parameter is “ordering” and in case of XSS vulnerability in other application this
parameter can be something else let’s say “userid”.
Snort rules:-
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"WEB-PHP phpBB mod tag board
sql injection attempt"; flow:established,to_server; content:"tag_board.php"; fast_pattern; nocase;
http_uri; content:"action=delete"; nocase; http_uri; content:"id="; nocase; http_uri;
pcre:"/tag_board.phpx3F[^rn]*action=delete[^rn]*id=[^rnx26]*(select|insert|delete)/
Usmi"; threshold:type limit, track by_src, count 1, seconds 300; metadata:policy security-ips alert,
service http; reference:bugtraq,32701; reference:cve,2008-6314; classtype:web-application-attack;
sid:15425; rev:5;)
In above snort rule, signature is only covering one evasion technique to detect the SQL injection.
Although there are many other ways using which attacker can bypass this detection rule.
For example: - Attacker can provide the select, insert and delete query via using comment /**/
within the keyword as S/**/E/**/L/**/ECT which gets normalize as SELECT later on database
side. As we can see that this is not covered by above signature.
This is just one way of performing SQL injection and there are many more ways that attacker can use
to conduct the attack. For more details you can search for SQL injection Evasion Techniques.
Like the above rule you can find some more signatures which are having same limitations.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL generic sql with
comments injection attempt - GET parameter"; flow:to_server,established; content:"/*"; http_uri;
content:"*/"; http_uri; pcre:"/(update|exec|insert|union)[^/]*/*.**//Uis";
metadata:service http; reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
classtype:web-application-attack; sid:16431; rev:2;)

3. alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL generic sql insert
injection atttempt - POST parameter"; flow:established,to_server; content:"insert "; fast_pattern;
nocase; http_client_body; pcre:"/inserts+intos+[^/]+/Pi"; metadata:policy security-ips
drop, service http; reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
classtype:web-application-attack; sid:15875; rev:5;)
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL generic sql update
injection attempt - GET parameter"; flow:established,to_server; content:"update"; fast_pattern;
nocase; http_uri; pcre:"/updates+[^/]+sets+[^/]+/Ui"; metadata:policy security-ips
drop, service http; reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
classtype:web-application-attack; sid:13514; rev:11;)
Weaknesses and Limitations found in current scenario:-
1. If some new evasion technique is discovered that conducts web attack (like SQL injection)
then in that case a new IDS/IPS signature have to be released for all the applications which
has SQL injection vulnerabilities. So, developer has to write one new signature for all the
applications to provide the protection. There is no single point where we can patch the entire
signatures against this new evasion technique.
2. False Negative chances are high in current scenario as IDS/IPS signature written for
vulnerability can possibly miss to cover some evasion techniques during signature
development phase or due to performance limitation of IDS/IPS detection engine.
3. In current approach it is difficult for IDS/IPS solution provider to provide quality assurance
parameters per vulnerability like how many evasion techniques or which evasion techniques
their signatures are covering for a particular vulnerability. Providing such information per
vulnerability is difficult.
Brief about signature development:-
Before writing the signature for vulnerability we first find the parameter, argument or function which
has the flaw. Now, while writing the signature we first match this parameter and then match the
attack pattern using either content matching or using PCRE.
Here, for above explained Joomla XSS attack I am writing a sample signature:-
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"Joomla XSS Attack";
flow:established,to_server; content:"index.php"; nocase; http_uri; content:"ordering="; nocase;
http_uri; pcre:"/ alertx28document.cookiex29x20style /smi"; metadata:policy security-ips alert,
service http; classtype:web-application-attack; sid:15 )
Here I have match the parameter “ordering” and then match the attack pattern using PCRE.
We match parameter first to reduce the PCRE matching on whole traffic to improve the performance
and reduce false positive chances. Direct PCRE matching on real traffic is very performance intensive.
My Idea
Generic Detection Algorithm/Engine: - What I am suggesting is that, we can develop some
generic detection algorithm/engine for each such generic attack and call them whenever they are
required.
Like in above case instead of matching the malicious pattern using a single PCRE we can call “XSS
detection algorithm/engine” that covers all the possible XSS evasion techniques.

4. There are multiple advantages of developing and using such attack detection algorithm/engine:-
1. Reusability:-The advantage of developing such engine is that we can call it for any
application which is vulnerable to such attack.
2. Signature Patching: - In case some new evasion technique is introduced to conduct the
attack then it’s only needed to enhance the detection engine to cover this new evasion
technique instead of what we do right now by developing a new signature for all the
applications. At the same time, it will reduce false negative chances. Also, it helps in providing
“Zero Day” protection.
3. Accountability: - With the help of such detection algorithm/engine we are sure about how
many evasion techniques are covered per vulnerability.
4. Quality Assurance: - Using such detection algorithm/engine we are very sure and confident
about the quality of our signature coverage.
5. Performance Enhancement: - We can optimize the algorithm and also use some special
hardware to run, which can help in improving the performance of IDS/IPS detection solution.
6. Automation: - Signature development process can be automated once we have the stable
detection engine for attack.
Details:-
Flow Diagram:-
Packet Capture
Malicious Pattern
http://attacker.in/joomla1015/index.php?option=com_search&searchword=xss&searchphrase=a
ny&ordering=newest%22%20onmousemove=alert%28document.cookie%29%20style=position:f
ixed;top:0;left:0;width:100%;height:100%;%22
First Content/Pattern Match
content:"ordering=";
PCRE Match for XSS
pcre:"/ alertx28document.cookiex29x20style
/smi";
Generic XSS detection Algorithm/Engine covers
all Evasion Techniques

5. Basic Architecture of Generic Detection Engine
Following architecture diagram it to give you a little Idea about how the generic detection approach
can work.
Content or PCRE Match
In above diagram we have two branches after Content/Pattern Match one is “Normal Detection” and
another one is “Generic Detection Engine”.
For generic attacks we are having six different attack detection engines which can be called as per the
detection requirement. Each individual detection engine cover all the possible evasion techniques
related to the respective attack.
Like XSS engine is capable of detecting all type of XSS attack evasions.
These detection engines are called during signature matching for the detection of malicious patterns
and return the result.
For all other type of attacks we have our normal detection engine that works like current detection
logic that includes further Content/PCRE matches.
XSS Detection
SQL Injection
Shell Code
Directory Traversal
Buffer Overflow
Remote File Inclusion
Content/Pattern Match
Generic Detection EngineNormal Detection

6. Detection Levels:-
We can define some detection levels in attack detection engine like low, medium and high. In case if
we want to drop some evasion techniques at the cost of appliance performance then there has to be
some possibility within engine using which we are able to drop some evasion techniques.
Evasion Techniques Complexity
Detection Engine Parameters: - Possible parameters that the detection engine can have are
mentioned as below:-
Engine ID Engine Name Detection Level Status Evasion
Technique
Count
1 XSS Low/Medium/High Enable/Disable Some Integer
Value
2 SQL Injection Low/Medium/High Enable/Disable Some Integer
Value
3 Shell Code Low/Medium/High Enable/Disable Some Integer
Value
4 Buffer Over Flow Low/Medium/High Enable/Disable Some Integer
Value
5 Directory Traversal Low/Medium/High Enable/Disable Some Integer
Value
6 Remote File Inclusion Low/Medium/High Enable/Disable Some Integer
Value
XSS Attack
HighLow Medium
Evasion 1 Evasion 2 Evasion 3 Evasion 4 Evasion 5

7. New Construct For IDS/IPS Signature
From signature development language/syntax point of view we can have some new constructs like as
below “engineid” and “detectionlevel” that can support the new generic detection engine. This is
just one way that I am thinking of but there can be some other ways also to integrated/implement the
new approach.
OLD RULE:-
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"Joomla XSS Attack";
flow:established,to_server; content:"index.php"; nocase; http_uri; content:"ordering="; nocase;
http_uri; pcre:"/ alertx28document.cookiex29x20style /smi"; metadata:policy security-ips alert,
service http; classtype:web-application-attack; sid:15 )
NEW RULE:-
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"Joomla XSS Attack";
flow:established,to_server; content:"index.php"; nocase; http_uri; content:"ordering="; nocase;
http_uri; engineid:1;detectionlevel:high;metadata:policy security-ips alert, service http;
classtype:web-application-attack; sid:15 )
Now as you can see that instead of “pcre” match I am using an “engineid” and “detectionlevel” which
is the ID of XSS engine. First signature perform the content matching “index.php” and “ordering=”
once it’s matched after then “XSS engine” is called to match for all the possibilities of XSS evasion
techniques and return the result. If any match succeeds then signature is triggered.
Here, using new approach there is no need to write the multiple signatures for different-2 evasion
techniques. All of this is taken care by generic detection engine.
Conclusion and Further Work
I believe that this approach helps a lot in IDS/IPS solution development and improve the quality of
signatures with respect to the evasion techniques. Using this new approach we can overcome the
current approach flaws and limitations.
Lot of work is required to actually make this approach as a working solution. Nothing has been tested
and implemented yet. So we need to do some experiments to test how this approach works. Once we
have some good results then we need to find a way to implement this approach into a working
solution.
Feedback and comments are most welcome.
Best Regards
Packet Computing Team