It rather involved being on the other side of this airtight hatchway: Reading the user’s saved passwords
A security vulnerability report claimed that a particular program did not store its saved passwords in the Windows Credential Manager securely:
Microsoft’s Contoso program does not encrypt user passwords before saving them in the Windows Credential Manager. As a result, any program that runs with the user’s credentials can read the passwords. The Contoso program should save encrypted passwords in the Credential Manager.
There was another report that put the blame on Credential Manager:
Credential Manager should require administrator privileges to read a user’s saved credentials.
The perceived issue here is that one program can read the passwords saved by another program, and that other program should encrypt its passwords so that they can be decrypted only by that program. Rogue programs enumerating the contents of the user’s saved credentials would be stymied because they don’t know how to decrypt the data.
But if you have gained the ability to execute code in the context of the victim, then you’ve already won. You can do anything the victim can do!
It’s like saying, “I am a bad guy from a 1960’s spy movie. I have successfully hypnotized the victim into obeying all of my commands, while nevertheless behaving perfectly normally. I tell the victim to go to the bank, withdraw all their money, and bring it to me. This is a security flaw in the bank. It should not allow hypnotized people to withdraw money!”
The bank did its job, which is to confirm the identity of the person withdrawing the money. The person at the counter did nothing to draw suspicion, and all the paperwork checked out, so they got their money.
The system sees that there is a process running as the user, and that process is asking for the password that the user had saved earlier. Now, certainly, users are permitted to access the passwords that they had saved (that being the point of saving the password), and the Credential Manager is correct in returning those saved passwords to that user. The information is not being disclosed to other users: Users can access their own saved passwords, but they cannot access the saved passwords of other users.
Encrypting the data before putting it in the password cache sounds like it would stop an attacker, but it doesn’t. Since the original program must be able to decrypt the data, the attacker can analyze the original program and re-run the decryption function. If the attacker is being lazy, they can just run the original program and set a breakpoint immediately after it decrypts the password.
You might think that you could protect yourself from hypnosis-induced bank withdrawal by telling the bank, “Before giving me any money, make sure to ask me this secret security question.” But that doesn’t help, because even though you’ve been hypnotized, you still know the answer to the secret security question. The hypnotized-you goes to the bank, the bank teller asks the security question, you answer it, get your money, and give it to the 1960’s evil bad guy.
And of course requiring administrator privileges to retrieve your own saved passwords would be a non-starter. Every time you want to use a saved password, you have to call your administrator to get it for you?
Allowing users to retrieve their own saved passwords is perfectly normal behavior. No security boundary is crossed, and the information is disclosed only to the user who put the information there in the first place.
If you let someone run arbitrary programs under your identity, you have handed over control of everything tied to your identity, and that includes your saved passwords.
Bonus bogus vulnerability: Suppose you create a shortcut to the command line runas /savecred /user:.\administrator someprogram.exe, and you run the shortcut, and an administrator comes over and types their password when prompted. A security vulnerability report claimed that there is an elevation of privilege vulnerability because an attacker can edit the shortcut to read runas /savecred /user:.\administrator cmd.exe and gain an administrative command prompt.
That’s true, but that’s also the whole point of /savecred.
The /savecred option means “Use the saved credentials from the Credential Manager, or prompt for credentials (and save them in the Credential Manager).” They are not saved in the shortcut at all. Not that saving them in the shortcut is even an option, because you can run runas from a command prompt, and in that case there’s no shortcut.
If you call over an administrator and get them to type their password into your system, then you found yourself a gullible administrator. In this case, what you tricked them into doing is adding their password to your password cache. It’s like calling an administrator to your Web browser and asking them to type their password into a Web site. That password is going to be saved in to your Web browser password cache, and you can now extract it from that cache and reuse it for anything you like.
The point of /savecred is to let you save your own credentials so you don’t have the hassle of typing them over and over into places you use often. If you can trick an administrator into putting their password into your saved credential cache, then more power to you (and shame on the administrator).
Don’t be a gullible administrator.
Light
Dark
9 comments
It’s frustrating that almost every single one of these posts could be summarized as:
Windows security model doesn’t match up to many peoples expectations of what a security model should do, and doesn’t match the security goals of some newer and more modern operating systems people interact with regularly. Users want their files, their passwords, their data protected from their software, whereas Windows protects itself and the underlying system from users, and users from other users. Operating systems like iOS allow them to meet their goals, I would not expect that a random iOS app would be able to delete my photos unless I gave it such permissions explicitly. Not quite sure how to bridge this gap.
I completely understand that there are tons of historical, compatibility, and other complex reasons for why this is. And I’ve even seen how attempts to change this (with the newer Windows APIs) have not gone very well, due to these issues. But that doesn’t change the fact that there is a huge mismatch between these expectations and reality.
Well summarized. It was difficult for me to wrap my head around this concept, but it truly is as you put it, Windows protects itself and the underlying system. Like some sort of HR department focused on protecting the company rather than the employee.
The Windows API is already pretty well organized, so it shouldn’t be impossible to create a few groups of application types, with varying levels of access (like “Restricted”, “Internet”, “Debuggers and Development”, “Raw disk access”, “Location”, etc.). Or just use the same permissions as on a mobile phone. If I download an application and run it, I don’t want it to have immediate access to the Internet, to the Credential Manager, or raw access to the disk and to the memory of other processes.
The OS is always on the other side of an airtight hatchway, apparently. Maybe it’s time to grace the user with a measly decompression chamber.
That classification already exists. They’re called UWP app capabilities. So stay in the UWP walled garden.
Speak for yourself about your expectations. As a user I fully expect to be able to access MY data with whichever program I run, whether the OS designer thought that was okay or not.
Please stop trying to turn usable operating systems into Fischer Price locked down useless-for-real-work toys. We have those already (iOS as you mention), you can just use that.
Wow whenever someone suggests a change that would break useful functionality in software because they are lazy and don’t want to be responsible for their own actions I always feel irrationally angry about it.
That said this person may be coming from a more locked-down OS like Android where all apps are sandboxed from each other, and apps are digitally signed so an attacker would be hard-pressed to get access to an app’s data outside of the app’s interface. Such OSs have their place, as do OSs which give users more freedom.
Yeah it makes me angry too.
Windows has the feature you’re asking about. It exists in apps coming from the App Store (or any app running in the sandbox). Each app in the store has to list the permissions it wants from the user and the user must confirm they grant access before installing. The problem with this approach, as can be seen with Android apps easily, is that the permissions are not fine grained enough in many cases or an app asks for all permissions, which completely defeats the purpose. I can’t count how many times I’ve refused to install an app because it wants access to my contacts even though it doesn’t do anything with contacts. This feature, while useful from a security standpoint, only works if apps try to lock down their permissions and users actually care. In my experience neither occurs. It is easier to ask for all permissions AND users want the app and will just agree to anything the app asks for. Even worse is that an app could ask for limited permissions and then later, in an update, change their permissions to ask for more. For an update users aren’t paying any attention.
The issue with Windows is that you can run anything and you can definitely lock down the app to prevent access but Windows is so much more flexible than Android/iOS that it would be a painful process. Furthermore, unlike a stringent API like Android/iOS have, a Windows app can call any # of APIs and don’t have to be registered/validated in advance. This would make it very difficult to lock down an app because the # of options are just too large. Besides it is pretty clear from the Windows Store reception that Windows users don’t want that feature anyway.
This problem could be solved if the operating system provides an option to expose decoy contact lists to individual apps.
Linux has the concept of “namespaces”, e. g. filesystem namespaces. A filesystem namespace is a full-fledged instance of a filesystem tree with its own root; two filesystem namespaces operates independently from each other, unless you explicitly set up mappings from one to the other. This means you can create a new filesystem namespace, set up mappings for the necessary directories (like
/procand/sys) but nothing more, and run an untrusted program in that namespace. You’ve essentially presented to that program a decoy filesystem to toy with. Software like systemd includes functionalities to perform this technique easily.Windows may actually have the machinery do the same already, seeing it supports things like “filesystem virtualization” and “registry virtualization”, but it doesn’t allow me to use its machinery to e. g. present a fake
C:\Users\MyUsernameto rogue apps yet.This time, the customer is right.
While Windows has remained on the generation-1 security model, in which user accounts are the security boundary and antivirus is necessary, other operating systems, including Android and iOS, have moved on to the generation-2 security model, in which each app is containerized. Apps CANNOT infect each other, read data (including saved credentials) of others, and subvert other apps’ operations.
Microsoft tried to bring that security model to UWP apps, but Microsoft’s version of containerization merely impacts well-behaving apps that never needed containerization. Pavel Yosifovich, the author of the 7th edition of Windows Internals has a good blog post on this subject.