September 8, 2009 at 9:54 pm
Comments posted to this topic are about the item Finding Passwords
September 9, 2009 at 5:52 am
from the faq @ http://www.sentrigo.com/passwordizer-faq
Are all user logins affected?
The vulnerability exists only when using mixed authentication in the SQL Server, which is typically used by DBA’s, system administrators, developers, and application programmers . If you cannot install the utility, we strongly recommend you use Windows Authentication only, in which case you will not be exposed to the vulnerability.
so TURN OFF MIXED MODE today, and make your server more secure!
September 9, 2009 at 6:06 am
As Steve pointed out in his podcast, having plain text passwords for SQL Logins in memory is not a major threat and that too when only sysadmins can see them.
Sysadmins have all the rights on their server already to do any activity and can reset passwords. There are better ways to secure a server than using this utility to mess with a production server's memory contents.
-------------------------------------------------
-Amit
Give a man a fish and he'll ask for a lemon. Teach a man to fish and he wont get paged on weekends !! :w00t: - desparately trying to fish [/size]
September 9, 2009 at 7:03 am
Of course an admin is receiving considerable trust anyway. But giving them possession of all other users' passwords is something else again. As you say, they can impersonate the finance officer and get the server upgrade that was rejected last month... it's for the company's good really, isn't it?
I mean, have I got this wrong: I can change your password to what I want it to be. But I can't change it back, or can I? Someone will know I've been fiddling.
My organisation has mixed clients, not all running Windows. We develop in Java. Two ways for Microsoft to be very unhappy with us, so I'm not sure why we even picked their SQL Server. They'd love to say "Sorry - you can only use SQL Server with Windows clients now!" (But our desktop application doesn't get a connection to SQL Server, we're 3-tier. I think we still pay Microsoft for each user, Windows or not...)
If Microsoft starts making umbrellas then it'll be compulsory for new PCs to have an open wire mesh topside. Yeah, laptops too. Sure, they'll dress it up with talk about low-CO2 fanless cooling...
September 9, 2009 at 7:19 am
Good editorial!!
I fully agree with your comments on this and am wondering if this is not just another way for Sentrigo to get some press and possible clients. Have you downloaded the tool? It asks for a lot of information for a "free" tool.
We seem to be in a better position then most others as we use a product called SecureSphere from Imperva that acts like a SQL firewall. Works very well can protects from this issue too. (no.. this not a plug for yet another vendor).
Lets face it, has anyone hear of passwords been stolen via server memory? SQL Injection yes, server memory, none with my eyes or ears.
Here's an thought for everyone. Maybe Microsoft released this information on purpose to Sentrigo. Knowing that it would get out and thus helping to push companies off of SQL 2000 / 2005 and move ahead with 2008 / 2008 R2?
Rudy
September 9, 2009 at 8:06 am
If sql server can not do the job then of course I'd use other programs to do them if it is needed.
I find these weaknesses and lack of professionalism annoying with the sql server team.
Like Steve argues it might not be the issue to some people but I believe it's more work to go throu the hash than fast and easily take a password from the memory. Considering some likes to call ms sql the ms sql OS, things like these are not acceptable.
September 9, 2009 at 8:27 am
The bigger worry, for me, is that someone's SQL auth pwd is likely their password elsewhere. Lots of people use the same password at work, for their Windows login, at their bank site, etc.
September 9, 2009 at 8:30 am
If people are using 1 password for many things then part of the issue is end user training. No patch or free app will fix that.
Rudy
September 9, 2009 at 9:15 am
rja.carnegie (9/9/2009)
I mean, have I got this wrong: I can change your password to what I want it to be. But I can't change it back, or can I? Someone will know I've been fiddling.
I'm pretty sure it is possible. If the server is configured to prevent direct updates to the system tables (hopefully it is) it is a bit trickier, but I believe it IS possible.
Andrew
--Andrew
September 9, 2009 at 9:31 am
The issue is not so much the specific vulnerability as the fact that some developer at Microsoft didn't think it was a problem to store passwords in memory as plaintext. While Microsoft is getting better, their culture of persuing marketable features over boring but necessary security is bound to cause them (and us) grief for years to come.
September 9, 2009 at 9:58 am
If it's a good idea for admins to have access to this information, why doesn't MS make the passwords visible for admins? If it's not supposed to be admin-visible for security reasons then this utility provides a "patch" for MS until they can get this fixed.
Many users reuse their user/pass, not a good idea but common. This could potentially give the admin access to other secure resources.
September 9, 2009 at 10:03 am
Andrew (9/9/2009)
rja.carnegie (9/9/2009)
I mean, have I got this wrong: I can change your password to what I want it to be. But I can't change it back, or can I? Someone will know I've been fiddling.I'm pretty sure it is possible. If the server is configured to prevent direct updates to the system tables (hopefully it is) it is a bit trickier, but I believe it IS possible.
Andrew
You can script out the login (with SID and PASSWORD HASH) and then change the password, "do bad things", drop the login, then recreate the login with the script so no one who doesn't have access to the logs (assuming you are logging user creation) can tell anything happened.
I don't think protecting the system tables would help prevent this, since you are using a CREATE USER statement.
The same principal probably works with AD if you have enough permissions (backup password hash and salt, "do bad", restore password hash and salt), so I'm not sure that using Windows Authentication will buy you that much protection from an enterprise admin.
Ultimately you have to be able to trust your sysadmin, we need too much power to do our jobs.
Of course it's usually easier to just go to the user's computer and turn their keyboard over if you want to know their password.
-DW
September 9, 2009 at 10:10 am
Darren Wallace (9/9/2009)
Andrew (9/9/2009)
rja.carnegie (9/9/2009)
I mean, have I got this wrong: I can change your password to what I want it to be. But I can't change it back, or can I? Someone will know I've been fiddling.I'm pretty sure it is possible. If the server is configured to prevent direct updates to the system tables (hopefully it is) it is a bit trickier, but I believe it IS possible.
Andrew
You can script out the login (with SID and PASSWORD HASH) and then change the password, "do bad things", drop the login, then recreate the login with the script so no one who doesn't have access to the logs (assuming you are logging user creation) can tell anything happened.
I was thinking of sp_addlogin, but that's pretty much what I had in mind.
Andrew
--Andrew
September 9, 2009 at 10:44 am
Rudy Panigas (9/9/2009)
If people are using 1 password for many things then part of the issue is end user training. No patch or free app will fix that.
While I agree with this reasoning and that these things are a larger threat, that so many do this reasoning I feel takes away the focus from the issue with an easily hacked server. I feel that where ever there is a vulnerability it should at least be hard to exploit, storing password in memory like this is something I'd expect from a student, not in sql server. That is what I feel brings more questions to the table. How many short cuts are there and how many issues like this one do we live with? You take this issue, you take the reseed still not working etc etc and it adds up to something done in a hurry and without proper testing, do you not agree with this side of the coin? That one problem indicates that there are more, especially when you know that is the case.
September 9, 2009 at 10:58 am
Robert.Smith (9/9/2009)
The issue is not so much the specific vulnerability as the fact that some developer at Microsoft didn't think it was a problem to store passwords in memory as plaintext. While Microsoft is getting better, their culture of persuing marketable features over boring but necessary security is bound to cause them (and us) grief for years to come.
by the sounds of the 'magic password clearing tool' it's not the passwords that are stored in plaintext, but rather the password that was used to login is not zeroed over before the memory is freed. This means that you end up with mostly valid passwords scattered throughout the processes memory - this is probably also why the clearing tool is 'safe' to use, because the memory is not currently allocated on the heap.
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply