Onderwerp: New Paper - SQL Injection Signatures Evasion

Dear List,

Imperva(tm)'s Application Defense Center has released a new white paper.

The paper, titled 'SQL Injection Signatues Evasion', is based on
research done at Imperva's ADC, and shows that providing protection
against SQL injection using signatures alone is not enough. The paper
demonstrates various techniques that can be used to evade SQL injection
signatures, including advanced techniques that were developed during the
research, and explains why it is not possible to adequately protect an
application against SQL injection using signatures only.

The paper can be viewed at http://www.imperva.com/adc/papers/sigevasion
(Both HTML and PDF versions are available)

The paper was written by:
Ofer Maor, Application Defense Center Manager
Amichai Shulman, Chief Technology Officer


Table of Contents
-----------------
- Abstract=20
- Introduction=20
- Recognizing Signature Protection=20
- Common Evasion Techniques=20
Different Encodings=20
White Spaces Diversity=20
TCP Fragmentation=20
- Advanced Evasion Techniques=20
The 'OR 1=3D1' Signature=20
Evading Signatures with White Spaces=20
Evading Any String Pattern=20
- Conclusion=20
- References=20

Abstract
--------
In recent years, Web application security has become a focal center for
security experts. Application attacks are constantly on the rise, posing
new risks for the organization. One of the most dangerous and most
common attack techniques is SQL Injection, which usually allows the
hacker to obtain full access to the organization's Database.

With the rise in SQL Injection attacks, security vendors have begun to
provide security measures to protect against SQL Injection. The first
ones to claim such protection have been the various Web Application
Firewall vendors, followed by most IDS/IPS vendors.=20

Most of this protection, however is Signature based. This is obviously
the case with common IDS/IPS vendors, as they come from the network
security world, and revolve around signature-based protection. However,
most of the Web Application Firewalls base their SQL Injection
protection on signatures as well. This is due to the fact that they
inspect HTTP traffic only, and are able to look for attack patterns only
within HTTP traffic. Moreover, it has lately become a common belief that
signatures are indeed sufficient for SQL Injection protection. This
belief has been backed up by a recently published article, describing,
allegedly, a thorough guide for building SQL Injection signatures, in
Snort(tm)-like format.=20

The research done at Imperva's Application Defense Center shows,
however, that providing protection against SQL Injection using
signatures only is not enough. This paper demonstrates various
techniques that can be used to evade SQL Injection signatures, including
advanced techniques that were developed during the research.=20

The paper further demonstrates why these techniques are actually just
the tip of the iceberg of different evasion techniques, due to the
richness of the SQL language. Eventually, the conclusion that the
research leads to is that providing protection against SQL Injection
using only signatures is simply not practical. A reasonably sized
signature database will never be complete, while an attempt to create a
complete comprehensive signature database, even if theoretically
possible, will yield an amount of signatures that is impossible to
handle while maintaining a reasonable performance requirement, and is
likely to generate too many false positives.


=20
---
Application Defense Center
Imperva(tm) Inc.
http://www.imperva.com/adc

This is in response to Imperva's email that it is trivial to evade
signature-based detection of SQL injection. There are a few points I'd like
to respond to in relation to their tone and content of the paper. Well first
lets take the tone:

The abstract of Imperva's paper says, among other things:
"Moreover, it has lately become a common belief that signatures are indeed
sufficient for SQL Injection protection. This belief has been backed up by a
recently published article, describing, allegedly, a thorough guide for
building SQL Injection signatures, in SnortT-like format." The "article" is
of course, the one on 'Detection of SQL injection and Cross-site scripting
attacks" that we wrote for Securityfocus
http://www.securityfocus.com/infocus/1768

First of all, this article that we wrote was never intended to be a
"thorough guide" nor did it claim that anywhere in the entire text. In fact,
in the conclusion to that article, we clearly stated:
"We recommend that these signatures be taken as a starting point for tuning
your IDS or log analysis methods, in the detection of these Web application
layer attacks." That surely does not sound like we were writing a thorough
guide

Anyways, coming to the technical issues. I do agree that signature-based
detection isn't 100% foolproof. In fact, throughout the article we've
pointed out some signatures that would yield a high number of false
positives, and we've stated that in the conclusion as well. The idea was to
start off on one possible technique to detect web application attacks. The
fact that Snort signatures support Perl compatible regular expressions
(pcre), gives an enormous amount of flexibility in writing concise
signatures that cover a multitude of possibilities. The signatures that we
have listed may not always be directly applicable and may require the
administrator to tune those signatures to their specific requirements.

Also in your paper the attacker tries out standard SQL injection techniques
and then moves on to enumeration of the IDS signatures using a whole bunch
of attack signatures, which "...involves a tedious, methodical process, of
trial and error. Autolycus simply takes a list of the attacks he uses during
the hack, and tries them out one by one." In the real world, it is quite
likely that by doing so he would have raised a huge number of alarms, which
a diligent security administrator would get alerted to. In fact, a large
majority of the attacks listed out in your paper would in fact be detected
by these signatures. I won't go in depth and analyze each evasion technique
that you discuss.

But, I do agree that signature-based detection isn't the final word in
application attack detection. Nor is anamoly-based detection, which is what
your product "Imperva Application Defense Center" is based on. I guess the
final word on this subject is still a long way ahead. Maybe its a product
that combines both approaches. I was thinking of a product that first uses
anomaly-based techniques to develop a list of signatures. Then the
administrator has the option to accept or reject the signatures, especially
if they are going to be used for intrusion *prevention*, rather than just
intrusion *detection*. That probably brings the best of both worlds - a
product to analyze and build signatures that not all administrators would be
knowledgeable enough to do themselves. Then presents a list of these with
basic explanation of what each one does. The administrator or the
consultants can train the product, just like one is supposed to do with an
IDS - be it signature-based or anamoly-based. Just a thought.

Our idea in writing that article was to provide a starting point for IDS
administrators to try and build in application level detection for almost
99% of typical application attackers. The response that we got indicated
that people took it that way. We had emails of administrators already having
working signatures for Oracle-based SQL injection attacks, of signatures
that worked with mod_security of Apache, and SecureIIS of Eeye, and feedback
on the signatures themselves. Which confirms my initial thought, that
signature-based detection is a feasible and cost-effective solution, though
it will require more study and better signatures.

I'd welcome a discussion on this topic, maybe on a more appropriate forum
such as webappsec@securityfocus.com or focus-ids@securityfocus.com

Cheers,

K. K. Mookhey
Founder-CTO,
Network Intelligence India Pvt. Ltd.
Web: www.nii.co.in
Tel: +91-22-22001530/22006019
=========================
Security Consultancy Services
http://www.nii.co.in/services.html
=========================

> ----- Original Message -----
> From: "Imperva Application Defense Center" <adc@imperva.com>
> To: <bugtraq@securityfocus.com>
> Sent: Monday, April 19, 2004 2:38 PM
> Subject: New Paper - SQL Injection Signatures Evasion
>
>
> Dear List,
>
> Imperva(tm)'s Application Defense Center has released a new white paper.
>
> The paper, titled 'SQL Injection Signatues Evasion', is based on
> research done at Imperva's ADC, and shows that providing protection
> against SQL injection using signatures alone is not enough. The paper
> demonstrates various techniques that can be used to evade SQL injection
> signatures, including advanced techniques that were developed during the
> research, and explains why it is not possible to adequately protect an
> application against SQL injection using signatures only.
>
> The paper can be viewed at http://www.imperva.com/adc/papers/sigevasion
> (Both HTML and PDF versions are available)
>
> The paper was written by:
> Ofer Maor, Application Defense Center Manager
> Amichai Shulman, Chief Technology Officer
>
>
> Table of Contents
> -----------------
> - Abstract
> - Introduction
> - Recognizing Signature Protection
> - Common Evasion Techniques
> Different Encodings
> White Spaces Diversity
> TCP Fragmentation
> - Advanced Evasion Techniques
> The 'OR 1=1' Signature
> Evading Signatures with White Spaces
> Evading Any String Pattern
> - Conclusion
> - References
>
> Abstract
> --------
> In recent years, Web application security has become a focal center for
> security experts. Application attacks are constantly on the rise, posing
> new risks for the organization. One of the most dangerous and most
> common attack techniques is SQL Injection, which usually allows the
> hacker to obtain full access to the organization's Database.
>
> With the rise in SQL Injection attacks, security vendors have begun to
> provide security measures to protect against SQL Injection. The first
> ones to claim such protection have been the various Web Application
> Firewall vendors, followed by most IDS/IPS vendors.
>
> Most of this protection, however is Signature based. This is obviously
> the case with common IDS/IPS vendors, as they come from the network
> security world, and revolve around signature-based protection. However,
> most of the Web Application Firewalls base their SQL Injection
> protection on signatures as well. This is due to the fact that they
> inspect HTTP traffic only, and are able to look for attack patterns only
> within HTTP traffic. Moreover, it has lately become a common belief that
> signatures are indeed sufficient for SQL Injection protection. This
> belief has been backed up by a recently published article, describing,
> allegedly, a thorough guide for building SQL Injection signatures, in
> Snort(tm)-like format.
>
> The research done at Imperva's Application Defense Center shows,
> however, that providing protection against SQL Injection using
> signatures only is not enough. This paper demonstrates various
> techniques that can be used to evade SQL Injection signatures, including
> advanced techniques that were developed during the research.
>
> The paper further demonstrates why these techniques are actually just
> the tip of the iceberg of different evasion techniques, due to the
> richness of the SQL language. Eventually, the conclusion that the
> research leads to is that providing protection against SQL Injection
> using only signatures is simply not practical. A reasonably sized
> signature database will never be complete, while an attempt to create a
> complete comprehensive signature database, even if theoretically
> possible, will yield an amount of signatures that is impossible to
> handle while maintaining a reasonable performance requirement, and is
> likely to generate too many false positives.
>
>
>
> ---
> Application Defense Center
> Imperva(tm) Inc.
> http://www.imperva.com/adc
>
>

Dear Mr. Mookhey,
=20
The 'SQL Injection Signatures Evasion' paper is the result of a several
months-long research conducted by Imperva's ADC. This research began
long before the pulibcation of the 'Detection of SQL Injection and
Cross-Site scripting attacks', and was obviously never intended as a
means of countering the validity or necessity of your paper.=20
=20
The reference to the paper was done exactly for the reasons you have
mentioned in your message. Altough not claiming to be a thorough guide,
the paper you have published is a very important paper, trying to use
the power of regular expressions to yield high coverage of SQL Injection
attacks detection. What we wanted to show was, that even such strong and
elaborate patterns, which would detect most of normal level application
level attacks, can not provide full protection, and will eventually be
bypassed using different evasion techniques (Obviously, once new
techniques are developed, more signatures can be added, but this is the
old cat & mouse game between the security experts and the hackers). Our
paper does not claim that the paper you have published is wrong in any
way or unprofessional. On the contrary, we do believe that this is one
of the best set of signatures we have seen published.
=20
As for Imperva's Application Defense Center, I believe there is some
confusion. Imperva's Application Defense Center is an independant group
within Imperva, which is dedicated to research of new application
security topics, as well as provide application security services, such
as penetration tests. Although Imperva(tm) Inc. is developing such a
product, and although some of its concepts are obviously a result of the
experience of Imperva's ADC, all the research done in Imperva's ADC is
completely independant. The grounds for a new research are usually based
on real world problems we encounter during penetration tests, or other
issues we believe will be interesting to investigate. For these reasons
we will not discuss in this forum the capabilities of Imperva's
products.
=20


P.S., I am cc'ing this to the lists where you have posted it, but also
to webappsec, as I believe that is the proper place for that discussion.


---
Ofer Maor
Application Defense Center Manager
Imperva(tm)
Phone: +972-3-6120133, Ext. 113
Fax: +972-3-7511133
Web Site: http://www.imperva.com/adc


-----Original Message-----
From: K. K. Mookhey [mailto:cto@nii.co.in]=20
Sent: Monday, April 26, 2004 8:32 AM
To: Imperva Application Defense Center
Cc: bugtraq@securityfocus.com; secpapers@securityfocus.com
Subject: Re: New Paper - SQL Injection Signatures Evasion


This is in response to Imperva's email that it is trivial to evade
signature-based detection of SQL injection. There are a few points I'd
like to respond to in relation to their tone and content of the paper.
Well first lets take the tone:

The abstract of Imperva's paper says, among other things: "Moreover, it
has lately become a common belief that signatures are indeed sufficient
for SQL Injection protection. This belief has been backed up by a
recently published article, describing, allegedly, a thorough guide for
building SQL Injection signatures, in SnortT-like format." The "article"
is of course, the one on 'Detection of SQL injection and Cross-site
scripting attacks" that we wrote for Securityfocus
http://www.securityfocus.com/infocus/1768

First of all, this article that we wrote was never intended to be a
"thorough guide" nor did it claim that anywhere in the entire text. In
fact, in the conclusion to that article, we clearly stated: "We
recommend that these signatures be taken as a starting point for tuning
your IDS or log analysis methods, in the detection of these Web
application layer attacks." That surely does not sound like we were
writing a thorough guide

Anyways, coming to the technical issues. I do agree that signature-based
detection isn't 100% foolproof. In fact, throughout the article we've
pointed out some signatures that would yield a high number of false
positives, and we've stated that in the conclusion as well. The idea was
to start off on one possible technique to detect web application
attacks. The fact that Snort signatures support Perl compatible regular
expressions (pcre), gives an enormous amount of flexibility in writing
concise signatures that cover a multitude of possibilities. The
signatures that we have listed may not always be directly applicable and
may require the administrator to tune those signatures to their specific
requirements.

Also in your paper the attacker tries out standard SQL injection
techniques and then moves on to enumeration of the IDS signatures using
a whole bunch of attack signatures, which "...involves a tedious,
methodical process, of trial and error. Autolycus simply takes a list of
the attacks he uses during the hack, and tries them out one by one." In
the real world, it is quite likely that by doing so he would have raised
a huge number of alarms, which a diligent security administrator would
get alerted to. In fact, a large majority of the attacks listed out in
your paper would in fact be detected by these signatures. I won't go in
depth and analyze each evasion technique that you discuss.

But, I do agree that signature-based detection isn't the final word in
application attack detection. Nor is anamoly-based detection, which is
what your product "Imperva Application Defense Center" is based on. I
guess the final word on this subject is still a long way ahead. Maybe
its a product that combines both approaches. I was thinking of a product
that first uses anomaly-based techniques to develop a list of
signatures. Then the administrator has the option to accept or reject
the signatures, especially if they are going to be used for intrusion
*prevention*, rather than just intrusion *detection*. That probably
brings the best of both worlds - a product to analyze and build
signatures that not all administrators would be knowledgeable enough to
do themselves. Then presents a list of these with basic explanation of
what each one does. The administrator or the consultants can train the
product, just like one is supposed to do with an IDS - be it
signature-based or anamoly-based. Just a thought.

Our idea in writing that article was to provide a starting point for IDS
administrators to try and build in application level detection for
almost 99% of typical application attackers. The response that we got
indicated that people took it that way. We had emails of administrators
already having working signatures for Oracle-based SQL injection
attacks, of signatures that worked with mod_security of Apache, and
SecureIIS of Eeye, and feedback on the signatures themselves. Which
confirms my initial thought, that signature-based detection is a
feasible and cost-effective solution, though it will require more study
and better signatures.

I'd welcome a discussion on this topic, maybe on a more appropriate
forum such as webappsec@securityfocus.com or focus-ids@securityfocus.com

Cheers,

K. K. Mookhey
Founder-CTO,
Network Intelligence India Pvt. Ltd.
Web: www.nii.co.in
Tel: +91-22-22001530/22006019
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=

Security Consultancy Services http://www.nii.co.in/services.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=


> ----- Original Message -----
> From: "Imperva Application Defense Center" <adc@imperva.com>
> To: <bugtraq@securityfocus.com>
> Sent: Monday, April 19, 2004 2:38 PM
> Subject: New Paper - SQL Injection Signatures Evasion
>
>
> Dear List,
>
> Imperva(tm)'s Application Defense Center has released a new white=20
> paper.
>
> The paper, titled 'SQL Injection Signatues Evasion', is based on=20
> research done at Imperva's ADC, and shows that providing protection=20
> against SQL injection using signatures alone is not enough. The paper=20
> demonstrates various techniques that can be used to evade SQL=20
> injection signatures, including advanced techniques that were=20
> developed during the research, and explains why it is not possible to=20
> adequately protect an application against SQL injection using=20
> signatures only.
>
> The paper can be viewed at=20
> http://www.imperva.com/adc/papers/sigevasion
> (Both HTML and PDF versions are available)
>
> The paper was written by:
> Ofer Maor, Application Defense Center Manager
> Amichai Shulman, Chief Technology Officer
>
>
> Table of Contents
> -----------------
> - Abstract
> - Introduction
> - Recognizing Signature Protection
> - Common Evasion Techniques
> Different Encodings
> White Spaces Diversity
> TCP Fragmentation
> - Advanced Evasion Techniques
> The 'OR 1=3D1' Signature
> Evading Signatures with White Spaces
> Evading Any String Pattern
> - Conclusion
> - References
>
> Abstract
> --------
> In recent years, Web application security has become a focal center=20
> for security experts. Application attacks are constantly on the rise,=20
> posing new risks for the organization. One of the most dangerous and=20
> most common attack techniques is SQL Injection, which usually allows=20
> the hacker to obtain full access to the organization's Database.
>
> With the rise in SQL Injection attacks, security vendors have begun to

> provide security measures to protect against SQL Injection. The first=20
> ones to claim such protection have been the various Web Application=20
> Firewall vendors, followed by most IDS/IPS vendors.
>
> Most of this protection, however is Signature based. This is obviously

> the case with common IDS/IPS vendors, as they come from the network=20
> security world, and revolve around signature-based protection.=20
> However, most of the Web Application Firewalls base their SQL=20
> Injection protection on signatures as well. This is due to the fact=20
> that they inspect HTTP traffic only, and are able to look for attack=20
> patterns only within HTTP traffic. Moreover, it has lately become a=20
> common belief that signatures are indeed sufficient for SQL Injection=20
> protection. This belief has been backed up by a recently published=20
> article, describing, allegedly, a thorough guide for building SQL=20
> Injection signatures, in Snort(tm)-like format.
>
> The research done at Imperva's Application Defense Center shows,=20
> however, that providing protection against SQL Injection using=20
> signatures only is not enough. This paper demonstrates various=20
> techniques that can be used to evade SQL Injection signatures,=20
> including advanced techniques that were developed during the research.
>
> The paper further demonstrates why these techniques are actually just=20
> the tip of the iceberg of different evasion techniques, due to the=20
> richness of the SQL language. Eventually, the conclusion that the=20
> research leads to is that providing protection against SQL Injection=20
> using only signatures is simply not practical. A reasonably sized=20
> signature database will never be complete, while an attempt to create=20
> a complete comprehensive signature database, even if theoretically=20
> possible, will yield an amount of signatures that is impossible to=20
> handle while maintaining a reasonable performance requirement, and is=20
> likely to generate too many false positives.
>
>
>
> ---
> Application Defense Center
> Imperva(tm) Inc.
> http://www.imperva.com/adc
>
>