full-disclosure - Re: Deep Blind SQL Injection Whitepaper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ad2d22a80808280936r6b68f442weaa35a064bd4cf67@mail.gmail.com>
Date: Thu, 28 Aug 2008 11:36:23 -0500
From: nummish <nummish@...0.org>
To: "Ferruh Mavituna" <ferruh@...ituna.com>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Deep Blind SQL Injection Whitepaper

> 2008/8/19 David Litchfield <davidl@...software.com>
>>
>> Hi Ferruh,
>>
>>> This is a short whitepaper about a new way to exploit Blind SQL
>>> Injections.
>>
>> I just had a read of your paper. You open with: "If the injection point is
>> completely blind then the only way to extract data is using time based
>> attacks like WAITFOR DELAY, BENCHMARK etc." This is not the case. You can
>> use other non-time based (and therefore faster) methods to infer the value
>> of data. See "Data-mining with SQL Injection and Inference" -
>> http://www.ngssoftware.com/papers/sqlinference.pdf
>>
>> Cheers,
>> David
> On Tue, Aug 19, 2008 at 1:09 PM, Ferruh Mavituna <ferruh@...ituna.com> wrote:
> Hi David,
>
> I'm aware of the other methods which mostly explained on your paper.
> Footnote 2 which clears up the definition "completely blind" was supposed to
> be "No error is displayed and no indicators are visible in the response"
> instead of "No error is displayed and no indicators are visible in the
> response that an error occurred".
>
> Hopefully will update the paper soon, thanks for pointing it out.
>
> Cheers,

Sorry to resurrect a 9 day old thread here...

It's an interesting concept, but like all timing based attacks, won't
the digits be more susceptible to noise due to possible network
latency? Even with two queries, there is still a large volume of
requests getting made, and one little bump can invalidate the
information you are pulling out.

If that really isn't an issue, you may want to consider putting the 6
digit first, then 1,2,3,4,5,7,8,9 as that's going to show up far more
frequently.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/