SQL Injection - Stored Procedures

[Bã§TãRÐ]

I have been working on this particular project for a little over 2 weeks now. This product contains between 700-900 stored procedures to handle just about all you can imagine within the product. I
just personally rewrote/reformatted close to 150 of them myself. Nothing too fancy, mostly a lot of formatting. We have a little down time between Q/A and fixing any bugs they find so I decided to
test the security of the site with Cross-Site Scripting and SQL injection. Because SP's are used in pretty much every aspect of the site, the site isnt vunerable to the simple Injection stuff like '
OR 1 = 1 . Instead I've had to try several things which I will get to in a minute. As I have access to all of these SP's and the dB in which they reside, I could easly look at the code and determine
what variables are neede to pass in. I've been trying to break the site to give up a database name so I can proceed to check the system tables etc etc - much like a regular hacker would (meaning not
cheating by looking at the code). So, I've started my attack by downloading a local version of the login page, changing a few variables and injected somthing like:
'SELECT * FROM INFORMATION_SCHEMA.TABLES

Initially, the statement is passed into the form fields and wont return anything other than a JS popup error. I altered the statement intentionally to break the page
SELECT * FROM INFORMATION_SCHEMA.TA'

and it produces an error giving me the name of the query and its location
when I plug the name of the query in the url i.e http://theurl.com/query_folder/query_name/ it fires me off to another folder containing an include file of some sort.
When I run that include it gives me the name of a pretty important variable. Apparetly its a variable that determins what dB I should point to.

Now, one of the issues I have is that everything is a stored procedure so trying to hack it is a little more difficult. But because I have the SP name and one of the variables its needs (found through
lots of testing) I've been trying to construct something that will throw an error to produce a dB or table name. The attack looks something like this:
'SET @var2Exec = 'DECLARE @var1 VARCHAR(2000); DECLARE @var2 INT SET @var1 = ''SELECT * FROM INFORMATION_SCHEMA.TABLES'' SET @var2 = 12345 ; EXEC(@var1)'
'EXEC(@var2Exec)'

I will always return an error saying that @var2 is of the wrong type etc. Essentially this means that I am passing in 2 variables to a SP that requires more than 2. So my question is, does anyone know
of a way to exploit the nature of Stored Procedures? It can be done, but my knowledge of SQL Injection is pretty limited but was wondering if anyone tests their own sites in this manner. Any
suggestions would be greatly appreciated.

 

[Bã§TãRÐ]

On another note I've read a few posts that others have had dealing with SQL Injection. Honestly there are 2 things you should be concerend about. SQL Injection and Cross Site Scripting. Often they are
used in combination with one another.

SQL Injection is most easily defeated using regular expressions to validate all of your data. While JavaScript is fast, Server Side is better, especially when validating for sensative data. You can
strip out most characters that make SQL injection easier. You wouldnt ever have a " or a ' in a password field, so why allow it? Regular Expressions can easly shut down an attack. Another way is to
set up a custom error page. Why give the attacker any more information than needed. If an error is detected - fire them off to a custom error page that says sorry we cannot .... dont give them access
to the ODBC errors that list the table names etc. Its not fool proof but it closes another open door to an attacker.

Cross Site Scripting or CSS is the ability for a person to download a local copy of the form or even a cookie, alter its contents, and then submit it from their browser to the live site. This can be
an issue (especially in shopping carts) where an attacker can submit a false value to your form processor. The data will be valid but its value is wrong. I deal with this by checking where the
referral page is. Especially when dealing with shopping carts Page 1 will be sent to Page 2 - Page 2 checks to see if the info came from Page 1 or originated somewhere else.

These are a few really simple things I do to help keep my sites safer. You should really learn to hack your own sites. It makes you a better coder in the end.

P.S. it is possible to exploit Stored Procs - but it takes a hell of a long to time to do it.

~Bastard

 

[Dave Anderson]

that requires more than 2. So my question is, does anyone know of a
way to exploit the nature of Stored Procedures? It can be done, but
my knowledge of SQL Injection is pretty limited but was wondering if
anyone tests their own sites in this manner. Any suggestions would be
greatly appreciated.

One of the values you get from stored procedures is resistence to SQL
injection. I say resistence instead of protection because you can still
expose yourself to risk if you do something dumb like this:

EXEC @DynamicSQLBuiltInMyProcedure

Without dynamic execution, parameters insulate you from injection. One thing
I note is that you have not provided details on your interface. How you
construct your SP call is a potential point of vulnerability, such as:

CN.Execute("MySP " + ParameterList)


Also, a bit of error handling goes a long way toward protecting the details
of your scripts and your DB:

try {
RS = CN.Execute( ... )
} catch(e) {
SendErrorEmail(e)
Page.Message = "Error accessing data"
}


All examples in JScript, obviously.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

SQL Injection is most easily defeated using regular
expressions to validate all of your data.

Not really. I can use ADODB.Command and NEVER validate any data, and still
be 100% protected from SQL injection.

While JavaScript is fast, Server Side is better,
especially when validating for sensative data.

If you are going to validate at all, you must do it on the server. Doing it
on the client is an acceptible complement to server-side validation, but it
can never replace it for any reason.

You wouldnt ever have a " or a ' in a password field,
so why allow it?

WTF are you talking about? I use " and ' in passwords all the time, not to
mention > and < (one of our vendor apps disallows these, to my great
annoyance). Forbidding those characters is an advertisement of your own fear
and incompetence. IMO, the data in the DB should be the data entered by the
user, subject to the constraints of the DATA TYPE (not by your programming
limitations).

I deal with this by checking where the referral page is.
Especially when dealing with shopping carts Page 1 will be sent to
Page 2 - Page 2 checks to see if the info came from Page 1 or
originated somewhere else.

Easily defeated: http://livehttpheaders.mozdev.org/

P.S. it is possible to exploit Stored Procs - but it takes
a hell of a long to time to do it.

On the contrary. I find it easy to make stored procedures unexploitable. The
first 5 things that some to mind:
1. Take away SELECT, UPDATE and INSERT rights from your application's SQL
Login. Grant execution permission on a procedure-by-procedure basis
2. Use error handling
3. Coerce values into their expected sub-types before assigning to
parameters
4. Use ADODB.Command objects (or at least escape single quotes for string
parameters)
5. Swear off dynamic SQL string construction and execution forever


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Bob Barrows [MVP]]

I have been working on this particular project for a little over 2
weeks now. This product contains between 700-900 stored procedures to
handle just about all you can imagine within the product. I just
personally rewrote/reformatted close to 150 of them myself. Nothing
too fancy, mostly a lot of formatting. We have a little down time
between Q/A and fixing any bugs they find so I decided to test the
security of the site with Cross-Site Scripting and SQL injection.

If you pass arguments via the Parameters collection of the Command object,
or using the procedure-as-connection-method technique
(http://tinyurl.com/jyy0), and you do not use the parameters to build
dynamic sql statements inside your stored procedures, then you are
invulnerable to sql injection. Period. SQL Injection depends on the use of
dynamic sql. Without dynamic SQL, there can be no SQL Injection. More:

http://mvp.unixwiz.net/techtips/sql-injection.html
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf


Validation techniques can be defeated, although the time it takes a hacker
to defeat them may cause him to move on to a more vulnerable site. So:
always validate in server-side code to avoid CSS exploits. Client-side
validation should supplement the server-side validation, not replace it. The
only reason to use client-side validation is to provide a better user
experience, allowing data entry errors to be causght immediately rather than
after submission.

Bob Barrows

 

[Bã§TãRÐ]

Most of the formatting I did with this project was to take these Huge Dynamic SP's and de-dynamicise them into compiled queries. This meant taking the branching logic and hardcoding all of the
possible combinations for that query. This was done because:
1. Some of these SP's are hit over 1 million times a year. That is a huge amount of overhead on the Server, this server contains 2,000 databases.
2. The branching logic If ElseIf Else slows things down with dynamic queries that are close to 200 lines long and have 2 dynamic elements in them.
3. Some of the SP's were returning temp tables full of information in the dynamic portion of it.

Dynamic SQL makes for nice looking coding but in the case of this project, we took a Dynamic SQL SP and compiled several children SP's and referenced it from a Parent SP. The result was a SP that took
over 1 minute to compile to one that ran in less than 1 sec. So the benefits to compiled Queries is considerable, but a little harder to maintain.

Now I know that these queries that I am trying to hack have variables passed into them. So

the SP would liike
Create proc 1
@var INT
AS etc etc.....

The idea of the attack is to pass in another variable that contains the SQL statement. The idea being that @var1 is set to equal something in the SP. If I could make it equal the SQL statement I am
passing it, it should begin to open up some information for me. That is what I'm currently trying to accomplish. I've already read 3 of the links you gave in their entirety.

A little goes a long way when dealing with SQL Injection and Cross Site Scripting (which doesnt seem to get too many people concerned for some reason). Yes, while validation is not fool proof, very
few things are in this world are, but at the same time the benefits of doing it over not doing it are considerable. There is no reason what so ever that you would want to leave those doors open.

I'll let you know more about the process if anything new comes up.

~Bastard

 

[Bã§TãRÐ]

Not really. I can use ADODB.Command and NEVER validate any data, and still
be 100% protected from SQL injection.

You have to realize that alot of the poeple here are not SQL experts. Most everyone learned SQL by creating these dynamically built SQL strings including myself. I've just recently started working
with SP's. RegularExpressions are a great defense against SQL injection and a great way to validate data before it goes into the dB. Just because you validate your data in the SQL (if you even do
that) just means you have to write more SQL and depending on what you're doing with it could slow things down. The idea of building a secure website is closing open doors, and layering the
protections. The more layers the less likely an attacker is going to stick around.

If you are going to validate at all, you must do it on the server. Doing it
on the client is an acceptible complement to server-side validation, but it
can never replace it for any reason.
Agreed

WTF are you talking about? I use " and ' in passwords all the time, not to
mention > and < (one of our vendor apps disallows these, to my great
annoyance). Forbidding those characters is an advertisement of your own fear
and incompetence. IMO, the data in the DB should be the data entered by the
user, subject to the constraints of the DATA TYPE (not by your programming
limitations).

Its easy to say WTF on something like this, especially if you work on sites with a small user base and they have an inkling of what they are doing in life. However, this particular project and many I
have had in the past have a user base of 500,000+ users. The #1 call tech support gets is What is my password? It is generally thought that to keeps costs and the amount of phone calls down, limiting
the characters allowed in the PW field to numbers and characters was the user friendly way to handle it.

Easily defeated: http://livehttpheaders.mozdev.org/

So I suppose, you would just rather not do it? Just leave that door wide open and allow an attacker to CSS your site because something can be easily defeated so you say? No site will ever been
bulletproof. But I think its wrong to say Dont do something because its easily defeated or takes a special tool to do so.

On the contrary. I find it easy to make stored procedures unexploitable. The
first 5 things that some to mind:
1. Take away SELECT, UPDATE and INSERT rights from your application's SQL
Login. Grant execution permission on a procedure-by-procedure basis
2. Use error handling
3. Coerce values into their expected sub-types before assigning to
parameters
4. Use ADODB.Command objects (or at least escape single quotes for string
parameters)
5. Swear off dynamic SQL string construction and execution forever

Not all developers are dB admins. In fact is most case I've been involved with, the dB servers are run by other people, some smart (will limit who can run what SP, preventing escalation) and others
are not (in one case cant even set up a FTP server properly) so it depens on the environment you're working in. Suggestion # 1 is a valid point but inpractical in my case 700-900 stored procedures and
#5 I'm working on! Thanks for the help.

!Bastard

 

[Jeff Cochran]

A little goes a long way when dealing with SQL Injection and Cross Site Scripting (which doesnt seem to get too many people concerned for some reason).

Cross-site scripting defenses are usually somewhat trivial to defeat.
It's tough to do more then check the referrer, but that's not too hard
to spoof. Storing critical variables server-side and using sessions
can reduce many of the benefits of cross-site scripting too.

Yes, while validation is not fool proof, very
few things are in this world are, but at the same time the benefits of doing it over not doing it are considerable.

The primary purpose of input validation is data integrity, not
security. That's not to say it isn't of use in helping secure an app,
but it can't be the only thing you do to provude for a secure
environment.

That said, validation should always take place on both the client and
the server. Some validation techniques work better in one place or
the other, but heading off user input errors at the client is far more
efficient than using the server.

Jeff

 

[Dave Anderson]

You have to realize that alot of the poeple here are not SQL experts.
Most everyone learned SQL by creating these dynamically built SQL
strings including myself. I've just recently started working with
SP's.

My comments directly rebut your "most easily defeated" assertion, and do not
attempt to disparage data validation.

As a side note, exact preservation of the original input data is
occasionally not only preferable, but *required* (regulatory or liability
reasons, for example). The requirement to preserve the original, in effect,
forbids validation. So how are you going to protect yourself from SQL
injection if validation is off the table?

RegularExpressions are a great defense against SQL injection
and a great way to validate data before it goes into the dB. Just
because you validate your data in the SQL (if you even do that) just
means you have to write more SQL and depending on what you're doing
with it could slow things down.

Again, I never said not to validate data before sending it to the database.
I just don't think regular expressions should be your last line of defense.

The #1 call tech support gets is What is my password? It is generally
thought that to keeps costs and the amount of phone calls down,
limiting the characters allowed in the PW field to numbers and
characters was the user friendly way to handle it.

This "hacker's wet dream" horrifies me on so many levels. Passwords are
inconvenient, so let's not make 'em too tough to remember.

So I suppose, you would just rather not do it?

Yes. I would not do it. I would rather assume the user can change *ANYTHING*
in the request.

I think its wrong to say Dont do something because
its easily defeated or takes a special tool to do so.

1. I do not consider Firefox extensions "special tools" as much as browser
features, many of which will find their way into all manner of future
browsers.

2. I think the use of HTTP_REFERER for security is a bad practice because it
lends a false sense of security despite having no reliability whatsoever. I
can absolutely think of good uses for it, but they *enhance* or *supplement*
the user's experience rather than impede it.

Not all developers are dB admins. In fact is most case I've been
involved with, the dB servers are run by other people, some smart
(will limit who can run what SP, preventing escalation) and others
are not (in one case cant even set up a FTP server properly) so it
depens on the environment you're working in. Suggestion # 1 is a
valid point but inpractical in my case 700-900 stored procedures and
#5 I'm working on!

If the developer is not a DBA, then someone else certainly is. And I
guarantee that DBA would like nothing better than removing SELECT, INSERT
and UPDATE from the web application's login -- and almost certainly would
prefer to be an essential part of the change management/migration process.

And FWIW, db_securityadmin is sufficient in SQL Server for the developer to
manage SP permissions. DBA is overkill.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Bã§TãRÐ]

Its obvious Dave Anderson and I disagree on some things but thats OK. It's what, makes this kind of forum the way it is. After some considerable testing today on the nature of Stored Procedures and
applying an Injection attack, I've exposed an exploit that isn't from a buffer overflow or a security hole in the SQL Server application itself but more along the lines of taking advantage of SQL and
stored procs. The exploit deals with permission settings on the SP's themselves. Now if you've been paying attention to this thread at all, you'll notice that Dave limits the permissions on the SP's
and I'm sure that some other DBA's follow suit. However, I am also sure that there is a large portion of the world that doesn't, as you may have noticed the spread of the Slammer virus using 'sa'
password to propagate itself. Whether it be laziness, incompetence or what ever, I'm sure there are literally thousands of server running millions of SP's without any regard to permissions. With that
in mind this makes anything you try a pretty likely event it will succeed. But also bear in mind that certain things also need to be in place, like the site has to be vulnerable to CSS attacks etc
etc.

I wont go into details but will more or less outline the beginning of what I think is a proof of concept. Granted my knowledge of SP's is pretty limited so bear with me:

The proof of concept is as follows.

I CSS the site exposing the name of a SP dealing with login information.
get_user_login_info

So, this particular SP will accept VARCHAR for username and password.

Step 1:
I've created a dynamic SQL statement that will create a Stored Procedure with the same name of the one that was exposed.

SET @var = 'CREATE STORED PROCEDURE.....'
SET @vat + @var = 'SELECT * FROM INFORMATION_SCHEMA.TABLES'
etc etc...

Step 2: I've created a Delete SP statement that I will Inject into the SQL
EXEC get_user_login_info 'delete procedure [dbo].[get_user_login_info]'

Step 3:
I fire the EXEC statement at itself telling to delete itself. (This actually happened today while testing.)
You can tell a SP to delete itself. Where the exploit per say comes into play.
This could easily be defeated by restricting permissions on the SP, but bear in mind that my guess is most people wouldn't do that for any number of reasons making it pretty readily available.

Step 4:
Continuing with the delete statement, you Execure the dynamic query that you made earlier, after you delete the original stored Procedure.

Because the web page is always calling the SP, you essentially deleted the original SP, and created one of your own, with your own variables, and would be able to access the SCHEMA tables or anything
else for that matter via your dynamic SQL statement. The combination of deleting and re-writing the SP would allow you access to anything in the database. Again, all of your ducks would have to be in
a row with permissions etc but again this is more of a proof of concept anyhow.


Any feedback?
~Bastard

 

[Bob Lehmann]

Would it kill you to set your mail to wrap at a reasonable number of
characters? It is almost impossible to read your posts without resizing the
window.

Bob Lehmann

Its obvious Dave Anderson and I disagree on some things but thats OK. It's

what, makes this kind of forum the way it is. After some considerable
testing today on the nature of Stored Procedures and

applying an Injection attack, I've exposed an exploit that isn't from a

buffer overflow or a security hole in the SQL Server application itself but
more along the lines of taking advantage of SQL and

stored procs. The exploit deals with permission settings on the SP's

themselves. Now if you've been paying attention to this thread at all,
you'll notice that Dave limits the permissions on the SP's

and I'm sure that some other DBA's follow suit. However, I am also sure

that there is a large portion of the world that doesn't, as you may have
noticed the spread of the Slammer virus using 'sa'

password to propagate itself. Whether it be laziness, incompetence or what

ever, I'm sure there are literally thousands of server running millions of
SP's without any regard to permissions. With that

in mind this makes anything you try a pretty likely event it will succeed.

But also bear in mind that certain things also need to be in place, like the
site has to be vulnerable to CSS attacks etc

etc.

I wont go into details but will more or less outline the beginning of what

I think is a proof of concept. Granted my knowledge of SP's is pretty
limited so bear with me:

The proof of concept is as follows.

I CSS the site exposing the name of a SP dealing with login information.
get_user_login_info

So, this particular SP will accept VARCHAR for username and password.

Step 1:
I've created a dynamic SQL statement that will create a Stored Procedure

with the same name of the one that was exposed.

SET @var = 'CREATE STORED PROCEDURE.....'
SET @vat + @var = 'SELECT * FROM INFORMATION_SCHEMA.TABLES'
etc etc...

Step 2: I've created a Delete SP statement that I will Inject into the SQL
EXEC get_user_login_info 'delete procedure [dbo].[get_user_login_info]'

Step 3:
I fire the EXEC statement at itself telling to delete itself. (This

actually happened today while testing.)

You can tell a SP to delete itself. Where the exploit per say comes into play.
This could easily be defeated by restricting permissions on the SP, but

bear in mind that my guess is most people wouldn't do that for any number of
reasons making it pretty readily available.

Step 4:
Continuing with the delete statement, you Execure the dynamic query that

you made earlier, after you delete the original stored Procedure.

Because the web page is always calling the SP, you essentially deleted the

original SP, and created one of your own, with your own variables, and would
be able to access the SCHEMA tables or anything

else for that matter via your dynamic SQL statement. The combination of

deleting and re-writing the SP would allow you access to anything in the
database. Again, all of your ducks would have to be in

a row with permissions etc but again this is more of a proof of concept anyhow.


Any feedback?
~Bastard

 

[Roland Hall]

: 1. I do not consider Firefox extensions "special tools" as much as browser
: features, many of which will find their way into all manner of future
: browsers.

Sure. A browser was not developed originally to be an offensive type of
application to test security. This is special. While it may find its way
into other browsers in the future, it is not the norm for a browser.
Perhaps they will add surf-n-smell abilities and whenever you hit a site in
Italy, you smell garlic! Scary if they eventually apply that to porn sites.
*yikes!* That may make its way into other browsers also but it would be a
special tool or special feature, outside the norm, at least at first.

: 2. I think the use of HTTP_REFERER for security is a bad practice because
it
: lends a false sense of security despite having no reliability whatsoever.
I
: can absolutely think of good uses for it, but they *enhance* or
*supplement*
: the user's experience rather than impede it.

Then a firewall is pointless since so many can defeat them. It's a wall
with holes. Surely you believe in multiple levels of defense. Just because
someone knows a way past certain security measures does not mean they know a
way past all of them or that they will not be discouraged or that they might
reveal themselves if they keep attacking. After all, not all have the Kevin
Mitnick arrogance to tease their victim nor do they usually attack directly
until all line of defenses have been accounted for. If you have to
determine what to do once you get to the front door, you're gonna' get shot
by the home owner.

There is no reason to use a browser to compromise a network on the Internet.
While the Universal Directory Traversal Exploit allowed for a browser to be
used, most attacks were not with browsers.

: If the developer is not a DBA, then someone else certainly is. And I
: guarantee that DBA would like nothing better than removing SELECT, INSERT
: and UPDATE from the web application's login -- and almost certainly would
: prefer to be an essential part of the change management/migration process.

Not all companies have DBAs and there are a lot more web sites run by
individuals than companies. It appears you are limiting your discussion to
large organizations. And security is not the primary role of a DBA.
Database administration and network security are entirely different roles
although some areas may cross and both are more than one person can do
alone, especially if the network is large.

Just my $.02.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

in message
: Would it kill you to set your mail to wrap at a reasonable number of
: characters? It is almost impossible to read your posts without resizing
the
: window.

How about that top posting? (O:=

The lines are past the unofficial 72 character limit but the text wraps just
fine on my screen. Are you having to scroll horizontally? Admittedly my
news reader is maximized and my resolution is 1024x768.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Dave Anderson]

Sure. A browser was not developed originally to be an offensive type
of application to test security. This is special. While it may find
its way into other browsers in the future, it is not the norm for a
browser. Perhaps they will add surf-n-smell abilities and whenever
you hit a site in Italy, you smell garlic! Scary if they eventually
apply that to porn sites. *yikes!* That may make its way into other
browsers also but it would be a special tool or special feature,
outside the norm, at least at first.

I guess you don't consider features like popup-blocking or password saving
in that bunch. Or the fact that virtually every browser (except IE) allows
you to choose a different UserAgent string...

Not all companies have DBAs and there are a lot more web sites run by
individuals than companies. It appears you are limiting your
discussion to large organizations. And security is not the primary
role of a DBA. Database administration and network security are
entirely different roles although some areas may cross and both are
more than one person can do alone, especially if the network is large.

Uh - read the thread again. He was making the point that some developers
don't have the kind of access to the DB necessary to create stored
procedures and assign permissions to them. The one guy wearing multiple hats
has everything he needs, so my response accordingly was to his "not every
developer is a DBA" comment.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Dave Anderson]

...the site has to be vulnerable to CSS attacks etc etc.

I really think you mean XSS attacks.


[regarding his SQL injection example]

Any feedback?

Perhaps five years ago there would have been a great number of sites
vulnerable to this type of attack. Maybe even two years ago - I could not
say. But it has been nearly impossible to be unaware of your blank sa
password in SQL Server since SP3.

Your exploit doesn't really care about the sa password, though. It only
cares that the web application uses a login with sufficient permissions to
modify information_schema.tables. And like the blank sa password, that is
presumably becoming a rare animal.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Roland Hall]

in message
: Roland Hall wrote:
: >> 1. I do not consider Firefox extensions "special tools" as much as
: >> browser features, many of which will find their way into all manner
: >> of future browsers.
: >
: > Sure. A browser was not developed originally to be an offensive type
: > of application to test security. This is special. While it may find
: > its way into other browsers in the future, it is not the norm for a
: > browser. Perhaps they will add surf-n-smell abilities and whenever
: > you hit a site in Italy, you smell garlic! Scary if they eventually
: > apply that to porn sites. *yikes!* That may make its way into other
: > browsers also but it would be a special tool or special feature,
: > outside the norm, at least at first.
:
: I guess you don't consider features like popup-blocking or password saving
: in that bunch. Or the fact that virtually every browser (except IE) allows
: you to choose a different UserAgent string...

I wasn't aware it was "virtually every" browser and don't get me started on
IE. If MSFT doesn't do something soon with this dinosaur I'm going to start
looking for exploits to force their hand.

: > Not all companies have DBAs and there are a lot more web sites run by
: > individuals than companies. It appears you are limiting your
: > discussion to large organizations. And security is not the primary
: > role of a DBA. Database administration and network security are
: > entirely different roles although some areas may cross and both are
: > more than one person can do alone, especially if the network is large.
:
: Uh - read the thread again. He was making the point that some developers
: don't have the kind of access to the DB necessary to create stored
: procedures and assign permissions to them. The one guy wearing multiple
hats
: has everything he needs, so my response accordingly was to his "not every
: developer is a DBA" comment.

Ok, first, I'm not taking sides one way or the other across the board. I've
seen many situations and sometimes someone wears many hats and sometimes his
legs are cut off. I'm not a DBA but yet I'm a developer. However,
development is not my primary focus. I'm focus on interconnectivity,
network design and security. Development just happens to be paying most of
the bills right now. The guy wearing multiple hats may have everything he
needs but he may not have all the knowledge he needs. I thought that was
the point he was making but I've been wrong before.

I do however disagree that passwords should be easy to please the users.
That's nothing more than politics. These people can remember how to drive
to work each day yet cannot remember their password if it's not their
child's birthday? That is allowed when there are no policies and
procedures, they're ignored or a few don't have to play by the rules (see
upper management and their croanies or the squeaky wheel gets the grease).
The result, another happy hacker.

 

[Bã§TãRÐ]

First of all, you whiners complaining about scrolling to read my posts. DEAL WITH IT. So far you have contributed nothing of value to this thread, so until you do so. F-off and deal with it. Now back
to the users who are concerned or even interested in such knowledge.

Thanks Dave for pointing out my imporper user of CSS when I have meant XSS all along. Its actually amazing you are the only one who picked up on that. Just goes to show that its still new terrortory
to a lot of people.

"But it has been nearly impossible to be unaware of your blank sa password in SQL Server since SP3." I was not using the "sa" and blank PW as a form of attack. Insead, the Slammer and "sa" deal was
used as an example to illustrate the mindset of a lot of users when dealing with SQL security. (every 8 seconds or so, it would double in size (amount of infection) and it holds the record as the
fastest propogating virus of all time) Yes, not everyone can be as protective as D Anderson.. (I' d say he is in the minority as far as his security measures). Consider Mitnick and his social
engineering, we can make some assumptions of DBA's (real or thrust into the position) and their laziness... etc... etc.... Anderson seems to be very considerate when it comes to securing a site, it
seems as though he has been through some sh*t in the past (or really just pays attention). However, I'd say there are quite a few more people who arent as considerate as he is for any number of
reasons. It is these people who would find themselves in a world of hurt with my proposed attack.

The attack focuses not on the any sort of pasword whatsoever, but the knowledge of how SP's run in general. As you noticed, I dont make any reference to passwords. What I am trying to illustrate, is
that through the open permissions of the generic web user - I can delete and re-write anyones SP's to do what I want.

The attack outlined again below: [ Edited for clarity ]

I XSS the site, exposing the name of a SP dealing with login information.
i.e. get_user_login_info

So, this particular SP will accept VARCHAR for username and password (most do in this case)

Step 1:
I've created a dynamic SQL statement that will create a Stored Procedure with the same name of the one that was exposed while using XSS and malfomed SQL statements meant to "break" the page into
giving me some much needed information.. The first of the statements would look something like.

SET @var = 'CREATE STORED PROCEDURE.....'
SET @vat + @var = 'SELECT * FROM INFORMATION_SCHEMA.TABLES'
etc etc...

Step 2: I've created a Delete SP statement that I will Inject into the SQL through the XSS exploit I've uncovered. The delete SP statement would look soemthing similar to:
EXEC get_user_login_info 'delete procedure [dbo].[get_user_login_info]'

Step 3:
I fire the EXEC statement at itself telling to delete itself. (This actually happened today while testing.)
You can tell a SP to delete itself. Where the exploit (per say) comes into play. Lazines, incompetence, ignorance etc.. any number of reasons could account for the "LACK" of permissions applied to a
particular SP. By lack I mean they (users) are free (i.e sh*t is pretty much wide open) , to do whatever they want. In Dave Andersons case, a few minor adjustments will restrict what a user is allowed
to do while running a SP, but bear in mind that my guess is most people wouldn't do that for any number of reasons making it pretty readily available.

Step 4:
Continuing with the delete statement, you Execure the dynamic query that you made earlier, after you delete the original stored Procedure.

Because the web page is always calling the SP, you essentially deleted the original SP (removing any variables passed into it), and created one of your own, with your own variables, statements, or
logic and as a result, you would be able to access the SCHEMA tables or anything else for that matter via your dynamic SQL statement. Bear in mind, I'm thinking like a hacker would. There is a list of
things I would go throught o get the information I wanted. Schema Tables, Table Names, Column Names, etc etc,

This combination of deleting and re-writing the SP (completely viable in a real world situation, again depending on permissions) would allow you access to anything in the database. Again, all of your
ducks would have to be in a row with permissions etc but again this is more of a proof of concept anyhow.


Any feedback on the method of attack was what I was looking for, not any comments on email formatting. While Dave and I may not see eye to eye - atleast he provides some relavant feedback on the
process. Follow his lead!

~Bastard

...the site has to be vulnerable to CSS attacks etc etc.

I really think you mean XSS attacks.


[regarding his SQL injection example]

Any feedback?

Perhaps five years ago there would have been a great number of sites
vulnerable to this type of attack. Maybe even two years ago - I could not
say. But it has been nearly impossible to be unaware of your blank sa
password in SQL Server since SP3.

Your exploit doesn't really care about the sa password, though. It only
cares that the web application uses a login with sufficient permissions to
modify information_schema.tables. And like the blank sa password, that is
presumably becoming a rare animal.

 

[Bã§TãRÐ]

in message
: Roland Hall wrote:
: >> 1. I do not consider Firefox extensions "special tools" as much as
: >> browser features, many of which will find their way into all manner
: >> of future browsers.
: >
: > Sure. A browser was not developed originally to be an offensive type
: > of application to test security. This is special. While it may find
: > its way into other browsers in the future, it is not the norm for a
: > browser. Perhaps they will add surf-n-smell abilities and whenever
: > you hit a site in Italy, you smell garlic! Scary if they eventually
: > apply that to porn sites. *yikes!* That may make its way into other
: > browsers also but it would be a special tool or special feature,
: > outside the norm, at least at first.
:
: I guess you don't consider features like popup-blocking or password saving
: in that bunch. Or the fact that virtually every browser (except IE) allows
: you to choose a different UserAgent string...

I wasn't aware it was "virtually every" browser and don't get me started on
IE. If MSFT doesn't do something soon with this dinosaur I'm going to start
looking for exploits to force their hand.

: > Not all companies have DBAs and there are a lot more web sites run by
: > individuals than companies. It appears you are limiting your
: > discussion to large organizations. And security is not the primary
: > role of a DBA. Database administration and network security are
: > entirely different roles although some areas may cross and both are
: > more than one person can do alone, especially if the network is large.
:
: Uh - read the thread again. He was making the point that some developers
: don't have the kind of access to the DB necessary to create stored
: procedures and assign permissions to them. The one guy wearing multiple
hats
: has everything he needs, so my response accordingly was to his "not every
: developer is a DBA" comment.

Ok, first, I'm not taking sides one way or the other across the board. I've
seen many situations and sometimes someone wears many hats and sometimes his
legs are cut off. I'm not a DBA but yet I'm a developer. However,
development is not my primary focus. I'm focus on interconnectivity,
network design and security. Development just happens to be paying most of
the bills right now. The guy wearing multiple hats may have everything he
needs but he may not have all the knowledge he needs. I thought that was
the point he was making but I've been wrong before.

No, this is exactly the point I was making. Thanks.

I do however disagree that passwords should be easy to please the users.
That's nothing more than politics. These people can remember how to drive
to work each day yet cannot remember their password if it's not their
child's birthday? That is allowed when there are no policies and
procedures, they're ignored or a few don't have to play by the rules (see
upper management and their croanies or the squeaky wheel gets the grease).
The result, another happy hacker.

I agree, like I mentioned before, this particular situation (and many before it) I've had to limit the PW security because for something like this for you and I is second hat. For avarage joe user
this is a monumental effort. Multiply that by 500,000 times and you have a workd of hurt on your end. Aslo think of the amout of people you'd have to hire (as a company) to deal with lost password
functionality and other related issues. This goes back to the point where Anderson and I were arguing. Every situation that you, I and him ill come across will be different. The best we can do is
apply our knowledge to the solution at hand and hope that it will survive the test of time.

Now while I appreciate all the comments on this thread, We're a bit off track - SQL Injection of Stored Procedures!!!!

~Bastard

 

[Patrice]

EXEC get_user_login_info 'delete procedure [dbo].[get_user_login_info]'
should do anything ???

What is the code for get_user_login_info ?

Patrice



--

Its obvious Dave Anderson and I disagree on some things but thats OK. It's

what, makes this kind of forum the way it is. After some considerable
testing today on the nature of Stored Procedures and

applying an Injection attack, I've exposed an exploit that isn't from a

buffer overflow or a security hole in the SQL Server application itself but
more along the lines of taking advantage of SQL and

stored procs. The exploit deals with permission settings on the SP's

themselves. Now if you've been paying attention to this thread at all,
you'll notice that Dave limits the permissions on the SP's

and I'm sure that some other DBA's follow suit. However, I am also sure

that there is a large portion of the world that doesn't, as you may have
noticed the spread of the Slammer virus using 'sa'

password to propagate itself. Whether it be laziness, incompetence or what

ever, I'm sure there are literally thousands of server running millions of
SP's without any regard to permissions. With that

in mind this makes anything you try a pretty likely event it will succeed.

But also bear in mind that certain things also need to be in place, like the
site has to be vulnerable to CSS attacks etc

etc.

I wont go into details but will more or less outline the beginning of what

I think is a proof of concept. Granted my knowledge of SP's is pretty
limited so bear with me:

The proof of concept is as follows.

I CSS the site exposing the name of a SP dealing with login information.
get_user_login_info

So, this particular SP will accept VARCHAR for username and password.

Step 1:
I've created a dynamic SQL statement that will create a Stored Procedure

with the same name of the one that was exposed.

SET @var = 'CREATE STORED PROCEDURE.....'
SET @vat + @var = 'SELECT * FROM INFORMATION_SCHEMA.TABLES'
etc etc...

Step 2: I've created a Delete SP statement that I will Inject into the SQL
EXEC get_user_login_info 'delete procedure [dbo].[get_user_login_info]'

Step 3:
I fire the EXEC statement at itself telling to delete itself. (This

actually happened today while testing.)

You can tell a SP to delete itself. Where the exploit per say comes into play.
This could easily be defeated by restricting permissions on the SP, but

bear in mind that my guess is most people wouldn't do that for any number of
reasons making it pretty readily available.

Step 4:
Continuing with the delete statement, you Execure the dynamic query that

you made earlier, after you delete the original stored Procedure.

Because the web page is always calling the SP, you essentially deleted the

original SP, and created one of your own, with your own variables, and would
be able to access the SCHEMA tables or anything

else for that matter via your dynamic SQL statement. The combination of

deleting and re-writing the SP would allow you access to anything in the
database. Again, all of your ducks would have to be in

a row with permissions etc but again this is more of a proof of concept anyhow.


Any feedback?
~Bastard

 

[Jeff Cochran]

First of all, you whiners complaining about scrolling to read my posts. DEAL WITH IT. So far you have contributed nothing of value to this thread, so until you do so. F-off and deal with it. Now back
to the users who are concerned or even interested in such knowledge.

Plonk.

Jeff