September 3, 2009 at 8:47 am
I'm not sure how much of a problem this is, but I wanted to point it out:
September 3, 2009 at 9:36 am
I'd say it's a problem that should be fixed, but it's a minor one.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 3, 2009 at 10:33 am
Yup, there are bigger problems if you've got a rogue admin on your hands. And there are more worrisome vulnerabilities out there. *cough* IIS5/6 FTP *cough*
K. Brian Kelley
@kbriankelley
September 3, 2009 at 10:50 am
I too think it is a small issue for 99.9% of the servers out there. For that 0.1% there is the tool that you can download.
CEWII
September 4, 2009 at 5:34 am
I think that you have to think about how this can be exploited and what people tend to forget.
Yes, it can only be exploited by administrators and people tend to focus purely on that, saying that admins have the power anyways so what difference does it make.
However what people forget, is that in a lot of financial organisations, sysadmin access and DBA actions are audited independently and in some cases there is more focus on DBA's than other users.
The ability to see passwords for other logins can be used maliciously by either impersonating/logging in using those accounts and doing malicious activities as changing data. or if those logins and passwords are given to people outside of the organisation.
A lot of banks use what is called segregation of duties where DBA's do not do login managment. So DBA's have nothing to do with passwords or creating users. there is a separate team which does it all based on a template request from a user, and they assign the password that is used. so a DBA does not know the password. the same can occur for sa accounts as well depending on the company.
The ability to see passwords regardless of the method, merits watching in my opinion.
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
September 4, 2009 at 7:39 am
Silverfox,
I think that we are talking about the 1%. I think it should be fixed, but I'm not going to get all in a tizy over it. The fact that it requires administrative level access to even pull it off does not negate it as an issue, but it sure does minimize its risk. You have to have a certain level of trust in your people, if you don't why are they working for you in that role? But on the same token a locked door is really only there to keep honest people honest. How many times do we hear of crimes of opportunity, this isn't that. DBAs in every environment that I have worked in are highly trusted individuals, not that activity is not logged, but they have rights to obscene amounts of data and if the don't trust us to use good judgement then we shouldn't be doing this job.
Bottom line, MS should fix it in 2005, 2000 is effective EOL and you should be moving anyway.
CEWII
September 4, 2009 at 7:55 am
The issue, in my mind, is that even if this is fixed, a rouge administrator can use tools to crack these password hashes relatively easily and impersonate someone. So this is a minor issue (to me), that ought to be fixed at some point, but isn't critical.
It's not that this makes it easier for administrators to get passwords, since I'm not sure it does.
September 4, 2009 at 8:18 am
The thing is, it is not only the dba's that can have sysadmin access on a box, that is something that has not been mentioned. Windows administrators and even management, as well as testers and developers can all under certain circumstances have sysadmin access on a box. I am not the tizzy sort, just being factual. dont get your knickers in a twist 😛
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
September 4, 2009 at 8:46 am
Law #6 of the 10 Immutable Laws of Security:
"A computer is only as secure as the administrator is trustworthy."
Look, if I am an admin, and unless you're on Windows Server 2008 I've got the service account password. In seconds. And I also can pull cached credentials from a DBA's login. This is well known in the security world. That's why the security world as a whole isn't making a big deal of it. Microsoft's assessment is basically right on. Yes, it's an issue, but not a significant threat compared to the known methods that already work and work well.
K. Brian Kelley
@kbriankelley
September 4, 2009 at 1:36 pm
As far as falsifying credentials goes, I'm pretty sure you could get away with using "setuser" for that more easily than you can pull a password out of RAM anyway.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 4, 2009 at 1:48 pm
SETUSER was my first thought. If it's SQL related, then that covers tracks.
However since so many people use the same pwd on other systems, getting the hash from SQL and cracking it (or from memory), could be an issue in other places.
September 4, 2009 at 2:13 pm
The problem is a standard security one, if you own the box (i.e. you are an admin) you can do what you like. In the case of sql you can copy the data files onto another machine where you are sa or even open the mdf files with a hex editor.
You can add auditing but what is to stop them pulling the power and booting from somthing other than the hard drive and then copying files??
Like others have already said if you can't trust your admins...
September 4, 2009 at 2:35 pm
Where are the days, when removing builtin\administrators was enough to be considered "secure". :w00t::hehe:
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
September 4, 2009 at 2:37 pm
That was a fallacy. It never was.
K. Brian Kelley
@kbriankelley
September 4, 2009 at 3:51 pm
GSquared (9/4/2009)
As far as falsifying credentials goes, I'm pretty sure you could get away with using "setuser" for that more easily than you can pull a password out of RAM anyway.
And any sysadmin login has impersonate rights on all logins. Unless the auditing is using OriginalLogin (which it should be), that's an easy way to impersonate any user in the system.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply