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