April 3, 2014 at 8:38 am
muthyala_51 (4/3/2014)
If we disable sa login on the server and all the database owners are sa. Do we see any conflicts in the reboot of the machine or restart of the services?
This is not an issue. SQL Server will prevent the sa account from logging in, but it doesn't affect any objects (databases, for instance), owned by that login.
K. Brian Kelley
@kbriankelley
April 3, 2014 at 9:11 am
K. Brian Kelley (4/2/2014)
Disabling xp_cmdshell is not a false sense of securityThere are several good reasons to do this.
1) They prevent against a mistake by someone with privileges who just doesn't think. For instance, if you shouldn't be running a command shell query from a production server but it's okay from dev, having it turned off in prod will remind them they are on the prod box. We've all been guilty of running a query against the wrong server if we've been a DBA for any length of time.
In that case, you should also make it so that DBAs only have read privs. 😉 There's no difference here between running a bad xp_CmdShell command and a bad TRUNCATE or a DELETE with no WHERE clause.
2) It stops script kiddies and those who don't know much about SQL Server. To get xp_cmdshell back on involves knowing sp_configure and RECONFIGURE. If an attacker only knows the rudiments of how to attack a SQL Server, then this stops their attempt. Yes, they can then go search on the Internet for the answer, but it gives you something they don't want to give up: time.
No it doesn't. Only "SAs" can run or turn xp_CmdShell on unless one has made the horrible mistake of giving casual user privs to run it directly. Ostensibly, only DBAs have "SA" privs and they supposedly aren't "kiddies". An attacker that get's into your server as "SA" is going to hit paydirt whether they use xp_CmdShell or not. An attacker that successfully gets in as "SA" is also very likely using attack software to do such a thing and all of the attack software that I've seen turns on xp_CmdShell as soon as it makes a connection. You're statement is kind of proof that turning it off brings a false sense of security.
3) It can cause a trip against a functioning IDS/IPS. A lot of IDS/IPS will flag the string xp_cmdshell. In order to turn on xp_cmdshell when it has been turned off requires an attacker to execute sp_configure 'xp_cmdshell', 1. Guess what? That triggers the hit. So does the initial xp_cmdshell use, which will fail. It may only give you a few seconds notice, but if the attacker has to search for the answer, your IDS/IPS just tripped, your security folks should get alerted, and you know you're under attack. If it's the case like in #2, that may give you just enough time to break up the attack.
You and I both know that's probably not going to do a thing for anyone on most systems except provide a log that will be written testament that the security team failed to prevent an attack. An attacker doesn't need xp_CmdShell to make a self deleting job that uses an EXEC task. The attack vector the OP described is proof of that (didn't use xp_CmdShell). Having xp_CmdShell turned off will give the minor advantage that you say but I doubt it'll give most DBAs the time to do anything, never mind get an alert. The key is to keep attackers out and, if they do get in, to prevent them from attaining "SA" privs. Anything else is likely to provide a false sense of security that leads people into more lax methods.
It doesn't do a lot.
I'll say. An attacker that is actually smart enough to get in with "SA" privs is absolutely going to know how to turn on xp_CmdShell. But, again, he doesn't even need xp_CmdShell if he can get in with "SA" privs. If he decides to use xp_CmdShell, it'll take his software less than 3ms to turn it on. By the time people react, he'll already have his payload and be gone.
However, to say it provides a false sense of security is incorrect. It's just another way to lay a tripwire to try and detect an attacker. Of course, for #2 and #3, if your organization doesn't have an IDS/IPS set up properly, it's all a moot point.
I guess we'll have to agree to disagree here, ol' friend. There are more cottage and accidental DBAs that think that turning off xp_CmdShell will provide something more than the 3ms "tripwire" you're talking about than there ever was.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2014 at 9:30 am
Jeff Moden (4/3/2014)
[/b]
In that case, you should also make it so that DBAs only have read privs. 😉 There's no difference here between running a bad xp_CmdShell command and a bad TRUNCATE or a DELETE with no WHERE clause.
Hmm, maybe that is why he have the option of DML triggers for data changes and DDL triggers for schema changes...
No it doesn't. Only "SAs" can run or turn xp_CmdShell on unless one has made the horrible mistake of giving casual user privs to run it directly. Ostensibly, only DBAs have "SA" privs and they supposedly aren't "kiddies". An attacker that get's into your server as "SA" is going to hit paydirt whether they use xp_CmdShell or not. An attacker that successfully gets in as "SA" is also very likely using attack software to do such a thing and all of the attack software that I've seen turns on xp_CmdShell as soon as it makes a connection. You're statement is kind of proof that turning it off brings a false sense of security.
Think about what a script kiddie is. A script kiddie is someone who doesn't have any expertise but is using a script or code someone else wrote. The person who wrote coded certain functionality and the script kiddie makes the most of it, because it's usually push button stuff. However, when that stuff doesn't work, they don't know what to do.
So a script or program that a script kiddie uses could possibly get in with a privileged account. For instance, a keylogger trojan gets installed on a DBA's workstation. The script kiddie has the credentials, plugs them into the script, and the script attempts to execute xp_cmdshell. It fails, IDS is tripped, and you know you're under attack.
Don't assume that because someone has a privileged account, they know what to do with it. Malware is often bought and sold that does a lot of tasks for you. The scenario I describe happens frequently every day.
You and I both know that's probably not going to do a thing for anyone on most systems except provide a log that will be written testament that the security team failed to prevent an attack. An attacker doesn't need xp_CmdShell to make a self deleting job that uses an EXEC task. The attack vector the OP described is proof of that (didn't use xp_CmdShell). Having xp_CmdShell turned off will give the minor advantage that you say but I doubt it'll give most DBAs the time to do anything, never mind get an alert. The key is to keep attackers out and, if they do get in, to prevent them from attaining "SA" privs. Anything else is likely to provide a false sense of security that leads people into more lax methods.
Then you've been working with the wrong security/networking teams. IDS/IPS is typically monitoring network traffic not running on the host. It'll see the xp_cmdshell going across the network and alert. This isn't new functionality. It's been around for YEARS. Free IDS like Snort have detected it for years.
K. Brian Kelley
@kbriankelley
April 3, 2014 at 4:28 pm
K. Brian Kelley (4/3/2014)
Then you've been working with the wrong security/networking teams. IDS/IPS is typically monitoring network traffic not running on the host. It'll see the xp_cmdshell going across the network and alert. This isn't new functionality. It's been around for YEARS. Free IDS like Snort have detected it for years.
I get that. My point is that the attack cited on this thread didn't use xp_CmdShell. Having it turned off did nothing to prevent this attack which did everything that one could do with xp_CmdShell.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2014 at 10:15 pm
Jeff,
I wouldn't make that assumption. We've only been given limited info from the forensics done thus far. We've been told:
- tcp/1433 was exposed.
- A SQL Server Agent job was found because it failed.
- It failed because it called a file, a trojan, that wasn't there.
If tcp/1433 was the only port exposed, that means the attack came through SQL Server. Yes, by using an Agent job command shell access is easy. However, did the trojan get onto the system? If it did, how did it get there? While it could have been through SQL Agent, it could have been through xp_cmdshell as well. That would likely be my approach.
Once the server is breached, using xp_cmdshell the trojan is pulled down immediately. Then the SQL Server Agent job is built and scheduled so that the trojan is executed periodically so it can phone home and get its next set of orders or get the command to go back to sleep. If going back to sleep means it ends its process, that makes it that much harder for it to be spotted. You're only going to see it if you happen to catch it when it's running.
Why do that? Because attackers have gotten smart. They realize we're now looking for traffic during off-peak times. So the best time to phone home is when there's a bunch of other traffic. There's more noise, making it harder to spot the malicious traffic. If I'm not based on the same time zone as the server or I don't want to have to actively be on it, I want to schedule the phone home. SQL Agent does the trick.
Yes, Task Scheduler could, too. However, if there's already SQL Server Agent jobs, again, the phone home command gets hidden in the noise. if I put it in Task Scheduler I've got two problems. The first is I may not get the job to run with the credentials I want. The second is there isn't a lot of Task Scheduler jobs. So there's less noise to hide the job.
Therefore, I wouldn't rule out anything. What I've described is a pretty typical hack nowadays, whether SQL Server is part of it or not.
K. Brian Kelley
@kbriankelley
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply