Post reply

x-cmdShell access

  • September 20, 2012 at 11:19 am

    #1540267

    Jeff Moden (9/20/2012)

    Ok, so how will having xp_CmdShell turned off prevent that internal threat? Answer is, it doesn't because anyone with SA privs can use xp_CmdShell even if it is turned off. Auditing is nice to have but it's like pouring water on a building that has already burned down. To wit, anyone with SA access can still easily get to a command line through at least 2 different avenues in SQL Server even if the DLL for xp_CmdShell were deleted.

    Have you tried this lately in SQL 2008?

    Having xp_CmdShell turned off is a futile effort and provides no extra level of security. Having it turned off may even provide a false sense of security.

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • September 20, 2012 at 12:46 pm

    #1540314

    opc.three (9/20/2012)

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    I absolutely agree that the fewer attach surfaces there are, the better but that's my whole point. Having xp_CmdShell enabled doesn't provide an attack surface unless someone has SA privs. If you have users and application logins that have SA privs, then having xp_CmdShell disabled simply does not remove an attack surface. You also have some much larger problems if users and apps have SA privs.

    --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

  • September 20, 2012 at 3:41 pm

    #1540418

    Jeff Moden (9/20/2012)

    opc.three (9/20/2012)

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    I absolutely agree that the fewer attach surfaces there are, the better but that's my whole point. Having xp_CmdShell enabled doesn't provide an attack surface

    I have to stop you right there. Sorry but there are no conditions that are applicable. Call it an extreme position if you like but it increases the attack surface, period, and that is why it should be left disabled.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • September 21, 2012 at 6:47 am

    #1540645

    opc.three (9/20/2012)

    Jeff Moden (9/20/2012)

    opc.three (9/20/2012)

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    I absolutely agree that the fewer attach surfaces there are, the better but that's my whole point. Having xp_CmdShell enabled doesn't provide an attack surface

    I have to stop you right there. Sorry but there are no conditions that are applicable. Call it an extreme position if you like but it increases the attack surface, period, and that is why it should be left disabled.

    If no one but trusted DBAs can run it directly, how does it increase the attack surface? It doesn't.

    The key is to not allow an attacker in as SA or even DBO. If they get in as SA, then it's not going to matter if xp_CmdShell is enabled or not.

    --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

  • September 21, 2012 at 7:00 am

    #1540657

    Jeff Moden (9/21/2012)

    opc.three (9/20/2012)

    Jeff Moden (9/20/2012)

    opc.three (9/20/2012)

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    I absolutely agree that the fewer attach surfaces there are, the better but that's my whole point. Having xp_CmdShell enabled doesn't provide an attack surface

    I have to stop you right there. Sorry but there are no conditions that are applicable. Call it an extreme position if you like but it increases the attack surface, period, and that is why it should be left disabled.

    If no one but trusted DBAs can run it directly, how does it increase the attack surface? It doesn't.

    The key is to not allow an attacker in as SA or even DBO. If they get in as SA, then it's not going to matter if xp_CmdShell is enabled or not.

    There are too many assumptions in your argument. Malicious people can add themselves to AD groups that get them into DB instances as sa. I have seen .NET configuration files with the sa login and password in plain-text in a connection string. xp_cmdshell is extremely powerful and also extremely hard to audit who is doing what. It can also elevate people's rights on the network depending on which account the SQL Server service is running as. The less things left on the table for an attacker to use the better.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • September 21, 2012 at 8:37 am

    #1540740

    opc.three (9/21/2012)

    Jeff Moden (9/21/2012)

    opc.three (9/20/2012)

    Jeff Moden (9/20/2012)

    opc.three (9/20/2012)

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    I absolutely agree that the fewer attach surfaces there are, the better but that's my whole point. Having xp_CmdShell enabled doesn't provide an attack surface

    I have to stop you right there. Sorry but there are no conditions that are applicable. Call it an extreme position if you like but it increases the attack surface, period, and that is why it should be left disabled.

    If no one but trusted DBAs can run it directly, how does it increase the attack surface? It doesn't.

    The key is to not allow an attacker in as SA or even DBO. If they get in as SA, then it's not going to matter if xp_CmdShell is enabled or not.

    There are too many assumptions in your argument. Malicious people can add themselves to AD groups that get them into DB instances as sa. I have seen .NET configuration files with the sa login and password in plain-text in a connection string. xp_cmdshell is extremely powerful and also extremely hard to audit who is doing what. It can also elevate people's rights on the network depending on which account the SQL Server service is running as. The less things left on the table for an attacker to use the better.

    Then you're saying that the "malicious people" can get into SQL Server with "SA" privs. If that's true, having xp_CmdShell turned off isn't going to help a bit. It won't even slow a determined attacker down because they'll be expecting that. Sure, it'll be logged if they turn it on but, like I said, that's just throwing water on the ashes of the burned building.

    --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

  • September 21, 2012 at 10:11 am

    #1540835

    Jeff Moden (9/21/2012)

    opc.three (9/21/2012)

    Jeff Moden (9/21/2012)

    opc.three (9/20/2012)

    Jeff Moden (9/20/2012)

    opc.three (9/20/2012)

    The less attack surfaces the better. If you're only worry is against the SQL-ninja then sure, nothing will stop them. The higher we raise the bar for a breach the better and in my estimation enabling xp_cmdshell lowers the bar.

    I absolutely agree that the fewer attach surfaces there are, the better but that's my whole point. Having xp_CmdShell enabled doesn't provide an attack surface

    I have to stop you right there. Sorry but there are no conditions that are applicable. Call it an extreme position if you like but it increases the attack surface, period, and that is why it should be left disabled.

    If no one but trusted DBAs can run it directly, how does it increase the attack surface? It doesn't.

    The key is to not allow an attacker in as SA or even DBO. If they get in as SA, then it's not going to matter if xp_CmdShell is enabled or not.

    There are too many assumptions in your argument. Malicious people can add themselves to AD groups that get them into DB instances as sa. I have seen .NET configuration files with the sa login and password in plain-text in a connection string. xp_cmdshell is extremely powerful and also extremely hard to audit who is doing what. It can also elevate people's rights on the network depending on which account the SQL Server service is running as. The less things left on the table for an attacker to use the better.

    Then you're saying that the "malicious people" can get into SQL Server with "SA" privs. If that's true, having xp_CmdShell turned off isn't going to help a bit. It won't even slow a determined attacker down because they'll be expecting that. Sure, it'll be logged if they turn it on but, like I said, that's just throwing water on the ashes of the burned building.

    Yikes. The more we talk about this the more your approach to security sounds like 'why bother.' I am actually becoming quite astonished that you're trying to defend an untenable position.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • September 21, 2012 at 7:23 pm

    #1541029

    opc.three (9/21/2012)

    Yikes. The more we talk about this the more your approach to security sounds like 'why bother.'

    I am actually becoming quite astonished that you're trying to defend an untenable position.

    BWAAA-HAAA!!!!! You're talking about security gaps that will allow someone to get in with "SA" privs and I absolutely agree that must be prevented. I'm trying to suggest that xp_CmdShell isn't the problem and that the very security gaps that you're talking about are. Simply turning off xp_CmdShell won't fix nor help those gaps. even deleting the DLL for xp_CmdShell won't help because someone with "SA" privs can and will get to the command prompt without it.

    And you call my position "untenable"?

    --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

  • September 21, 2012 at 8:23 pm

    #1541031

    Jeff Moden (9/21/2012)

    opc.three (9/21/2012)

    Yikes. The more we talk about this the more your approach to security sounds like 'why bother.'

    I am actually becoming quite astonished that you're trying to defend an untenable position.

    BWAAA-HAAA!!!!! You're talking about security gaps that will allow someone to get in with "SA" privs and I absolutely agree that must be prevented. I'm trying to suggest that xp_CmdShell isn't the problem and that the very security gaps that you're talking about are. Simply turning off xp_CmdShell won't fix nor help those gaps. even deleting the DLL for xp_CmdShell won't help because someone with "SA" privs can and will get to the command prompt without it.

    And you call my position "untenable"?

    You bet 🙂

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • September 21, 2012 at 9:36 pm

    #1541037

    opc.three (9/21/2012)

    Jeff Moden (9/21/2012)

    opc.three (9/21/2012)

    Yikes. The more we talk about this the more your approach to security sounds like 'why bother.'

    I am actually becoming quite astonished that you're trying to defend an untenable position.

    BWAAA-HAAA!!!!! You're talking about security gaps that will allow someone to get in with "SA" privs and I absolutely agree that must be prevented. I'm trying to suggest that xp_CmdShell isn't the problem and that the very security gaps that you're talking about are. Simply turning off xp_CmdShell won't fix nor help those gaps. even deleting the DLL for xp_CmdShell won't help because someone with "SA" privs can and will get to the command prompt without it.

    And you call my position "untenable"?

    You bet 🙂

    Good enough. Let me ask just one final question of you if you don't mind. If an attacker breaks into an SQL Server and attains "SA" privs, do you know of any method that will prevent the attacker from getting to the Command Prompt level? I'm not trying to be a smart guy here, Orlando. I'd really like to know.

    Actually, if there's anyone out there that reads this and can provide a method, I'd sure appreciate it. Thanks folks.

    --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

  • September 21, 2012 at 10:11 pm

    #1541041

    Jeff Moden (9/21/2012)

    opc.three (9/21/2012)

    Jeff Moden (9/21/2012)

    opc.three (9/21/2012)

    Yikes. The more we talk about this the more your approach to security sounds like 'why bother.'

    I am actually becoming quite astonished that you're trying to defend an untenable position.

    BWAAA-HAAA!!!!! You're talking about security gaps that will allow someone to get in with "SA" privs and I absolutely agree that must be prevented. I'm trying to suggest that xp_CmdShell isn't the problem and that the very security gaps that you're talking about are. Simply turning off xp_CmdShell won't fix nor help those gaps. even deleting the DLL for xp_CmdShell won't help because someone with "SA" privs can and will get to the command prompt without it.

    And you call my position "untenable"?

    You bet 🙂

    Good enough. Let me ask just one final question of you if you don't mind. If an attacker breaks into an SQL Server and attains "SA" privs, do you know of any method that will prevent the attacker from getting to the Command Prompt level? I'm not trying to be a smart guy here, Orlando. I'd really like to know.

    Nope, not that I know of, not on 2005 or newer. I would love to be proven wrong here. As far as I know all we can do is make it more difficult and raise all kinds of red flags if someone tries it, and I am compelled to do just that. Obviously you are not subscribed to that same line of thinking and that's perfectly fine but I remain astonished.

    It would be useful to be able to uninstall the xp to be honest, i.e. to make it required to choose the feature during installation and to have to run the installation to add the feature if it was not previosuly installed making it otherwise innaccessible from T-SQL regardless of server role membership. I would vote for the same treatment for the sp_OA procs as well as ad hoc distributed queries and the CLR. All in-built features (e.g. the Geography data type) would retain access to what they needed to function but nothing would be exposed via a T-SQL interface. Maybe opening a Connect item is worth exploring. SQL Server is already considered one of the most secure commercial RDBMS'es out there but these steps would help further harden the platform.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • September 21, 2012 at 11:11 pm

    #1541045

    opc.three (9/21/2012)

    Obviously you are not subscribed to that same line of thinking and that's perfectly fine but I remain astonished.

    Now you're putting words in my mouth, Orlando. I'm absolutely subscribed to making it as difficult as possible to for attackers both inside and out. The only difference between thee and me is that I think it's a futile action to disable xp_CmdShell whereas you do not. Don't get me wrong. I'll never give non-SA users privs to run it directly and I don't give anyone but DBAs "SA" privs. Shoot, I have to be pressed pretty hard just to give anyone more than PUBLIC privs and then the request must be both defensible and in writing.

    --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

  • September 21, 2012 at 11:29 pm

    #1541046

    Sorry, that was an extension of my view and your position. By willfully enabling xp_cmdshell, your position, you have made it easier to be attacked, my view, therefore you are willfully making it easier to be attacked.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

Viewing 13 posts - 31 through 42 (of 42 total)

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