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 |
|
snuh
Starting Member
3 Posts |
 Posted - 2008-01-15 : 15:19:51
|
| Hi all, long time lurker, first time poster.One of those fantastic mornings, an hour late, no coffee, walk through the door and the first words I hear are "we've been hacked!"Ugh.Turns out there is one and only one place on the website that isn't properly protected against sql injection attacks and somebody found it (now fixed). It doesn't look bad - a new table has been added, dbo.a_LyHungTraVinh_a with two empty columns [LyHungTraVinh VNC Hacked] and [Good Bye My Love]. I was somehow hoping my first hack would be more clever, so I'm also having to cope with mild disillusionment.But I think I can get over that, what I'm really hoping for your help with is how to proceed with the forensics and clean-up. See, our DBA resigned a couple weeks ago and we're in the cute situation of not having one at this moment - I'm certainly not one. It looks like this is just a random act of harmless vandalism but I'd feel better if we did our full due diligence. Here's what we've done so far, any additional advice or links to resources would be greatly appreciated.1. Identified and closed the vulnerability2. Ran AdeptSQL_Diff and compared the production db with an archived version - other than the aforementioned new table, the schema and data is unchanged3. ... that's it.I suspect using DBCC LOG and/or fn_dblog would be helpful to review the attacker's transactions, but I'm having a devil of a time finding information on how to use those, particularly about what permissions I need to use them.thanks! |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2008-01-15 : 15:36:48
|
| First, make sure that the login that the application is using to connect to the database is not in any server role (sysadmin, etc.), and is not in any elevated role in the database (db_owner, etc.). This is the first line of defense; if the application login doesn't have elevated access, they can't do as much damage.You should make sure they did not create any database logins, or create any SQL Agent jobs or alerts. You should make sure they did not create any objects in any of the system databases.You should make sure they did not connect to any other database server that your production server might have access to.CODO ERGO SUM |
 |
|
|
snuh
Starting Member
3 Posts |
Posted - 2008-01-15 : 16:48:45
|
| Thanks Michael. Good call on the permissions, we have curtailed the permissions for application login.I checked agents, alerts, objects, procedures, and users and didn't find anything new or edited.How would I check for connection attempts?Thanks! |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2008-01-15 : 17:03:05
|
quote:
Originally posted by snuh
Thanks Michael. Good call on the permissions, we have curtailed the permissions for application login.I checked agents, alerts, objects, procedures, and users and didn't find anything new or edited.How would I check for connection attempts?Thanks!
You may see the information in your SQL Server event logs, depending on your SQL Server Security Login Auditing settings.You may also be able to see information on logins in the servers Security event log.CODO ERGO SUM |
|
|
|
jezemine
Master Smack Fu Yak Hacker
2886 Posts |
Posted - 2008-01-15 : 17:07:38
|
did the application login have rights to xp_cmdshell at the time of the breakin?
elsasoft.org |
|
|
|
snuh
Starting Member
3 Posts |
Posted - 2008-01-15 : 20:22:53
|
| Hi, thankfully the login did not have permissions to execute xp_cmdshell nor do the logs reveal anything more than a create table statement. Looks like it was just some harmless vandalism.Thank you both very much for your assistance. Gonna use this incident as an opportunity to make a few changes around here... |
|
|
|
|
|
|
|
|
sql injection forensics