Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Architectural Insight into Microsoft UAC and Avecto Privilege Guard

October 20, 2017

  • Blog
  • Archive

A recent press release from a competitor made some ill-educated statements about Microsoft User Account Control (UAC) and other user mode solutions that control application privileges. The article picked up on a weakness in UAC that has been publicly known since the beta of Windows 7, and then went on to suggest that user mode solutions are not capable of managing application privileges securely and that elevated processes can only be protected at the kernel level.

This is a not only a naive statement, but one that is categorically incorrect. I will provide clear facts to dispel this fallacy, as I explore the internals of UAC and Avecto’s own privilege management solution, Privilege Guard (Edit: now Defendpoint).

As an experienced kernel level developer, I find comments of this nature extremely irritating, as it shows a complete lack of understanding of kernel level drivers and I believe that vendors have a duty to educate and not mislead the market.

Microsoft UAC Architecture

I will begin by addressing UAC, which has a similar architecture to Privilege Guard, as both are implemented in user mode. UAC comprises the Application Information Service (AIS) and the consent.exe program, with the latter responsible for prompting the user securely. At this point, I hope I don’t need to defend Microsoft’s ability to implement kernel level components in the operating system. The simple reason UAC is implemented in user mode is because there are no advantages to implementing it in kernel mode. UAC’s closest predecessor on Windows XP, “Run As”, is also implemented in user mode, through the Secondary Logon service.

Adding unnecessary code to the kernel simply increases the chances of system stability issues and it is a complete misnomer to suggest that code should be implemented in the kernel because it’s more secure. There are many critical security components in Windows that run as system services, because they do not require kernel level components to perform their role. Microsoft themselves had a big drive in Windows 7 to simplify the kernel, removing many of the complex interdependencies and reducing the amount of kernel code, which resulted in MinWin.

There is no good reason for an application privilege management solution to exist in the kernel because all of the APIs that are used by a privilege management solution can be accessed securely from a system service running in user mode. A kernel implementation merely introduces unnecessary stability risks, which is why Microsoft UAC and Avecto Privilege Guard are both implemented in user mode, as system services.

If you are interested in finding out more about the architecture of UAC then I would highly recommend that you refer to Windows Internals, 5th Edition, by Mark Russinovich and David Solomon.

UAC Slider and Code Injection Vulnerability

As for the infamous UAC vulnerability that has been in Windows 7 since the beta, it should be understood that this is purely a configuration issue and all security solutions are only as strong as their policies. The UAC slider is a compromise between security and usability, and it’s unfortunate that UAC can be compromised at any setting other than its most secure setting, where the user is always prompted. Even if UAC was implemented in the kernel, it would suffer from the exact same issue, so don’t be fooled into thinking this is an architectural problem, as one particular vendor would have you believe.

The issue arises because the default setting of UAC will effectively trust all Windows components, allowing them to perform administrative functions without gaining consent from the user. Unfortunately, this allows an arbitrary application running in the user’s session to inject a thread into any trusted Windows process, such as explorer.exe, and then invoke calls to elevated COM methods that will not prompt the user. Without becoming overly technical, this can be used to run an elevated application without the user’s consent. It’s important to understand that UAC is still intercepting these elevated requests, but it is simply letting them through without prompting the user because the calls are initiated by a trusted Windows process, albeit by a rogue thread.

To suggest that UAC and other privilege management solutions will suffer from this problem unless they are implemented at the kernel level is a misconception, and to further suggest that these types of problems can never be fixed or patched is frankly laughable. Microsoft chose not to fix this weakness in UAC because it would mean a radical rethink of the UAC slider, in terms of how much of the operating system is trusted. This is purely a limitation of UAC’s configurability and its lack of granularity. Microsoft clearly state that the slider setting will always be a compromise between security and usability. If your over-riding concern is security then the slider should always be set to its most secure setting, which is to always prompt the user for consent.

Avecto Privilege Guard Architecture

Avecto Privilege Guard shares an almost identical architecture to UAC, where a system level service is responsible for managing the elevation of processes, in conjunction with a number of supporting components, such as Privilege Guard’s secure messaging executable, which provides similar functionality to the consent.exe component in UAC.

Unlike UAC, Privilege Guard allows elevation of applications without giving the user access to an administrator account, which is a more suitable solution for corporate environments. In addition, Privilege Guard has very granular policies, as opposed to a coarse slider, so there is no need to configure broad sweeping policies that would allow trusted Windows components to perform elevated operations without the user’s consent.

Early this year we released a security update for Privilege Guard, which tightened the security applied to a user’s processes, to provide protection against potential code injection threats when weak policies are in place. That said it’s important to follow best practices and ensure that only applications that require administrative rights are added to the Privilege Guard policies.

In some situations it may be appropriate to prompt the user before elevating an application, either to obtain their consent or to warn them of their actions. This can be achieved through Privilege Guard’s custom messaging facility, which utilizes the secure desktop to ensure that messages can’t be tampered with by applications running in the user’s session.

I hope that this post has been informative and explained why Microsoft UAC and any other application privilege management solution should reside in user mode.

Mark Austin,

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

A Zero Trust Approach to Secure Access

Webcasts

Rising CISOs: Ransomware, Cyber Extortion, Cloud Compromise, oh my!

Whitepapers

A Zero Trust Approach to Windows & Mac Endpoint Security

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.