[SC-L] Lateral SQL injection paper
Greetings SC-Lers, Things have been pretty quiet here on the SC-L list... I hope everyone saw David Litchfield's recent announcement of a new category of SQL attacks. (Full paper available at http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) He refers to this new category as lateral SQL injection attacks. It's very different than conventional SQL injection attacks, as well as quite a bit more limited. In the paper, he writes: Now, whether this becomes exploitable in the normal sense, I doubt it... but in very specific and limited scenarios there may be scope for abuse, for example in cursor snarfing attacks - http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf . In conclusion, even those functions and procedures that don’t take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and don’t let this type of vulnerability get into your code. The second lesson is that no longer should DATE or NUMBER data types be considered as safe and not useful as injection vectors: as this paper has proved, they are. It's definitely an interesting read, and anyone doing SQL coding should take a close look, IMHO. It's particularly interesting to see how he alters the DATE and NUMBER data types so that they can hold SQL injection data. Yet another demonstration of the importance of doing good input validation -- preferably positive validation. As long as you're doing input validation, I'd think there's probably no need to back through your code and audit it for lateral SQL injection vectors. Anyone else have a take on this new attack method? (Note that I don't normally encourage discussions of specific product vulnerabilities here, but most certainly new categories of attacks--and their impacts on secure coding practices--are quite welcome.) Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Lateral SQL injection paper
David's papers are always interesting, but I think the most interesting thing is that we are starting to see advanced SQL injection like his recent work on cursor attacks/snarfing being used in the wild in mass-SQL injection exploits. Attackers are using multiple layers of encoding for both reliability of delivery, and and for obfuscation (for all of you that rolled your eyes every time I've talked about this for the last five years :) and as a result are bypassing interface input validation and blacklists. The attackers are using common stuff for filter evasion like using char(127), then hex URI- escaping or hex encoding that (with \hex, HTML entity, decimal, whatever), and then sometimes URI encoding every character of the resultant string. Internal parsers canonicalize down to the SQL interpretable string (e.g.char(127)) and the SQL parser obviously makes a nice ' out of that. There are a lot more clever things going on with the exploits, some of which could be restricted by simple privilege. Anyway -- the black hat crowd is paying as much attention to the lastest exploit techniques, if not more, than most of us are. They are using them in the wild, right this second, to make money. Interesting work by David, for sure, and great ammo if we have to beat the strong data typing drum in our software. -- -- Arian J. Evans, software security stuff. I spend most of my money on motorcycles, mistresses, and martinis. The rest of it I squander. On Mon, Apr 28, 2008 at 12:13 PM, Kenneth Van Wyk [EMAIL PROTECTED] wrote: Greetings SC-Lers, Things have been pretty quiet here on the SC-L list... I hope everyone saw David Litchfield's recent announcement of a new category of SQL attacks. (Full paper available at http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) He refers to this new category as lateral SQL injection attacks. It's very different than conventional SQL injection attacks, as well as quite a bit more limited. In the paper, he writes: Now, whether this becomes exploitable in the normal sense, I doubt it... but in very specific and limited scenarios there may be scope for abuse, for example in cursor snarfing attacks - http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf.. In conclusion, even those functions and procedures that don't take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and don't let this type of vulnerability get into your code. The second lesson is that no longer should DATE or NUMBER data types be considered as safe and not useful as injection vectors: as this paper has proved, they are. It's definitely an interesting read, and anyone doing SQL coding should take a close look, IMHO. It's particularly interesting to see how he alters the DATE and NUMBER data types so that they can hold SQL injection data. Yet another demonstration of the importance of doing good input validation -- preferably positive validation. As long as you're doing input validation, I'd think there's probably no need to back through your code and audit it for lateral SQL injection vectors. Anyone else have a take on this new attack method? (Note that I don't normally encourage discussions of specific product vulnerabilities here, but most certainly new categories of attacks--and their impacts on secure coding practices--are quite welcome.) Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Lateral SQL injection paper
Anyone else have a take on this new attack method? If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. In Java (for Insert/Update/etc) just use PreparedStatement + variable binding. There are similar constructs in all languages. Although the attack is cool - the defense is still the same. Grey Box Testing (code review and pen testing) will uncover all SQL Injection flaws in even the largest app in very little time. - Jim Greetings SC-Lers, Things have been pretty quiet here on the SC-L list... I hope everyone saw David Litchfield's recent announcement of a new category of SQL attacks. (Full paper available at http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) He refers to this new category as lateral SQL injection attacks. It's very different than conventional SQL injection attacks, as well as quite a bit more limited. In the paper, he writes: Now, whether this becomes exploitable in the normal sense, I doubt it... but in very specific and limited scenarios there may be scope for abuse, for example in cursor snarfing attacks - http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf. In conclusion, even those functions and procedures that don’t take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and don’t let this type of vulnerability get into your code. The second lesson is that no longer should DATE or NUMBER data types be considered as safe and not useful as injection vectors: as this paper has proved, they are. It's definitely an interesting read, and anyone doing SQL coding should take a close look, IMHO. It's particularly interesting to see how he alters the DATE and NUMBER data types so that they can hold SQL injection data. Yet another demonstration of the importance of doing good input validation -- preferably positive validation. As long as you're doing input validation, I'd think there's probably no need to back through your code and audit it for lateral SQL injection vectors. Anyone else have a take on this new attack method? (Note that I don't normally encourage discussions of specific product vulnerabilities here, but most certainly new categories of attacks--and their impacts on secure coding practices--are quite welcome.) Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
