June 24, 2008 at 11:17 am
I found this while running a Profiler trace and I'm trying to decide how worried I should be.
Select sectionID, heading from ordered where virtualSectionID_p =
'003;DECLARE @s-2 VARCHAR(4000);SET @s-2=CAST(0x4445434C415...'
The first part is a valid Select statement for the DB, but I'm pretty sure the rest is malicious.
I chopped out most of the hex value, but when I cast and print it, the text looks like this:
DECLARE @T VARCHAR(255),@C VARCHAR(255)
DECLARE Table_Cursor CURSOR FOR
SELECT a.name,b.name FROM sysobjects a,syscolumns b
WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xty
This code throws a syntax error, so it won't actually do anything, but the odd thing is that the same batch appears hundreds of times in the trace output. The hex value starts out small, but grows by a few digits each time it appears in the trace; this is effectively adding characters to the SQL code above, so even though the code above has a syntax error, it will presumably be syntactically correct at some point (although I could never find such an example).
So I really have two questions:
1) Have I correctly identified this as a SQL injection attack?
2) How worried should I be? This is a db for a third-party web app, so is there anything I can do besides restrict the app's SQL credentials as much as possible w/out breaking it?
Thanks all,
--mij
June 24, 2008 at 11:37 am
Yes, it is a SQL injection attack.
I'd notify the the 3rd party provider of the web application regarding the SQL Injection attack. If it is getting through to your database, there is an issue with the application that they should look at correcting (if they will).
I'd be concerned. Having seen this on your system, I think I am going to look at our systems a little closer and see about setting up some traces. If you could provide me with what yours look like, that would be a great starting point.
😎
June 24, 2008 at 11:43 am
I think you've identified that correctly. You might want to go through all your tables with columns that can hold text data and search for the word 'script' to find out if it did any damage.
http://isc.sans.org/diary.html?storyid=4565&rss
As far as fixing, I'd look to your application vendor to correct since it allowed bad input. And if that's not possible then you might want to modify the affected pages yourself to do input checking. For example, checking that the input length was in a normal range would probably have been enough to stop that particular attack.
June 24, 2008 at 2:18 pm
OK, thanks for the confirmation. I kind of figured that's what it was, but this is the first time I've ever seen one as it's happening (as opposed to a demo or sample) and sometimes Profiler shows me things that look weird just because I've never seen them before. Anyway...
Lynn, I was just using the standard/default template for profiler with the database ID column added so I could filter on a single DB. The actual code that showed up in the TextData column for the SQL:BatchCompleted event matches the description in the SANS link provided by Todd (above).
Todd, thanks for the link.
Now I'm off to search for corrupted data, which ought to be especially fun because this app stores HTML in the database. Wish me luck.
Thanks again,
--mij
June 26, 2008 at 3:19 am
If the injection attack inserts script tags into text columns, then I have a script that can help remove them. I based it off the original injection query, so it only searches in columns likely to be affected!
I would be happy to post here if anyone is interested.
June 26, 2008 at 6:23 am
That sounds like a good script for the script library.
😎
June 26, 2008 at 8:45 am
I wouldn't mind seeing it; our DB didn't appear to be compromised, but I'd be interested in your approach.
June 26, 2008 at 8:59 pm
Oh no! I've been called out now 😉
It's essentially the same as the decoded output as indicated in the first post in this thread...
It was made very quickly and is still really quite crude - so feel free to improve it!
Ideally, it should match strings with wildcards but I haven't figured out an elegant way to do it in this yet.
DECLARE @T VARCHAR(1000)
DECLARE @C VARCHAR(1000)
DECLARE Table_Cursor CURSOR FOR
SELECT a.name AS TableName, b.name AS ColumnName
FROM sysobjects a,syscolumns b
WHERE a.id=b.id AND a.xtype='u'
AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
OPEN Table_Cursor
FETCH NEXT
FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN
IF @T IS NOT NULL AND @T <> '' AND @C IS NOT NULL AND @C <> ''
BEGIN
--NOTE: for use replace the round brackets with angled brackets in script tag
EXEC('UPDATE ['+@T+'] SET ['+@C+']=REPLACE(CONVERT(VARCHAR(4000),['+@C+']), ''(script src=http://whatever)(/script)'', '''')')
END
FETCH NEXT
FROM Table_Cursor
INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
If you just want to find the location of any script tags you can use something like this instead of the EXEC (UPDATE) bit:
EXEC('SELECT '''+@T+''','''+@C+''' FROM ['+@T+'] WHERE ['+@C+'] like ''%<script%''')
I hope this is of some use to someone out there 😉
June 27, 2008 at 1:58 am
There is a lot of this going on at the moment
usually the injection looks for text/character type fields and where there is enough space
adds in a script which embeds into the web page and runs when rendered running a piece of code which downloads a trojan onto the computer where the broswer is running.
I would check you permissions on the public role and remove all of them.
The web application database user login needs to have its rights restricted down to datareader and denydatawriter and not ever be dbowner. Denying select rights to the sys tables on the web application user will also kill this type of attack stone dead.
Also a grant exec rights to stored procs which read/write the data and call them from the web application and eliminate any SQL in the web application.
This is the only way to avoid this sort of thing.
I have script which will find and replace (i.e. fix the data if you need them, not my own work) the bad text.
Be aware that this kind of attack has usually a varied payload and can download a trojan from the web app which installs a key logger application that records and transmits your activities to the hacker(s).
I would immediately take the web application down and isolate your network from the internet when you detect this happening.
Sorry to sound so scary!:D
You web app and database have got crap security, it needs fixing fast!:P
Hiding under a desk from SSIS Implemenation Work :crazy:
June 27, 2008 at 9:12 am
That looks exactly like SQL injection.
Our database got hit by just this kind of attack 2 days ago. The good news is, it happened about 10 minutes after the last transaction log backup, so I was able to restore with no data loss. Hooray for good backups.
I've remove as many rights as I can from the login the web account uses. I removed read/write permissions from the sysobjects and syscolumns. I took away the dbowner rights.
Now if I can just talk the boss into finding time for us to rewrite it to close the other loopholes....:w00t:
August 9, 2008 at 9:12 am
August 9, 2008 at 11:56 am
Personally I would suggest restore from backup rather than trying to fix. There's no easy way to tell if the attack you got hit with is the same as another person's or if it's a slightly modified one that does additional nasty stuff.
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
September 9, 2008 at 9:59 am
hi
(excuse for my syntaxe am french)
i have a big porblem with sql injection in last june
my plateform are asp/sql server 2000
i update all my asp script for deny sql injection but all my table in my database are corrupted with
« »
I found one topic who some one do this request in sql server
-----------------------------------------------------------------
use [Your_Database_name]
GO
DENY SELECT ON [sys].[columns] TO [Your_User]
DENY SELECT ON [sys].[tables] TO [Your_User]
DENY SELECT ON [sys].[syscolumns] TO [Your_User]
DENY SELECT ON [sys].[sysobjects] TO [Your_User]
DENY SELECT ON [sys].[objects] TO [Your_User]
DENY SELECT ON [sys].[syscomments] TO [Your_User]
GO
-----------------------------------------------------------
after this no attack
but now i transfert my databse on sql server 2005
and all table a corrupted again !!!!!!!!!!!
i trie
-----------------------------------------------------------------
use [Your_Database_name]
GO
DENY SELECT ON [sys].[columns] TO [Your_User]
DENY SELECT ON [sys].[tables] TO [Your_User]
DENY SELECT ON [sys].[syscolumns] TO [Your_User]
DENY SELECT ON [sys].[sysobjects] TO [Your_User]
DENY SELECT ON [sys].[objects] TO [Your_User]
DENY SELECT ON [sys].[syscomments] TO [Your_User]
GO
-----------------------------------------------------------
but nothing the table are corrupted again and again
please wath can i do?
am sure that the asp code are good
perhaps must deny an other system base i dont know sql 2005
thanks a lot
September 9, 2008 at 1:12 pm
I would argue that if you're getting hacked again and again, your asp code is not good.
All data access should be via stored procedures. Ensure that the user has no access to the base tables. Not just the system views, but all of the user tables
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
September 10, 2008 at 1:49 am
You need to revoke any/all rights on all objects to the "public" role.
This means that all users/roles will have no rights unless you grant them specifically.
It is not SELECT that is the issue on the sys tables its the fact that you have granted update rights to the application user used by your ASP code.
You need to use parameterized stored procedure calls, typed variables and parsing/removal of ';' in your ASP code.
--Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
Viewing 15 posts - 1 through 15 (of 41 total)
You must be logged in to reply to this topic. Login to reply