May 5, 2008 at 3:27 pm
Hi,
My customer website is keep on getting hacked again & again.. every month soem body updates few coulmn in important tables wiht garbage...
Its ASP Classic website using SQL server 2000.
I did all SQL inject precauion on web form so that no one can enter any sql startment....
1. Can any one advice how somebody still can update the datbase..?
2. How to find the traces how someone updated our database? Mean via sql server or anyother way... Is there any query logging table .. or something which can tell me.... This is how hacker did it.......
This is happening 4-5 time.. I am feelign myself failuer plelase advice.
May 5, 2008 at 4:47 pm
What is getting updated? Are these columns not reachable from the web? Could people be entering bad data?
Are you only using stored procedures with ASP and the stored procedure object?
You can only trap stuff using Profiler and running a trace. Or you can log every update from the website, write to a local flat file.
May 6, 2008 at 12:24 am
Are you sure that every possible place that input is entered (including query strings) is checked for injection?
Are you building up SQL statements and executing them or are you using parameterised stored procs?
Is the server in mixed mode or windows authent? What login is the web app connecting as? Is the username/password hardcoded in any file?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2008 at 1:31 am
Its ASP Website & i am hardly using stored proceduer....
Its old done websit with classic ways of Inline Coding..........
May 6, 2008 at 1:52 am
Then you're asking for SQL injection.
If I may suggest...
Look into moving code into stored procs and calling with parameters. It's a far more secure way of doing things.
How are you checking for SQL injection?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2008 at 3:10 am
Have to agree with the others, change to Stored Procs, give your Application access to these only and no access to the underlying tables..
May 6, 2008 at 6:17 am
onlybemine (5/6/2008)
Its ASP Website & i am hardly using stored proceduer....Its old done websit with classic ways of Inline Coding..........
I nornally wouldn't pile on to something like this with a late hit, but it's worth it.
You outlined your own problem in the statement above.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 6, 2008 at 6:44 am
Since movign to stored proc is another big investment because of size of work.. which i couldn't do this stage....
Also
How to stop SQL Injection via webforms i am securing against all know tricks... Like ( Replace ' with '' etc and don't accept and update & deltee keyword from webforms/fields....)
Also since Its sql 2000 .. will it make any difference moving to 2005?
Any suggestions... in current circustmance how to stay best?
May 6, 2008 at 6:52 am
With stored procs/parameterised queries is the only way to be sure. Yes, it's a lot of work. how much work is going in to fixing that database?
If you're just replacing quotes, you're not very secure at all.
How about quotes as hash codes/escaped characters? Tthere's another post here from yesterday where the hacker passed the command to execute as a varbinary, did a cast to nvarchar and EXEC'd that.
No real difference in moving to 2005. The root problem is the way you're calling the DB. would be the same with Oracle, MySQL or any other DB really.
What username is the web app using to call the DB?
Do you do validation of any querystrings as well?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2008 at 7:00 am
And what level of access does that user have? Is the server set up with 'sa' and no password?
Yes, setting up procs is work, but your core issue is your code. You need to fix it to fix the problem. Anything else is an attempt at a band-aid. Even if you restrict the user that the ASP page uses to datareader and datawriter, your data is still exposed and can be manipulated by the hacker that's going after your system. You need to lock them out completely. That's what stored procedures help to do. You could rewrite all the code to use parameterized queries. That's probably as much work as setting up stored procedures, but it will limit access.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 6, 2008 at 8:48 am
GilaMonster (5/6/2008)
Then you're asking for SQL injection.If I may suggest...
Look into moving code into stored procs and calling with parameters. It's a far more secure way of doing things.
How are you checking for SQL injection?
Here's a stupid question, but are you logging your SQL the web page generates anywhere?
May 6, 2008 at 9:06 am
You might try parsing the log to find out which account is doing the updates. It's always possible someone is directly connecting to the database and doing the updates that way, instead of through injection from a web site.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 6, 2008 at 9:17 am
onlybemine (5/6/2008)
Since movign to stored proc is another big investment because of size of work.. which i couldn't do this stage....Also
How to stop SQL Injection via webforms i am securing against all know tricks... Like ( Replace ' with '' etc and don't accept and update & deltee keyword from webforms/fields....)
Also since Its sql 2000 .. will it make any difference moving to 2005?
Any suggestions... in current circustmance how to stay best?
One thing to watch out for, as this has come up recently, is that simply replacing keywords won't always do it. For example, what keywords are there in:
0x73656C656374202A2066726F6D207379732E7461626C65733B2073656C656374202A2066726F6D207379732E72656D6F74
655F6C6F67696E733B2073656C656374202A2066726F6D207379732E7379737573657273
Can you replace "select" out of that? Not really.
But what happens if you run:
;declare @a varchar(1000);select @a = cast(0x73656C656374202A2066726F6D207379732E7461626C65733B2073656C656374202A2066726F6D207379732E72656D6F74
655F6C6F67696E733B2073656C656374202A2066726F6D207379732E7379737573657273 as varchar(1000));exec(@a)
In SQL 2005, that will give you a list of the tables in the database, the remote logins, and the user accounts. Something similar can be done using SQL 2000 system tables.
You might want to try something like that in your code that prevents SQL injection. See what it does. There are ways to defeat it (the best is use stored procs with input parameters), but you have to test for possibilities like that, which don't contain "select" anywhere in them.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 6, 2008 at 10:27 am
onlybemine (5/6/2008)
Since movign to stored proc is another big investment because of size of work.. which i couldn't do this stage....Also
How to stop SQL Injection via webforms i am securing against all know tricks... Like ( Replace ' with '' etc and don't accept and update & deltee keyword from webforms/fields....)
Also since Its sql 2000 .. will it make any difference moving to 2005?
Any suggestions... in current circustmance how to stay best?
Well - you can look at it this way - you can either start on the "substantial chunk" of work to move it into stored procedures, or you can spend substantial chunks of time finding what this hacker does to your data, and what might be getting stolen/corrupted/destroyed.
Trying to protect yourself from SQL injection attacks from within the ASP page itself is quite honestly a fantasy. There are plenty of ways to completely hijack classic ASP, so you have 0 guarantees that SQL injection measures fired from within the ASP code are even being fired.
You're playing with an unexploded hand grenade right now, so you can either choose to find a way to defuse the situation, or you can choose to sit back and wait for it to go off. I'm frankly amazed that you're leaving a website up that according to your own words has been repeatedly hacked. Anything like that happens around me just one time, and that site would be yanked until we have a decent clue why/how, and a fix be in place. Anything getting hacked multiple times over in the same way, and I'd be sitting in some higher-up's office explaining why there is value in my continued employment with them.....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
May 7, 2008 at 9:33 am
I can't add much to what has been said, buthere is my 2 Cents worth. Matt is correct. what do you want to spend your time doing, correcting data or writing procs to prevent SQL injection. You have an issue with data changing and you wanted advise. These guys are good and are correct. If you are able to put validation on the columns being affected you might limit some of the damage, but it won't prevent it.
It worries me if you aren't 100% positive that the changes are being made by SQL injection, then you have security issues that need to be addressed on top of the programming issues. Who has access to the database and what are their authorities? Is the guest account still enabled? Can application roles be used? There are lots of things that can be and many should be done.
Since this is a customer, you may not have the authority to make changes, but you may want to look at the link below and discuss some of the possibilities with them.
http://technet.microsoft.com/en-us/library/bb283235.aspx
Q
Please take a number. Now serving emergency 1,203,894
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply