Penetration Testing mailing list archives

Re: [PEN-TEST] sql injection with stored procedures


From: Brian Hinken <exploits () netbrian com>
Date: Thu, 15 Mar 2001 13:43:13 -0500

Try something like this as your injected variable:

par1 = foo', 'foo2', 'foo3'; alter procedure PROC_FOOBAR(foo varchar(1),foo2
varchar(1),foo3 varchar(1)) as select * from sysobjects --

This of course would be destructive, if it even works (I haven't tried), so
proceed with caution.

If it does work, you can play around with what you are changing the proc to,
then get whatever info you need.  In fact you would probably need to mess
around with it a bit so that the ASP app gets the field names it expects.


-----Original Message-----
From: Penetration Testers [mailto:PEN-TEST () SECURITYFOCUS COM]On Behalf
Of Cristiano Lincoln Mattos
Sent: Thursday, March 15, 2001 10:13 AM
To: PEN-TEST () SECURITYFOCUS COM
Subject: sql injection with stored procedures

Hi,
I'm working on a pen-test for a client -- basically, im in
a situation where his web app (ASP+SQLServer) does not validate the form
inputs,
making sql injection possible. What's making this trickier is
that the form inputs are parameters to stored procedures that
the app uses... and the SELECT calls are inside those procedures.
So, i can inject statements into the stored proc call, but
not into the select calls inside it, as using 's and the like is
not "carried" in to the procedure. An example:
PROC_FOOBAR 'par1', 'par2', 'par3'
inside this procedure is the real select call... but my input
forms are par1, par2 and par3. I can inject stuff, passing an
input of:
par1 = foo', 'foo2', 'foo3'; <select statement, exec, etc.> --
The foo2 and foo3 are just so that the stored proc doesn't
complain that it hasnt been passed all the parameters. That, as
would be expected, comes out to be:
PROC_FOOBAR 'foo', 'foo2', 'foo3'; <select, etc> -- 'par2', 'par3'
So, i can effectively inject code after the PROC_FOOBAR call,
including selects and execs of other stored procs.
The thing is, the ASP code that is calling this is only
expecting one recordset... so the results of what i injected are
not coming back to me on the page. I tried playing around with
's and "s to see if i could pass one to the SELECT *inside* the
store proc, but this only messed up its own parameters. Other
tricks like UNIONing with the injected select so that it comes back in one
recordset apparently do not work with stored procs.
So, is there a way to make these results come back to me? I
know that it is already a dangerous issue even without seeing the
results, but i would like to gather more info about the DB with
this. xp_cmdshell does not work, it is not running as privileged
user. I tried researching into sending the results of a query via
email through a stored proc, but apparently lots of MAPI configuration
is necessary on the SQL Server to enable this, and i obviously dont
have access (yet) to that kind of stuff.
Ideas in the above and following would be appreciated:
* Ways to display the info, considering that the ASP code
only expects and displays one recordset. Other methods
such as emailing, FTPing, using sockets, whatever, are
also appreciated.
* Usefull stored procedures that would allow me to gather
info on the system or somehow help me see the results
of what i am injecting. Note that i can gather much info
on the system using a few builtin stored procs, but it's
not very usefull if i cant see it. :)
I haven't seen this type of info around, so this could be
a helpfull discussion to many people. Any help appreciated.
Cristiano Lincoln Mattos, SSCP
CESAR - Centro de Estudos e Sistemas Avançados do Recife


Current thread: