[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48AC9B5B.1000609@sensepost.com>
Date: Thu, 21 Aug 2008 00:31:55 +0200
From: Marco Slaviero <marco@...sepost.com>
To: Ferruh Mavituna <ferruh@...ituna.com>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Deep Blind SQL Injection Whitepaper
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Ferruh Mavituna wrote:
| This is a short whitepaper about a new way to exploit Blind SQL
Injections.
| It's implemented in BSQL Hacker (
| http://labs.portcullis.co.uk/application/bsql-hacker/ ).
|
| *It is possible gather information from a target server with a 66%
reduction
| in the number of requests made of the server (compared to normal Blind SQL
| Injection), requiring two rather than six requests to retrieve each char.
| *
| *Download:
| *https://labs.portcullis.co.uk/download/Deep_Blind_SQL_Injection.pdf
|
|
|
| Regards,
[Already responded off-list, but for the benefit of those interested in
the various options for outbound channels in sql injection here's a
summary:]
The approach proposed is interesting as it reduces the number of
requests required to extract a byte, however it will probably increase
the total time required to extract a byte as compared with a bit-by-bit
approach. (Of course, in certain circumstances it's possible to extract
a byte in a single request if the database query or cgi doesn't timeout,
by waiting for the ordinal value of the character in question.)
The half byte technique (nibble technique?) could be a good thing, since
it would stand a greater chance of flying under threshold-based monitors
than a bit-by-bit approach, but would also decrease the speed of the attack.
For those interested in timing (errors/dns) as an outbound channel, we
wrote a paper last year along with a PoC tool. Both are accessible at
http://www.sensepost.com/research/squeeza/
We decided on the bit-by-bit approach as we tended to be less prone to
falling asleep while waiting for output as compared to other timing
strategies we attempted...
Regards
- --
marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREDAAYFAkism1sACgkQiAIcbqYz6hlx0QCfeQLTIWeYOur5hTE8WSrpWgzv
n24An0VJ/UB5HmOuZdrn0wgpadLeieyg
=RmrE
-----END PGP SIGNATURE-----
** CRM114 Whitelisted by: From marco@...sepost.com **
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists