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!

  • Some questions to ascertain more about the how:

    1) Do you have a web application which is exposed to the Internet?

    2) Is SQL Server exposed to the Internet?

    3) Is the web server and the SQL Server together on the same server?

    3) What type of user account does the web app use to get access, a SQL Server one or a Windows one (it sounds like you switched to a Windows one)?

    4) What privileges does the account the web app uses have?

    K. Brian Kelley
    @kbriankelley

  • Ok All,  GOT IT!

    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!

    To answer your questions, the web server and SQL server are on the same box and both are exposed to the internet.  The web app is now using a trusted connection, the anonymous web account.

    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!

  • Yes, the web application code needs to be tightened up. You didn't say what it was, I assume ASP, but... that needs to be fixed for any and all possible injection points (it sounds like you've fixed some if not all the entry points). What you should also do is reduce the privileges the web anonymous account has within SQL server (it should certainly not be a member of the sysadmin role) to the bare minimums necessary for the application to run.

    However, from a security perspective I'll be quite honest with you that we typically recommend a compromise box to be completely wiped and reloaded from scratch. If you have a backup you can confirm was prior to the server being compromised, reload with that. Of course, before you go down that path, if you want to involve law enforcement, call them first. For instance, the FBI has a methodology for their forensics. Of course, that should be done before any modifications are typically done to the server other than disconnecting it from the network. However, they can probably still do something, especially if you have logs, etc. That would be the way to go.

    K. Brian Kelley
    @kbriankelley

  • Have you ever gone that route and pursued with the FBI?  Do you contact the local office by voice or e-mail?  How does it work exactly?

  • No, I've never had to as of yet, thankfully. I think contacting the local field office is the typical way most folks start. Another way looks to be via:

    http://www.ic3.gov/

    K. Brian Kelley
    @kbriankelley

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply