Microsoft rejects call to fix SQL password-exposure risk 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 …
Does this vulnerability show the passwords of users who authenticate using Windows authentication (it could store the password somewhere temporarily) or passwords of SQL users? If it's the latter then this doesn't seem to be a massive issue - I would've thought that any admins would either connect using their Windows credentials or a single SQL admin account.
To me, the SQL accounts should really only be used for system accounts rather than user accounts.
Then why do they make their proprietary version of Kerberos the default for newer Active Directory domains? You never even see the password on the wire (or sitting in memory) at all, just hashes and tokens.
On any NT-based version of Windows, you can't get to the password once you create it. The password is gone; it doesn't exist. You can't pull it back out unless you dump the hashes and run a brute force cracker against it.
The password is never seen again; only the hashes are compared.
Even if you hijack someone's authentication token and are able to impersonate them, you have no idea what their password is.
SQL doesn't need this level of security? Then why bother putting it in the OS? Wouldn't it be easier for Help Desk folks and End Users if an admin could just recover your password and tell you what it is so you don't have to create a new one every time you forget it?
Microsoft is just being a jerk.
So anyone who can obtain proper access can see the passwords.... It may not matter much for the database that is compromised, but knowing that many people use the same password for everything, there is a pandora's box opening for stalking, identity theft, embezzlement, etc.
Imagine a rouge individual in the IT department who just lost his position or is unstable who decides to grabe the favorites and history off the computers of the CEO and board of directors. Using the info and the stolen passwords gains access to their online banking and drains accounts....
Or the IT guy who has a thing for the pretty girl in marketing who keeps rejecting him so he uses it to start reading her email and begins stalking her...
I see many very bad possibilities.....
What is it about Macro$lut when it comes to fixing security issues within their products? If they can be bothered fixing them it6 usually takes months. Otherwise the Eveil Empire basically just bend over, sprerads it's cheeks and farts excuses like "That is the way it is designed to work" or "This is not a security worry"in the face of it's customers.
M$ do not practice "Security through obscurity" so much as "Security through We don't give a flying fuck!"
If the sysadmins wanted to capture passwords before they get encrypted, they have several means of doing so. They already have implicit full access to everything anyways, if you don't trust the admins, you've got bigger issues to worry about.
Also, storing just a password hash on the server is impractical for applications which do not use solely NT authentication and still wish to use single sign on.
A perfect example is how Samba (built on NT authentication) is fundamentally incompatible with the Linux /etc/passwd and is the reason Samba requires it's own redundant user administration tools.
There are of course scripts to help synchronize the password hashes at the time the password is given in the clear, however then it still goes back to trusting the sysadmin who could log passwords to a file.
"On any NT-based version of Windows, you can't get to the password once you create it. The password is gone; it doesn't exist. "
Actually, the password is potentially discoverable every time it is used to log in. The sysadmin need only deploy a version of the client which leaks the password. Given that he is the sysadmin, this is well within his ability, possibly even without alerting the user.
But then again non of this should matter, anything you can do with your login, the sysadmin can do without your login, including forging the logs, or temporarily changing your password to impersonate you when your not around, before restoring the old one.
The only reason a rogue sysadmin would really need your password is if you've foolishly used your password elsewhere.
It stores passwords??????
Comon guys, this is security 101, you should never store passwords, only hashes.
Reminds me of the time I rang BTInternet for a password reset only to be gobsmacked when the minimum wage flunky on the other end actually told me what my password was!
Needless to say I switched ISPs immediately and then spent some considerable time changing passwords for other accounts.
Mines the coat with the SHA-1 on the label
...and remind them that admin-level access to the OS should *not* automatically equate to admin-level access to the software running on that OS.
I help maintain a large database system, and the *last* thing we want is for the UNIX admin people to have access to the contents of the database, simply because they are "root". Can't stop them from copying/deleting/moving the DB files, but they should not be able to read/modify the contents, dammit!
I used to work in a telecoms outfit which stored voucher numbers for prepaid phonage in the database. I explained why this was not a good idea, and also how to hash the values so that the admins couldn't use their access to get/sell free phone calls (at least not easily). Blind bit of good it did. Same mentality at Microsoft, it appears. At least the Linux guys acknowledge that root can be a bad guy too and fix these things (thinking in particular of the gcc/null pointer issue, which is pretty esoteric, but got fixed anyway).
"...and remind them that admin-level access to the OS should *not* automatically equate to admin-level access to the software running on that OS."
This would be ideal. Technically though, if the computer/OS itself has access to the application, which has full access to the data, then the sysadmin can find a way to get full access to the data also even if the application won't expose it directly.
It's the same reason it's impossible to create a foolproof DRM software media player. The very same routines/keys which decode the media for authorized playback can be mimicked to decode the media for unauthorized playback, often with the aid of a simple point and click interface. Media companies continue to try because they are sold on a false marketing gimmick that it is feasible in the first place. In fact it is nothing more than obfustication.
Having admin-level access to the OS *does* automatically equate to potentially having admin-level access to the software. Too many people assume that the passwords implemented in the client protocols will actually be enforced at the data level, but that's just not the case. A great deal can be gleaned from database files with a hex editor alone. Alternatively one need only tweak a few bytes in the database software to make it jump right over the password check entirely.
Face the facts: OS admin + motivation -> can get to data.
The amount of cluelessness displayed by some of the comments is truly astounding.
First, this affects only a legacy authentication mode inherited from Sybase back in the 90s. It's the equivalent of using NTLM instead of Kerberos -- you can force the system to do that, but it's a Bad Idea, and the consequences are upon your head.
Second, as the above implies, Windows authentication ("integrated authentication", in SQL Server parlance) is not affected; it uses the OS-provided mechanisms.
Third, there has to be code running as system, or with similar permissions, _on_ the machine that runs SQL Server. So much for Senrigo's "any user". If an admin opens a database server up for interactive logon by normal users, he should be fired on the spot.
Fourth, the reasons for not fixing the issue are two: (1) Backwards compatibility (yes, some _really_ old apps expect to be able to manipulate the old-style passwords directly) and (2) lack of benefit (why fix deprecated junk?).
Cheers,
Felix.
P.S.: I work for Microsoft, but never in the SQL Server group. I did and do use SQL Server for my hobby, which is unrelated to my job.
If you combine this article with another, yesterday i think, giving the number of people who use the same password across systems ... it is a no brainer that this should be fixed. No one, administrator or otherwise, should be able to read someones passwords as it is in danger of giving them access to other services not related to those that they administer.
That Microsoft has adopted this stance is gobsmacking, but sadly, not unexpected.
It's not an MS thing, it's a user/administrator thing. If a Windows server has been correctly setup the administrator can't automatically access the database data. Having said this the administrator (or root user) will always ultimately be able to get the contents of the database because they are admin/root. This is why noone should ever logon as root or administrator and access to runas/su to these accounts should be heavily monitored.
This post has been deleted by its author
Gawd, with attitudes like that it's no wonder I get so many security updates a month.
I love the circularity of the logic.... let me paraphase the argument:
"There's a security flaw... the admin can do X"
"That's ok, the admin can do anything anyway"
"Well yes, THAT'S THE FLAW!"
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.
"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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
