SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


A Hex on Your Database


A Hex on Your Database

Author
Message
Mike C
Mike C
SSCertifiable
SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)SSCertifiable (6.5K reputation)

Group: General Forum Members
Points: 6477 Visits: 1172
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"



style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]




This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though Smile


Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.
davidthegray
davidthegray
SSC Veteran
SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)

Group: General Forum Members
Points: 244 Visits: 130
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"



style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]




Dobberteen, there are two solutions. First (best) is using a parameter.
rs.Source = "SELECT * FROM Orders WHERE OrderID = @OrderID"


The problem is that using parameter in old .asp ado vb code is a bit of a pain.

Second (quickest) solutions are: if your OrderID is an int, just use something like
rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & CInt(Request.QueryString("OrderID")) & "'"



If your IDs are strings, use something like
rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Left(Request.QueryString("OrderID"), myFieldLength) & "'"


Melville
Melville
SSC-Addicted
SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)

Group: General Forum Members
Points: 479 Visits: 18
@Christian Buettner

Standard injection attacks often work on the basis of form entry and then accurately guessing that there will be injectable code at the other end. Often works on username/password entry where the page that interprets the entry only checks to see if count of the matching username/password is one or more -

select count(*) from login where username = @username and password = @password

Then its a simple matter of using apostrophes and semi-colons to do a destructive query.

This is a newer injection that I have seen first hand and it relies not on form entry but on parameterized pages eg:

http://www.injectme.com/search.asp?search=hitmebabyonemoretime

It merely guesses that search.asp has some direct Sql similar to the form based injection. Interesting that the new injection uses hex, but fundamentally it is easier to retrospectively discover because it is as clear as day in the weblogs.



Melville
Melville
SSC-Addicted
SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)SSC-Addicted (479 reputation)

Group: General Forum Members
Points: 479 Visits: 18
@Tao Klerks

I guessed the right answer without reading the question at any length because I'd seen it before!

As I am more of a developer who uses Sql than a Dba with an understanding of coding I am also aware of the continuing debate amongst developers who want to use inline Sql as opposed to SPs. But I believe that you are right in saying use SPs, and parameters and you *should* be alright.



yavvie
yavvie
SSC-Enthusiastic
SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)

Group: General Forum Members
Points: 121 Visits: 109
the string 0x73656C656374206E616D652066726F6D207379732E6461746162617365733B actually has some meaning? I quite don't get why a string like this is used in the question.
Or is it just any string that generates an error on the server and thus displays a listing of the databases?

edit: never mind, found it in one of the posts Smile "select name from sys.databases;"

however, i tried it and got only some errors Smile
Hugo Kornelis
Hugo Kornelis
SSCoach
SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)

Group: General Forum Members
Points: 18787 Visits: 12426
yavvie (7/15/2008)
the string 0x73656C656374206E616D652066726F6D207379732E6461746162617365733B actually has some meaning? I quite don't get why a string like this is used in the question.
Or is it just any string that generates an error on the server and thus displays a listing of the databases?


Hi Yavvie,

Run the code below in a query window and you'll see the meaning of this string.

SELECT CAST(0x73656C656374206E616D652066726F6D207379732E6461746162617365733B AS varchar(50))




Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
dobberteen
dobberteen
Valued Member
Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)

Group: General Forum Members
Points: 51 Visits: 125
Mike C (6/18/2008)
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"



style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]




This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though Smile


Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.


I couldn't agree more about the shaky nature of the 'fix' that we've put in place to stop this *one* type of exploit... Again, we've been lucky as this is the only type of attack that we're seeing. I'd hate to see what would happen if someone decided to start guessing object names and then DROPping them - actually, I wouldn't need to see it, I know exactly what would happen.

I'm sure it's obvious that I'm not a DBA - my role leans much more to the development side... but since I am the only guy at my office w/a modicum of SQL server experience, I am called on to fulfill a quasi-DBA role from time to time. Ah the joys of working in a tiny shop! Smile
davidthegray
davidthegray
SSC Veteran
SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)SSC Veteran (244 reputation)

Group: General Forum Members
Points: 244 Visits: 130
dobberteen (7/15/2008)
Mike C (6/18/2008)
dobberteen (6/18/2008)
we've been getting hammered by the version of the attack that inserts the javascript mentioned above, thanks to a complete lack of input validation and total reliance on the:

rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Request.QueryString("OrderID") & "'"



style of coding.

Our solution, though very weak IMO, has been to issue:

DENY SELECT ON syscolumns TO [username]
DENY SELECT ON sysobjects TO [username]




This solution has been successful, though I can't help but be concerned about how vulnerable we are to other types of SQL injection. And of course, no one is willing to give the go-ahead to rewrite our thousands of scripts to utilize parameterized queries, include input validation, etc.

Can't complain about the job security that this particular exploit has given me though Smile


Denying SELECT on the system tables is a good idea, but presumably the this username still has permissions to access other tables. These permissions might be SELECT permissions, or possibly more seriously INSERT, DELETE, UPDATE, TRUNCATE or even DDL statements. What you've implemented sounds like a stop-gap measure to defend against that one particular attack. Just remember that nothing in IT is as permanent as a temporary solution.


I couldn't agree more about the shaky nature of the 'fix' that we've put in place to stop this *one* type of exploit... Again, we've been lucky as this is the only type of attack that we're seeing. I'd hate to see what would happen if someone decided to start guessing object names and then DROPping them - actually, I wouldn't need to see it, I know exactly what would happen.

I'm sure it's obvious that I'm not a DBA - my role leans much more to the development side... but since I am the only guy at my office w/a modicum of SQL server experience, I am called on to fulfill a quasi-DBA role from time to time. Ah the joys of working in a tiny shop! Smile


Dobberteen,

Doing something like:
rs.Source = "SELECT * FROM Orders WHERE OrderID = " & CInt(Request.QueryString("OrderID"))


should be easy and quick enough (provided, of course, that your order IDs were integers).

Since it looks like you are using string IDs, let's say they are 10 chars long:
rs.Source = "SELECT * FROM Orders WHERE OrderID = '" & Left(Request.QueryString("OrderID"), 10) & "'"



Those fixes will probably let you sleep a bit better at night. Wink
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search