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 > >
