Re: SQL Injection Question

["Kurt M.D John" <kurt.md.john () gmail com>]

Great Stuff Guys. Thank you so much. All of you were helpful

--Kurt M.D. John, CISA, C|EH, CPT

On 09/20/2010 09:57 AM, Jason Ross wrote:
> On Sun, Sep 19, 2010 at 8:36 PM, Kurt M.D John<kurt.md.john () gmail com>  wrote:
> > Hey Guys,
> >
> > take a look at the email below. I recently did a pentest and found that a
> > site was vulnerable to sql injection but it was minimal. The user which runs
> > the queries has read-only access and the information is public but an sql
> > injection still spits out the full table nonetheless.
>
> I'm not sure what you mean by that last bit. It could be taken at
> least 3 ways, and I'm not sure which you intended:
> 1. Do you mean that throwing the 1=1 into the form returns a database
> error message that reveals the table structure?
> 2 Do you mean that you were able to query the DBMS instance for table
> structure using SQL statements?
> 3. Do you mean that entering in the 1=1 results in a large number of
> rows being returned?
>
> If the first is correct, an error message is not the same as a SQL
> injection (though it often is the first sign of an injectable
> application.)
> If the second is correct, I think the rest of the question is already
> answered, and all you need to do is provide the SQL statements you
> used, along with the table information output, to prove the point.
> If the third is correct (which is the one I think you meant), then
> given the wildcard hardcoded in the SQL statement, a large number of
> rows is to be expected. However, the DBA is incorrect that SQL
> injection is not occuring. You have altered the query logic and
> appended additional SQL syntax.
>
> Where the query should be :
>     WHERE PROJECT.FOLIO_NBR LIKE 'some_input_data%'
>
> it has now become:
>     WHERE PROJECT.FOLIO_NBR LIKE '' or '1'='1%'
>
> These are two completely different SQL statements, and are processed
> in entirely different ways by the database engine.
> The actual structure of the query has changed, not just the data being
> searched for within the database.
>
>
> > The information below
> > is what the DB Admin sent me in defence of the potential vulnerability. My
> > question is, since it is vulnerable to sql injection can statements be
> > mutated to get dangerous results such as privilege escalation, etc. I am not
> > familiar with sql injection
>
>
> Since you are testing applications which use databases for security
> flaws, you should probably become familiar with SQL injection,
>
> If you need to prove that injection is occurring, try throwing
> comments into your injection, and look up using UNION and/or timing
> attacks to alter the data being returned. How you do this will vary
> based on the DBMS being used. Presuming Microsoft SQL server, comments
> could be added by appending two dashes to the end of your injected
> data.
>
> Using the example provided in your email, the parameter should become:
>     ' or '1'='1'--
>
> To answer your question of whether this could be used to get dangerous
> results, the answer is "it depends". Presuming that an actual
> injection was taking place, then it is very likely this could be
> leveraged to further an attack (at least to gain more useful
> information about the environment), but how much risk is actually
> present really varies based (at least) on what the database
> environment is, how it is configured, the data it contains, and how
> the application is set up to interact with it.
>
> --
> jason
>
>
> <snipping the remaining stuff>

------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT and CEPT certs require a full practical examination in order to become certified. 

http://www.iacertification.org
------------------------------------------------------------------------