| Date: | May 4, 2005 / year-entry #112 |
| Tags: | history;when-people-ask-for-security-holes-as-features |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050504-52/?p=35713 |
| Comments: | 33 |
| Summary: | Sometimes people ask for features that are such blatant security holes I don't know what they were thinking. Is there a way to get the current user's password? I have a program that does some stuff, then reboots the system, and I want to have the current user's password so I can log that user... |
Sometimes people ask for features that are such blatant security holes I don't know what they were thinking.
(Sometimes they don't bother explaining why they need the user's password; they just ask for it.) Imagine the fantastic security hole if this were possible. Anybody could write a program that steals your password without even having to trick you into typing it. They would just call the imaginary For another angle on credential-stealing, read Larry Osterman's discussion of why delegation doesn't work over the network. Even if you didn't want the password itself but merely some sort of "cookie" that could be used to log the user on later, you still have a security hole. Let's call this imaginary function This is just a thinly-disguised |
Comments (33)
Comments are closed. |
What about RebootAndLogMeBackAsSameUser(); – no argument, no password, no cookie, no nothing – a bit more secure :)
Still, no good idea – user should know why system reboots, therefore, rebooting should always be done with a user on the keyboard…
Isn’t your cookie analogy similar to the the existing Remote Assistance Invitations in Windows XP; a short term grant of access to a resource that you currently have access (and rights) to.
Imagine you somehow retrieved the password, now is there a way to reboot the system and auto login user? Just curious, don’t know why should this be needed :-)
waleri,
LogMeOnAsTheSameUser() has the same problem. How does it contact the domain controller to log the user on? You need to contact the DC during the logon process, because things like logon hours might have expired, etc.
You can’t get that information.
When I bought an Intel motherboard recently, it had a bunch of software to install (chipset drivers, monitoring tools, etc). It required several reboots.
Intel had written a "master" install program which installed the necessary componenets one by one, somehow preserving its state between reboots.
One of the first things the installer did was ask for my username, password, and domain. It did this so it could auto-logon after each reboot. It was optional. If I didn’t, I would have to log back in each time.
I was really nervous when I first ran the setup, because I’ve seen so many crappy installers. I figured an install routine that complicated just had to botch up at some point. Surprisingly, it didn’t. That same install of Windows is over 3 years old, not a single problem.
Although, I wondered about the various reboots. Why couldn’t everything be installed at once, and then reboot once? Never figured it out.
It’s true, the user’s login password can’t be accessed by any program, but all the following are 100% accessible:
– MSN messenger password
– Outlook Express, all passwords
– Outlook passwords
– All passwords from "Protected storage" (stored by IE)
– Dial-up passwords
– Network passwords used to access the shares and .NET passwords
Ilya,
Check out how TweakUI automatically logs in a user on startup when you edit the Autologin settings.
It modifies registry keys at
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon
to specify the username/domain/password.
I remember when installing visual studio.net the setup program did something like this…
the real question is HOW ?
How about a "one time pass" where you ask for a special code that lets you bypass the password once? It’s only good for one login, and perhaps for a limited time. And, if you ask for another pass, it invalidates the previous one.
This is a solution to a problem that I don’t have, so it’s just curiosity.
What’s wrong with a RebootIntoCurrentUser() function? Or am I thinking too laterally?
Ok, you want a user’s password?
Stub GINA.
When winlogon calls WlxLoggedOutSAS you call the original GINA’s WlxLoggedOutSAS function. You can use the PWLX_MPR_NOTIFY_INFO to get the password in clear text.
Chris
This is a slight diversion (how shocking!), but your mention of tricking users into typing their password reminded me of the following:
If you leave Outlook 2000 running in the background and for whatever reason connectivity is lost and then restored, it pops up a dialog asking for your username, password and domain. The problem is that the dialog gives no indication of which application it’s tied to, so users don’t know who needs their password, or why.
I always dismiss the dialog just in case, but if I wrote a program that looked similar and all it did was ask for a username and password, I bet I could steal the passwords of 90% of the people who work here.
Boxmonkey,
You raise a good point.
People always hold up OSX’s security model as the "proper way" to do a limited user account. You run as a normal user (not admin), and when an app needs admin privs (say during install), OSX displays a dialog, asking for the admin password.
I always thought this model was a bit of a security placebo. It conditions people to enter their admin password whenever it’s asked for. Also, how hard would it be to craft my own dialog that looks like OSX’s?
msemack:
Some installers on Windows do prompt for admin privs when running as a limited user. (VS.NET for one does.) Unfortunately many installers do not.
RebootIntoCurrentUser: Also poses a problem where lets say for instance, you know a particular user shuts down their computer before they leave the office, you just have to execute that function before the machine shuts down. Then you can later start up the machine with different their credentials, and possibly access encrypted files etc on their account.
There are too many scenarios like this that would make a function like this a big hole.
I see that Pablo has already got to the question I wanted to ask – VS.NET setup used to do something very similar to this a long time ago.
"A lot of installers seem to require reboots every time it might be required…"
99.9% of programs that install and then claim you need to restart to get it to work will, if you’re running XP, work fine without a restart. The only things that seem to be telling the truth are virtual device drivers — CD image drives, etc.
I’m fairly sure than when XP was imminent some claim was made about it never needing rebooting due to installs, etc. It was with much surprise, then, that I discovered that one surefire way of needing a reboot is by running the network setup wizard; one of the options in there (I forget which) invariably requires a reboot to take effect. Service packs, too, require rebooting, although that’s pretty excusable — I guess some OSes can replace the kernel from under themselves, but it’s got to be tricky to pull off… (I wish the Windows Update "your machine needs to be rebooted" message had a "remind me never" option — I’m fed up with dismissing it several times before I’m ready. :)
Autologon.
http://support.microsoft.com/default.aspx?scid=kb;en-us;315231
Dear Windows Development Community,
Never reboot my machine without my permission.
Hugs and Kisses,
Scot Boyd
If you have a "one time pass" or "RebootIntoCurrentUser" you still have problems. One is security: Nobody expects a powered-off machine to be a security hole. And just because the pass can be used only once, you still gave away a pass. Would you give away a one-time key to your house? "But it can be used only once!"
Second is security: In order for you to be authenticated against the domain controller, you have to present your password. But the local computer *doesn’t know your password* (it’s the domain controller that knows your password). In other words, the information isn’t even the local computer’s to give away if it wanted to.
Scott: haha. Care to get a petition going on that? I’d sign it A THOUSAND TIMES.
Oops. Scot. Sorry about that.
Having Windows relogin on boot would be useful during maintainance or program reinstall, but the general rule of thumb I follow with newer systems is to keep the user around to enter the password. I’ve never had anyone complain when I’ve given up the keyboard so they can enter the password (but I’ve also worked on relatively few systems) and then continue with what I’m doing.
My theory on why install programs constantly ask for reboots is installer writers found Windows ran better with their "new" software after a reboot so they asked for it even when it wasn’t needed.
Windows Server 2003 (at least the Small Business Edition) asks for your password during setup so that it can reboot and log back in again.
It even promises it won’t remember it and use it again. :-)
msemack: That’s why Longhorn will have a Protected Admin feature. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/leastprivlh.asp. I agree that it’s way too easy to spoof the admin password prompt. The Run As feature in Windows 2000 and higher suffers the same problem.
It may well be that Windows XP has been designed not to require reboots but unfortunately very few people use Windows XP on its own: most of them run programs on it, and it’s the programs that cause the trouble!
My users get constant problems when trying to install an updated build of my application. The app itself really truly isn’t running (we can check Task Manager and it isn’t) but the .EXE file is still being held open.
When it happens to us, the sysinternals Handles utility reports that explorer.exe is the program that is holding the .EXE file open, so theoretically we could talk the user through "Ctrl+Alt+Del, terminate explorer.exe, install the app, restart explorer.exe"… except that occasionally the culprit is reported as winword.exe instead (the application in question has nothing to do with Word!)
On the whole, it seems simpler and safer to shut down and restart rather than mess around with Task Manager… but it’s a major irritation nonetheless.
Possibly Norton Anti-Virus may be opening and failing to close the .EXE file, and committing its crime in the context of a perfectly innocent process; but that comes straight back to the basic point: however robust you make Windows, some people *are* going to ruin everything by using it to run programs.
well, you *can* actually get the user’s password in old versions of Windows:
http://www.securityfocus.com/archive/1/10924
http://www.microsoft.com/technet/security/bulletin/MS99-052.asp
They also forget Windows does not know the password. It knows the hash. And you need to know the clear password to gen the same hash. Naturally, it do a dictionary attack on itself, but not a solution. Maybe a one time pw as others said.
Wednesday, May 04, 2005 4:02 PM by Mat Hall
> It was with much surprise, then, that I
> discovered that one surefire way of needing
> a reboot is by running the network setup
> wizard; one of the options in there (I
> forget which) invariably requires a reboot
> to take effect.
If your primary IP address is a fixed address then changing the address sometimes requires a reboot. (Why sometimes and why not other times, maybe to be compatible with both Windows 95 and NT?)
Because you’re not logged on.
PingBack from http://wm161.net/2008/04/27/windows-isnt-insecure-it-just-has-idiots/