7

After Vista came out, security professionals argued that UAC wasn't actually a security barrier, and Microsoft eventually admitted it isn't. But the case they were talking about was a local administrator, who just has to click ALLOW on UAC prompts.

But what about non-administrator users, who must enter a password at UAC prompts? In that case, is UAC actually a security barrier?

A related question here hints that the answer is yes, but doesn't say so explicitly: Assuming UAC is enabled, does a non-administrator account offer any security improvements?

  • One reason is due to paradigm shift to the browser, UAC has no effect on exploit. Second reason is mostly due to "Potential unwanted application" installation, UAC has no intelligent o warn the user about the potential harm. – mootmoot Jul 13 '18 at 7:43
  • In any. You can simply bypass it with any decent yes-click emulator. – Overmind Jul 13 '18 at 11:47
  • @Overmind: Have you tried? It's really hard to do that. – Joshua Jul 13 '18 at 15:37
  • The UAC bypass code has been published for years. download.pureftpd.org/pub/misc/UAC.cpp ; you can make anything use it. It's not as simple as clicking any Y/N window, but it's still bypassable even if it gets to spawn. – Overmind Jul 16 '18 at 7:15
4

The phrase "security barrier" can be ambiguous. I think it may be more useful to consider the concept of a security guarantee, sometimes called a security boundary. More here.

Basically, a security guarantee is a statement about the intended behaviour of the software.

Any way to violate a security guarantee (within the appropriate scope) represents a security vulnerability, i.e., a bug or a design flaw. In the case of a security vulnerability in Windows, Microsoft's general policy is to at least attempt to correct the problem. In most cases, this means a security patch, usually via the monthly cumulative updates.

NB: this is not a legal or contractual obligation.

So what about UAC? Well, it depends on both the scenario and the system configuration. Let's go through some of the more obvious and/or interesting cases. [Note to OP: I think you're mostly interested in the last case, so feel free to skip straight to the bottom.]

Default Settings, Admin User

In this case, when you attempt to perform certain tasks that require administrator access, you get the Yes/No dialog.

There is [I believe] a security guarantee that no application (which does not already have administrator privilege) can press the Yes on your behalf, and that the information provided by the dialog about which application is being launched is accurate. [Proviso: I'm not entirely sure what the story is concerning potentially malicious accessibility applications. Can anyone expand on this?]

But in this case that's all irrelevant, because there isn't any security guarantee that an application cannot obtain administrator privilege without bringing up the dialog, and in fact there are a great many well-known techniques for doing so. More here.

Always Notify, Admin User

If you have turned on the "Always Notify" UAC setting, then [I believe] there is a security guarantee that no application can directly gain administrator access, via UAC, without the dialog appearing. More here.

... but still no guarantee that the application will use the admin privileges in the way in which you are expecting. You get to see which application is being launched, but it is your responsibility to check that it is the one you were expecting. Also, you don't see the command line by default, only if you ask for more details; if an application that you trust has dangerous command-line options, a malicious application might take advantage of that, hoping you won't notice them.

... and if any third-party applications are running with admin privilege, they might have vulnerabilities allowing a malicious application to take control. Windows does take some steps to mitigate this risk, e.g., you can't just use a plain old shatter attack, but it can't eliminate all possible methods one application might use to attack another.

... besides, in a typical enterprise environment you can take advantage of the fact that UAC doesn't operate over the network, as described in Joshua's answer. This sort of attack is I suspect even easier and more practical than it sounds.

In practice, these issues significantly limit the effectiveness of this security guarantee, even in the absence of any security vulnerabilities in Windows itself.

(Such security vulnerabilities have existed; for example, Joshua points out that at one point the Task Scheduler allowed an admin user to create elevated tasks without first requiring elevation. Once discovered, it is likely that they will eventually be patched, but they are also likely to be considered low priority.)

[The current user registry hive provides a huge attack surface for a malicious application to attack elevated applications, particularly if you can make changes before the elevated application is launched. Does anyone know whether there are any standard techniques around this? The most obvious approach would be to put a malicious DLL onto the user's PATH, I suspect many applications would be vulnerable to this simple attack.]

Non-Admin User With An Admin Password

This is the case where the logged-on user account is not an administrator, but the user knows an administrator password. All the previous caveats apply.

... plus, a malicious application might mimic the dialog to capture your password, as already discussed in Michael's answer. There are some mitigations in place to make it difficult for a program to use an administrator password to gain admin privilege, but my understanding is that this is not a security guarantee. [Can anyone confirm whether there is a known way to elevate once you've got an admin password? Perhaps via the Task Scheduler, for instance? In many cases this is moot, I guess, since once you've got the password you can use it to RDP in or access the C$ share or whatever from another machine.]

The only really safe approach here is to never provide the administrator password when prompted; instead, switch user and log in with your admin account whenever necessary. Of course this is enough of a pain that only the most punctilious systems administrators will stick to it consistently.

... obviously, if you're doing that, you also need to follow good hygiene in other respects, e.g., you don't download an installer in your non-admin account and then run it from your admin account. But then, you shouldn't really be running a web browser from your admin account either, so catch-22.

Non-Admin User Without Admin Password

We're on firmer ground here. There is an unambiguous security guarantee that a non-admin user will not be able to run an application with admin privilege without providing an administrator password. This isn't new to UAC, but UAC doesn't remove the guarantee either.

Vulnerabilities violating this guarantee are usually called local elevation of privilege vulnerabilities. In most cases they are considered lower priority than vulnerabilities that allow remote attacks, but Microsoft will usually patch them reasonably promptly.

[OK, that depends on your definition of "reasonable". :-)]

  • Considering our discussion with Joshua, maybe change the Always Notify section of your answer to clarify that some of those vulnerable apps are part of Windows. E.g. Task Scheduler until recently, and probably still others. Third-party apps (and network-based bypasses) aren't the only risks. – Sad IT admin Jul 15 '18 at 7:36
  • @SadITadmin, I've added a note about it. That sort of thing does get patched, but perhaps not always as promptly as one might hope. (I discovered a privilege elevation vulnerability in Windows XP many years ago, one which never did get patched in XP itself - it was fixed in Vista though.) – Harry Johnston Jul 15 '18 at 7:54
  • @HarryJohnston - why is "don't download an installer in your non-admin account and then run it from your admin account. But then, you shouldn't really be running a web browser from your admin account either..." important? If no one knows the password for your non-admin account, then the installer won't be tampered with. Also, what is the risk of using a browser between users with different privileges? – Shuzheng Aug 3 '18 at 7:14
  • @user111854, if your non-admin account has been compromised by an attacker, e.g., because of a zero-day vulnerability in your web browser, then anything you download with your non-admin account might be infected. If you then run the infected download with your admin account, the attacker now has admin access. But on the other hand, if you run a web browser in your admin account, your admin account is directly vulnerable to web browser zero-days. UAC does provide some level of protection in the latter case, but subject to all the caveats already mentioned. – Harry Johnston Aug 3 '18 at 7:29
  • ... I guess if you're determined enough (or paranoid enough) you could use wget or a similar tool (in your admin account) to download just the particular installer(s) you need directly from a deep link. – Harry Johnston Aug 3 '18 at 7:32
14

This is not really an answer, but speaking in absolutes with security can be dangerous... so... it depends.

I think when you say "Microsoft said UAC is not a security barrier," this is probably what you mean:

From Security Watch: The long-term effects of User Account Control (2007):

What UAC Is Not

UAC was not deliberately designed to be the most annoying feature in the history of Windows. Rather, this set of technologies was designed to set us on a path where users do not need to expose their systems to potentially malicious code as frequently as they have during the past few years.

In its current form, UAC will not stop really good attackers, or ones who have the help of really good attackers. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time. Users have learned to dismiss dialogs, and so they will until we manage to teach them otherwise. This results from many contributing factors, including the fact that there are too many warning dialogs, that the messages in them are useless, and that many of the manuals for whatever devices users buy include a note to "please click yes to the security warning dialog to dismiss it."

UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. This is a class of attack that has largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That said, UAC definitely changes the nature of such attacks and transforms the rules of the game to be much more like what prevailed on UNIX for more than 20 years.

UAC will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user regardless of the user's privilege. As such, an application, including a malicious one, can access the data. UAC does not, and cannot, change that. It does not eliminate the need to be vigilant, distrustful, and paranoid—attributes we should all instill in our end users at every opportunity.

UAC was not designed to protect an application running with elevated privileges from all attacks by an application that runs with normal privileges in the same login session. While UAC does provide some weak process isolation, it was not a design goal for UAC to sandbox applications from each other.

So what is UAC for? From the same article, we get an answer...

Some of the brightest thinkers in the world on Windows security today, such as Joanna Rutkowska, did understand UAC's purpose. As she put it in a blog post on February 4, 2007, UAC "is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators" (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right, except I would use the term "enable" rather than "force."

This suggests the purpose of UAC was more about enabling users to give up administrative privileges most of the time, without crippling the user experience. UAC is a set of security features that was implemented for the long-game. It forces application developers to work within the boundaries of a standard user where possible, so that users won't need to elevate privileges when they should have been able to work without administrative permission levels.

For your average user, if they don't have administrative privileges on the machine, it will likely be enough of a barrier to keep them from running an installer that requires administrative privileges. But it is by no means a fix-all solution for security.

Bonus Material: Here's a good discussion of UAC from an IT Perspective on RunAs Radio (Episode 376). Richard Campbell carries a recurring theme through RunAs Radio over the years, that if IT has configured things correctly, and the user is doing what they're supposed to be doing, they should never be blocked by a security barrier. It's a lofty goal, but it really is the ideal balance.

I'm going to step out of this question for a moment and take into account the context of another question you've asked: Can I configure Windows Defender to reject competing AV programs?

At your scale of about 30 machines... you might want something like Group Policy as a tool to work with to start locking down machines a little more. But since you're not on a domain-controlled network, you may have to settle for Group Policy's little brother: Local Policy.

Here's a specific group policy object that might be helpful: User Account Control: Behaviour of the elevation prompt for standard users. This setting configures UAC to automatically deny privilege escalation requests. Unfortunately, locking down machines like this will result in more help desk requests if the users don't have the software they need... or the software they use requires administrative privileges.

  • By the way... given that the article I linked is over 10 years old, I think it shows lasting insight on the part of Dr. Johansson that the challenging bits of social engineering and attackers with advanced capabilities remain a constant. – nbering Jul 13 '18 at 5:41
  • 12
    Nice answer. Uac had another effect: it forced many windows programmer to stop assuming every user had root on the system – Stephane Jul 13 '18 at 5:52
  • Thanks. Yes... that is covered somewhat in the linked article. With 10 years of hindsight, I still think that article is bang-on. The fundamental issues that Windows still gets a bad rep for were a result of the convergence of the system design, developer behaviour, and a lack of incentive for users to work in a secure manner. – nbering Jul 13 '18 at 6:00
  • I threw in a link to a podcast episode from 2014 talking about UAC and some other related security features. I really like Richard Campbell's philosophy that if we're doing our job right as IT and Security people, users that are doing what they're supposed to should never be blocked by a security barrier. But if they're off the path, they will experience road blocks very quickly. – nbering Jul 13 '18 at 7:03
  • @Stephane Most of them, the ones that didn't were even harder to deal with though. Had a coworker at a previous job who did something to cripple or disable UAC on his account (how he got around group policy was never explained), although he denied having do so. He was regularly barfing over our code base with stuff that triggered prompts on anyone else's system (eg writing to files in `C:\Program Files\App Name\sub folder`) and insisting nothing was wrong because "works on my machine". Before then when testing on a non-admin account was SOP getting devs to agree it was a bug was easier. – Dan Neely Jul 13 '18 at 14:35
1

I think this question needs to be addressed specifically and thoroughly:

But what about non-administrator users, who must enter a password at UAC prompts? In that case, is UAC actually a security barrier?

Making users enter their password in the UAC prompt actually makes the system overall less secure!

Why?

  • It does not provide any additional security. The way that UAC is implemented, it's not possible for malicious software running with user privileges to click the OK button programmatically in a non-password scenario. Only in a scenario where there is an attacker with physical access to the unlocked system he could theoretically be prevented from doing things that require admin privileges. However...
  • Malicious software running with user privileges (which an attacker with physical access to the unlocked system could easily install) can spoof the UAC password screen and thereby learn the user's password. This cannot happen in the no-password scenario.
  • In which way an application can spoof (assuming latest OS patches have been applied) the password?! It's a secured screen and you can't obviously attach an hook to log the keypresses – Adriano Repetti Jul 13 '18 at 15:50
  • @Borgwardt: that's just a phishing problem. The most effective solution is to just not give users the admin password. But per nbering's answer, then I'd just get hammered with summons to come enter the password. And in my particular case, there's a 50% chance I'd get either promoted to official admin, or fired. – Sad IT admin Jul 13 '18 at 17:15
  • 1
    @AdrianoRepetti: all an app has to do is go full screen and have exactly the same look as the UAC screen. How are you going to tell the difference? – Michael Borgwardt Jul 13 '18 at 18:40
  • Of course you CAN tell it's a secure login screen! It's even more obvious than network credentials dialog. If an user can't tell the difference then he is doomed to be cheated even to enter his credentials in a web page... – Adriano Repetti Jul 13 '18 at 18:53
  • @SadITadmin: How is "just" a phishing problem not a problem? And the point is that UAC is, in fact, a perfectly good security barrier if users are well-informed what it means and careful about only approving requests from trusted sources. The problem is that average users are neither. Whether they have to enter a password or just click OK is irrelevant. There are no technical solutions to this. – Michael Borgwardt Jul 13 '18 at 18:54
1

The current [update: appears to be fixed in newer Windows 10 builds, but should be double checked as the API involved is not equivalent to punching buttons on the screen] UAC bypass is Scheduled Tasks -> Create Task -> [X] Run at highest privilege + [X] do not store users password -> Run task

If Microsoft were to go through the great length required to close it, the previous UAC bypass waits in the wings: Remote desktop to self; present real login screen -> Wait for user to enter password -> use automation to click Yes on UAC elevation prompt. This time, the Mandatory Authorization Control checks that prevent lower-privilege applications from manipulating higher-privilege applications don't work because RDP server is at a high enough level.

The no-RDP-loopback check is in the client not the server. I have managed to connect to localhost with a modified client.

UAC is no security boundary in a professional environment.

In addition, once domain joined, if the current user can elevate to admin on two machines that are currently powered on, then UAC has yet another bypass. According to the documentation, this works even if not domain joined but I can't get it working for local accounts so the documetation might be wrong. OpenSecurityManager() from machine 1 on machine 2. Machine 2 has no idea that the session from machine 1 hasn't elevated and network logins are always elevated. Create new service that does "sc \machine1 create ... binPath="; start it; wait for start to fail; delete service; Create new service that does "sc \machine1 start ..."; and your binary now has Local System.

  • 1
    Seems your current UAC bypass wouldn't enable a non-admin user account to elevate to admin. Your previous UAC bypass is just a phishing attack, and wouldn't enable a non-admin account to elevate either. Or did I misunderstand? – Sad IT admin Jul 13 '18 at 17:23
  • @SadITadmin: Actual limited user getting admin rights is much worse than a UAC bypass. – Joshua Jul 13 '18 at 17:25
  • 1
    Yes, of course. But neither of your UAC bypasses allows a limited (i.e. non-admin) user to gain admin rights, do they? – Sad IT admin Jul 13 '18 at 17:48
  • @SadITadmin: Correct; they do not. – Joshua Jul 13 '18 at 17:56
  • +1. Out of curiosity, does the loopback RDP attack work in the default Windows configuration? (Remote Desktop access is disabled by default, but I'm not sure offhand whether it's really disabled or just blocked by the firewall.) – Harry Johnston Jul 14 '18 at 3:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.