Re: [sqlmap-users] request for improvement/ howto/ usage in some special circumstances

[Bernardo D. A. G. <ber...@gm...>]

For the ones interested in this thread, my reply is on the
sqlmap-devel mailing list.

On Thu, Feb 19, 2009 at 09:42, Stiefenhofer, Marek
<M.S...@r-...> wrote:
> Dear all,
>
> I was working with sqlmap during the last 6 month in several penetration
> test projects. It's a really powerful tool and saved me sometimes a lot
> of hard work in exploiting SQL injection problems found in a large
> variety of web apps.
>
> Although I'm really excited about the features of sqlmap I consistently
> notice some limitations that might be easily worked around and would
> make a great improvement of the tool's value.
>
> In some cases I'm not sure if I just misunderstood something and the
> problems can already be worked around with correct usage of the tool. So
> here comes a summary of my problems and suggestions. Feel free to
> comment or point me to possible solutions.
>
> 1.) Dynamic parameter test
>
> I do understand that this test is needed to distinguish between
> potential injectable parameters and non-injectable ones. But when I tell
> the injectable parameter with -p this test should be omitted. There're
> lots of vulnerable apps where parameters that are injectable can't be
> confirmed with the current "dynamic tests".
>
>
> 2.) The dogma of the three different state results: non-injected,
> true-injected, false-injected
>
> The tool assumes that this three states result in different pages.
> That's not the case for many apps, i.e. most login-forms. Consider the
> following example PHP code, without error output to the client:
>
> $sql = "SELECT * FROM accounts WHERE username='".$_GET['username']."'
> and password = '".md5($_GET['password'])."'";
> $result = DB_query($dbconn, $sql) or die( 'Could not execute sql query'
> );
> if ($data = DB_fetch_array($result)) {
>  echo "Welcome you're logged in";
> }
> else {
>  echo "Login failed";
> }
>
> I know this one does not need blind sql injection. There are lots of
> other ways to misuse it, but it's just an example that I need to use for
> demonstrating some blind SQL injection issues. Let's see:
> To my knowledge you can't exploit the above example easily it with
> sqlmap, because non-injected pages (with wrong login data) and false
> injected pages produce the same result. Even --string won't help here
> (anyway a more flexible way to tell the tool how to distinguish between
> the three states would be great)
>
> Furthermore you need to guess a correct username to make any use of
> sqlmap, because you need to prefix the above statement with:
> existingusername'
> ...and an according postfix. This leads to the next problem:
>
>
> 3.) all statements are constructed with AND
>
> If sqlmap would also deal with OR statements, the above injection could
> be found (and hopefully exploited) without constructing correct prefix
> and suffix, example:
>
>
> True injection: username=' OR '1'='1
> False injection: username=' OR '1'='0
>
> I'm not sure about this last point, but I've found lots of examples in
> real world, where AND statements won't work at all. Does it make sense
> to include OR statements in the injection checker or am I just
> misunderstanding something?
>
>
>
> Again - I really appreciate the work that led to this tool. I'm looking
> forward for any comment/ clarification/ or acknowledgement from any user
> or developer.
>
>
> --Marek
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> sqlmap-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>
>



-- 
Bernardo Damele A. G.

E-mail / Jabber: bernardo.damele (at) gmail.com
Mobiles: +447788962949 (UK), +393493821385 (IT)
PGP Key ID: 0x05F5A30F