01 oktober 2005

Hacking SQL Server 2005

Just went to the talk by Brian Knight (SQLServerCentral.com) and Bayer White on hacking SQL Server 2005 (although most of it is not 2005 specific). It was a really nice talk on SQL injection and cookie manipulation. I assume you know what both of these are, otherwise Google for it or drop me a comment and I will follow up on it. The crowd was 90% or more DBA, so it gave a good angle on how DBA's would exploit the system once they are in. One of the things is covering up your tracks.

Here are some examples:

  • Check for SQL injection vulnerability using a name that contains a apostrophe (') like o'Conner. That way it won't show directly as a hack-attempt in the logs.
  • ' OR 1=1 -- is the shortest injection attack one around. Check what it does when you enter it in the Username textbox.
  • Find a page that is vulnerable and has a grid on it. You can use the grid as a viewer for extra data that you retrieve like so:
    ' UNION SELECT id, name, 0,0 from sysobjects where xtype = 'U' --
    Notice the extra zeros to fill out the additional columns of the table. Pick a column that has the correct data type.
  • With the last statement you should get all user tables. Check if one of them refers to users. Let's say it is Users. Then run something like this:
    ' UNION SELECT 0, UserName, Password, 0 FROM Users --
  • One other nifty trick is that when there is no output available through error messages that get displayed in the table, you can use if statements to test for something and add a wait time in it. A pause will indicate a match on the criteria. For example, to test if you are running with sa credentials, do this:
    ' if (SELECT suser_sname()) = 'sa' WAITFOR DELAY '0:0:10' --
  • If the page has error messages, you can probe for metadata using expressions like ' HAVING 1=1 --, which should give errors such as "Column Users.UserName is invalid in the select list...".
  • Append sp_password at the end of statements, so the log will not pick it up. Instead it will state a text that says something like: "sp_password" was detected, so we replaced it with this text".
  • Finally you may want to create additional records in the user table and create a "normal" account with elevated privileges. Just use INSERT statements constructed with the schema information you got from previous steps.

Cool stuff. Got to go. Maybe more later today.

Comments

# Mark Willems said:

Indeed tricky stuff! Did they also talk about how to prevent that kind of attacks?

Regards, Mark

dinsdag 4 oktober 2005 15:28
# Alex Thissen said:

Hi Mark,

In short the solutions mentioned were: no string concatenation or escape user input (personally, I would always use parametrized queries or stored procedures) and encrypt every secret that is sent to the client (like session tickets and login names inside a cookie).

During the presentation I also brought up the option to do JavaScript injection (aka Cross-Site scripting XSS) to do cookie-hijacking.

The bottom-line is: NEVER, NEVER EVER trust user input.

zondag 9 oktober 2005 12:00
# Niels said:

It is sad to see that a lot of (large) sites are vulnerable to SQL injection and XSS. It's a matter of being creative!

The motto of every developer must be:

"All input/output is evil, until proven otherwhise!".

Gr,

Niels

dinsdag 11 oktober 2005 11:35