Microsoft rejects call to fix SQL password-exposure risk
Unpatched and staying that way
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Microsoft is butting heads with a company that provides software for database security over a weakness in SQL Server that can expose user passwords to anyone with administrative access to the program.
Researchers at San Mateo, California-based Sentrigo warned Wednesday that the "significant vulnerability" is present in the 2000, 2005, and 2008 versions of SQL Server that use the mixed authentication mode, aka the SQL Server and Windows Authentication Mode. While those with administrative privileges typically have the ability to change others' passwords, they should never be able to view those access codes in the clear, they say.
"Applications go to great lengths to obfuscate passwords when they are needed within the software, and should not store passwords as 'clear text,' either in memory (as is the case with this vulnerability) or on disk," Sentrigo's advisory stated.
Microsoft has rejected the company's calls to change the way the software handles passwords, saying people with administrative rights already have complete control of the system anyway.
"Microsoft has thoroughly investigated claims of vulnerabilities in SQL Server and found that these are not product vulnerabilities requiring Microsoft to issue a security update," a spokesman wrote in an email. "An attacker who has administrative rights already has complete control of the system and can install programs; view, change, or delete data; or create new accounts with full user rights."
He called on customers using SQL Server to follow security guidelines Microsoft has already laid out.
Each side in this kerfuffle has a point. Clearly, the feature exposed by Sentrigo makes it easier for rogue insiders and attackers who breach a network's defenses to sniff out passwords that could aid in additional intrusions. And in the 2000 and 2005 versions of the program, this can be done remotely, raising the possibility that an attack could be done by exploiting a SQL injection vulnerability that gives a hacker administrative access to a backend database.
(Changes in the 2008 versions make it more difficult for users to access the memory, so the vulnerability can only be exploited locally, Sentrigo said).
But given the ability of the average administrator to sniff out credentials a half-dozen other ways, the vulnerability seems to be more a sin of omission. While it probably violates principles of security in depth, most IT pros aren't likely to lose much sleep over it.
For those who do, Sentrigo has released a free utility that provides SQL Server users with additional security by erasing passwords. It's available here. The exposure weakness has been designated CVE-2009-3039 by the common vulnerabilities and exposures project. ®
COMMENTS
@ Use Windows Authentication mode!
By Wolf 1 Posted Wednesday 2nd September 2009 20:41 GMT
"If you use the Windows authentication mode this is a non-issue--and your life is a LOT easier to boot!"
Yes indeedy this is the most frequently deployed technique to be found in distributed SQLServer deployments over corporate networks. I seldom see anything else.
@Peter Gathercole
"By allowing sysadmins to peek at other user's passwords, it enables them to do things as other users while bypassing any audit trail that points back to *THEM*, and leaving a false trail pointing at someone else."
Yes, this is indeed the problem.
"Key loggers and password leaking backdoors should not be able to be installed without again leaving some evidence of the fact."
Idealism, meet reality. You need to think more like a programmer/hacker. If you had a CS background, you'd realize that any application level security can be defeated, even if it doesn't have any bugs.
Here are some ways which could work without leaving a valid security audit trail.
1) Install a hardware key, or hacked keyboard, or even just a wireless keyboard.
2) Install a rogue bios.
3) Run the desktop and/or server in a VM, or on spare hardware such that security audits are never really logged in the right place during the event.
4) Install trojan software under a user's account such that malicious activities really do occur under their name. This could be accomplished by sending a susceptible user a malicious email (custom malware will not match existing antivirus signatures).
5) Use a known or unknown vulnerability in the OS or application to escalate privileges in a way which cannot be traced to the sysadmin.
6) Destroy any evidence and fabricate the logs
7) Extract the user credentials from a legitimate location such as the windows command scheduler, or temporarily change the executable/batch file being executed so that it actually runs from the context of another user's account.
8) Hop onto another user's account which was left unlocked.
9) Send themselves a trojan which appears to be from the outside or another user.
Many of you may not like it, but a motivated rogue sysadmin can always defeat all the protections which they are hired to keep in place. And with enough care, they can do so without leaving an audit trail pointing to themselves.
"As SarBox is mandatory for US financial organisations, does this mean that it should be recommended that SQL Server should now be added to the banned software list, or at least relegated to non-customer and non-financial database use?"
Nope. As pointed out by others, this is a configuration decision and NT authentication is still available. Just because software can be configured insecurity doesn't mean it needs to be banned. By that criteria, I doubt that any software would pass.
@Lou Gosselin
You've obviously never worked anywhere Sarbaine Oxley or Basle II requirements have been applied (like *ANY* Western financial organisation). If you follow these as specified, you have to implement a segregation of authority, meaning that your system administrators cannot subvert the security logs (at least, not without leaving a secure-from-them audit trail). There should be a different part of the organisation who have no ability to change the systems, but who do have authority over the logs, whose job it is to make sure that the sysadmins do not step over the mark.
The problem in a nutshell is that, yes, the sysadmins can do pretty much anything within their control, but this should be subject to audit. By allowing sysadmins to peek at other user's passwords, it enables them to do things as other users while bypassing any audit trail that points back to *THEM*, and leaving a false trail pointing at someone else.
Key loggers and password leaking backdoors should not be able to be installed without again leaving some evidence of the fact.
As SarBox is mandatory for US financial organisations, does this mean that it should be recommended that SQL Server should now be added to the banned software list, or at least relegated to non-customer and non-financial database use?
This behaviour from a major IT provider is just inexcusable.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
