Message-ID: <08dc01c42b58$2fbda290$1800a8c0@laptop3>
Date: Mon, 26 Apr 2004 12:02:01 +0530
From: "K. K. Mookhey" <cto@....co.in>
To: "\"Imperva Application Defense Center\"" <adc@...erva.com>
Cc: <bugtraq@...urityfocus.com>, <secpapers@...urityfocus.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@...urityfocus.com or focus-ids@...urityfocus.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@...erva.com>
> To: <bugtraq@...urityfocus.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
>
>

Powered by blists - more mailing lists