Server Compromised! | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Server Compromised!

Hi All, I’ve discovered that my server has been compromised and I believe it came through SQL server. I see in my application event log that the xp_cmdshell SP was executed around the time that my server was compromised so I assume that this is how the attack started. Here are some questions: 1. I’ve had my SQL Server 2000 (8.00.818 (Intel X86)) set to Mixed Mode. I changed this to Windows Authentication and changed my connection string to use "Trusted_connection=yes;". I guess I don’t fully understand how this works though. I thought that this means that you can only access the SQL Server through the local machine from a valid Win2K user account that also has a login and database access in SQL Server. In order to get my web app up, I had to add a Win2K user with access to the specific database. I figured that I would not be able to access my SQL server from my development localhost (remote to the server) with a connection string that calls out the IP address and specifies a database user/password nor would I be able to access through Enterprise Manager remotely. This is not the case however. Why is this? 2. How do I prevent this from happening? I thought what I did above would help but it doesn’t seem to do what I expect. I have a strong password on the SA account and on the Win2K accounts. I can change the password for the SQL Server data base user as well, but I thought that wouldn’t be necessary since I change to use Window Authentication but that’s apparently not true. Any help would be greatly appreciated!

I’m not aware what language has been used to design the application, if its ASP.NET or c# then take help of this link to configure the connection to SQL database using the application. SQL Server Authentication is provided for backward compatibility. For example, if you create a single Windows 2000 group and add all necessary users to that group you will need to grant the Windows 2000 group login rights to SQL Server and access to any necessary databases. BOL refers a section about Windows authentication
When connecting to an instance of SQL Server running on Windows NT 4.0 or Windows 2000 using Named Pipes, the user must have permission to connect to the Windows NT Named Pipes IPC, \<computername>IPC$. If the user does not have permission to connect, it is not possible to connect to an instance of SQL Server using Named Pipes unless either the Windows NT 4.0 or Windows 2000 guest account on the computer is enabled (disabled by default), or the permission "access this computer from the network" is granted to their user account.
Check whether the server Win2k computer has Kerberos support enabled. Satya SKJ
This posting is provided “AS IS” with no rights for the sake of knowledge sharing.
Ok All, GOT IT! The app is coded in ASP and I found an SQL Injection vulnerability. I found a script file that was placed on my server which caused my server to connect via FTP to a remote machine. The IP address of that machine was in the script. I then went to my web server logs and found that IP address in the logs and could see clearly what page was being accessed. I checked that page and saw the injection vulnerability. I’ve modified the code to protect against the injection AND it will also log the injection! Two questions:
1. Since it’s an injection attack, is the only way to prevent this by scouring the code for possible holes or can I protect against this with user privelege changes? I may be able to protect against the use of xp_cmdshell with privelege changes but not against INSERT/DELETE/UPDATE/SELECT commands it seems. 2. How can I pursue this legally or otherwise?!? Thanks for your input!