Lateral SQL injection paper

[arian.evans at anachronic.com (Arian J. Evans)]

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 <ken at krvw.com> 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