Post reply

Hacked or Corrupted?

  • April 30, 2004 at 6:34 am

    #82750

    Hello all,

    Two days ago our production database had a set of three non related tables truncated, one of them even had the indexes dropped. Now we are receiving the following error at least 10 times a day on our SQL Server 2000 (SP3) production server (Windows Advanced Server 2000 SP3.

    DATE/TIME: 4/30/2004 6:37:27 AM

    DESCRIPTION: Error: 17805, Severity: 20, State: 3

    Invalid buffer received from client.

    COMMENT: (None)

    JOB RUN: (None)

    Are there any suggestions as to how I begin tracing down what machine is sending the offending stream to our sql server?

    Also, the same day our IIS 6 Server (patched for the recent SSL vulnerability) had massive application failure and had to be rebooted. And we are seing some activity on our firewall on port 1434. Does anyone think this is a hack or can it be that our database has become corrupted. I've run database maintenance on it and no errors are evident.

     

    Doug

  • April 30, 2004 at 7:03 am

    #504813

    While it is possible you've been hacked, the database changes could have been done by anyone with rights, and that might have been an accident. The error being returned to clients is a bit disconcerting, however. The firewall traffic is not all that unusual, as Slammer is still out in the wild. Given everything else going on with the recent Microsoft patches, I'll reserve comment there. Just look in the newsgroups and you'll find issues with MS04-011 and MS04-012. I haven't heard of any massive application failures, but there are issues with these two patches on a handful of systems (a few, the vast majority patch fine).

    Is there any evidence on the web servers of a hack (root kits present, unusual event log entries other than the app failure, etc.)? Do you have any intrusion detection systems in place? Do you have any incident response procedures?

    Take a look here for some papers on how to do incident response if you don't have well-defined procedures in your organization:

    SANS InfoSec Reading Room: Incident Handling

     

    K. Brian Kelley
    @kbriankelley

  • April 30, 2004 at 7:17 am

    #504815

    Thank you for your reply.

    We don't have much in the way of IDS beyond auditing our firewall log. And unfortunately application crashes on our web server are par for the course, just not in the number we received the morning before the data corruption.

    There are 9 of us with permissions to the database that could have truncated the tables. That was my initial thoughts on the problem until we started seeing buffer overuns. The buffer overuns started just after the we lost the tables.

    No one on our staff would even know where to begin looking for root kits. My guess is that they would be on our two internet facing web servers. We do have virus software enterprise wide that is up to date and it has not intercepted anything. This looks more like a hack than a virus anyway.

    We don't have well defined procedures for incident response, but we are working on it. This just gives us some more motivation.

    Thank you for the link

  • April 30, 2004 at 7:29 am

    #504818

    In this case, if you can afford it, you may want to bring in consulting help to check things out. There should be someone locally in Des Moines who has proficiency in computer forensics and the like.

     

    K. Brian Kelley
    @kbriankelley

  • April 30, 2004 at 10:19 am

    #504861

    Also, is your SQL Server patched to SP3a?

    -SQLBill

  • April 30, 2004 at 10:24 am

    #504865

    Our SQL Srver Installation is only at SP3. Is there a fix in SP3a for this error?

    I found this article on google. It seams like a real possibility that this is the culprit:

    http://www.standardio.org/article.aspx?id=215

    and it seems like this is the fix for it without having to rewrite a lot of code.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;827366

    Doug

  • April 30, 2004 at 11:11 am

    #504870

    There are hotfixes to handle malformed TDS packets, but this looks like a more reasonable solution. Out of curiousity, was there a recent change in the application or the way it's used?

     

    K. Brian Kelley
    @kbriankelley

  • April 30, 2004 at 11:33 am

    #504876

    We have weekly (sometimes less) applicaiton roll outs. I'm sure something went live. Though from the looks of the qbase article it might even be an old application where the text fields have finally grown too large.

     

    Doug

Viewing 8 posts - 1 through 7 (of 7 total)

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