Post reply

SQL Injection - Suggestion..!!!

  • August 5, 2014 at 3:25 pm

    #310543

    We had a SQL injection on a web server, This servers hosts decade old asp(IIS,SQL 2000) code. I am in the process of getting this migrated to newer platforms. This is going to take some time next 4 to 6 months.

    To fix the SQL injection I have quickly restored from the backup and everything is up and running.

    As part of preventive measure I have done the following.

    1. Configured the log backup. so that we can recover to point to a point before the issue.

    2. disable the unused ports on the server.

    3. Run the vulnerability scanner and fixed all the loop holes.

    4. time intrusion prevention for SQL server is enabled in the security software.

    5. database level security hardened at the server.

    Let us know any other suggestions that you have done which I have missed.

    Your help is highly appreciated.

    Thank you,

  • August 5, 2014 at 3:51 pm

    #1735420

    Fix the code.

    Change permissions to the web app user to the minimum needed. You'll still get attacked but the damage can be minimized.

    Fix the code.

    Fix the code.

    The code should not execute string literals concatenated on the app. You need to use parametrized queries/Stored Procedures.

    You could sanitize your inputs, bit it won't catch everything or it might give false positives.

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2

  • August 5, 2014 at 6:36 pm

    #1735449

    Since you have already been hacked, you must assume that your ENTIRE hardware infrastructure is compromised, especially if you are like most of my clients and run your stuff with accounts that have too high permissions on the SQL Server. You simply MUST scan every machine you have for every form of malware, spyware, root kits, etc. It is dirt-simple to own everything once injection is realized.

    Given that it will likely take you a while to fix your code the single most important thing to do (after ridding yourself of payloads the bad guys may have dropped on you) is to shift to using exceptionally-restricted SQL Server user. This will mitigate the effects of follow-on hacks. Also look to secure the server by disallowing xp_command shell, use lowest-privilege logins for sqlserver.exe and sqlagent.exe executables. Obviously as the other poster said fixing the code becomes the developer's highest priority.

    You must also change EVERY SINGLE PASSWORD AT YOUR COMPANY IMMEDIATELY, and enforce complex passwords. Unless the hackers were being very nice to you every one of your logins of every form and to every system you have is compromised.

    Best of luck - you're going to need it. Sorry to be blunt, but the survival of your company is very likely at stake here. :crying:

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • August 5, 2014 at 10:01 pm

    #1735464

    Some of this has already been said but it's worth repeating...

    Make sure that your password policies are strict and enforced.

    Also, make sure that the logins for SQL Server and SQL Agent have their passwords changed and limit what they can "see" in the domain. Change the passwords for any and all proxies. Anyone with logins at either the Windows or SQL Server level must change their passwords.

    Make sure that no application login has "SA" or even "DBO" privs. No exceptions on the "SA" thing. If some "SA" activity is required from the app, do it only through stored procedures. The apps must not have "SA" privs, period.

    Make sure that no individuals or groups have proxy privs to xp_CmdShell, period. They should only use it through stored procs.

    You should do a review of any certificates on the system, as well.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • August 6, 2014 at 11:38 am

    #1735723

    Thank you all for your suggestion. I will recheck those suggestions again.

    Whole server is running on an isolated environment. From SQL server side there is no SA permissions for application account; only read/write permissions on that particular database as required by the application. Services are running with minimal permissions.

    Only thing is ASP code that was written poorly 10 years back. When I spoke to the company who developed this site; they are pretty much agreed that code issues and SQL injection. Problem is entire site is having the similar code fixing the landing page is not going to help. There are number of other pages where it uses the simple query string that also need to fixed. Fixing the home page is like band aid for the home page. Rewriting the whole code costs more than new product.

    Only thing is replacement project is in progress. It will take quite some time. Need to hold the fort till the new projects kickoff.

  • August 6, 2014 at 4:46 pm

    #1735808

    This might not be helpful, but you might want to look at some form of caching or a static version of every page on the site. If the issue is things like product id's being passed in the URL, then you can probably create a static version of those pages to be served until the site is re-coded. Something like that.

    "If I had been drinking out of that toilet, I might have been killed." -Ace Ventura

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

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