|Hacking Exposed Windows
By Joel Scambray
Have a look inside the third edition of Hacking Exposed Windows : Microsoft Windows Security Secrets and Solutions...
Step 2 of 2:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
by Joel Scambray, with this excerpt from chapter 12, "Windows security features and tools."
User Account Control (UAC) is one of the most discussed and visible aspects of the Windows Vista operating system. This is probably because, unless you've disabled it, it requires your attention more often than any other Windows security feature. On that note, Microsoft publicly states that UAC is not a security boundary, but merely an opportunity for the user to make a decision on whether an action should take place or not. Given that many attacks these days require some form of user intervention, UAC does raise the proverbial bar for attackers. As such, we will discuss some of the finer points of UAC in this section.
The "principle of least privilege" is by no means a new concept. In fact, if you've been in the security realm long you've heard the phrase more times than you'd care to count. Then why, for such a simple concept, is it so difficult to implement? In the software world, two primary factors exist: usability and compatibility. Users and enterprises want a solution that they can use straight out of the box and have it play nice with older or
The challenge here is to create a solution that makes everyone, including the security folks, sleep better at night. That solution involves adding a notch or two between no access and full access. This is exactly what Microsoft did when considering how to secure the Windows Vista operating systems.
Tokens and processes
When a Windows process is created, its access token is populated with the Security Identifier (SID) of the invoking user, the SID of the groups to which the user belongs, the SID of the logon session and a list of system-wide privileges possessed by the user. When a process attempts to interact with another securable object, such as a file, the contents of the process's access token are used in conjunction with the object's security descriptor to determine how the process can interact with the object, such as reading or modifying it. Due to such things as the time zone/printer scenario, users are often surfing the Web and reading emails under the context of the local administrator. As such, exploiting a vulnerability in a mail client and Web browser provides remote attackers with full control of the operating system -- a less than desirable situation, depending on who you are. What if we could simply remove the privileges associated with administrators and other powerful groups from these processes? Wouldn't we be better off?
User Account Control is the compromise between users with administrator privileges and the shortleashing security folks; it's not quite warm porridge or the perfect bed, but it's closer. It allows non-IT users to feel empowered by granting them the ability to change WEP keys, install printers and set the clock without dishing out administrative privileges. To accomplish this, during an interactive logon, UAC leans on the Local Security Authority (LSA) to detect whether the user's token contains any elevated privileges. If it does, the original fully privileged token is stashed away and the LSA performs a second logon with the filtered token. The primary advantage of this is allowing elevated accounts to operate unprivileged until they attempt to perform an action that requires additional privileges.
User Account Control considers the following privileges elevated, and they will therefore be stripped from user tokens upon logon:
By default, this affects the following groups:
- Built-in administrators
- Power Users
- Account Operators
- Server Operators
- Printer Operators
- Backup Operators
- RAS Servers Group
- Windows NT 4.0 Application Compatibility Group
- Network Configuration Operators
- Domain administrators
- Domain Controllers
- Certificate Publishers
- Schema administrators
- Enterprise administrators
- Group Policy administrators
Additionally, if the user is a member of the administrators group, the filtered token will contain a deny-only version of this SID. This will cause Windows to consider the administrator's SID only when evaluating deny Access Control Entries (ACEs) in a object. The user will not be able to access the object unless he has been explicitly granted access or by membership of another group. This can be observed by logging in to Vista as a member of the administrators group and running whomai /all from the command prompt. The following listing is an example of executing this command:
User Name SID
Group Name Type SID Attributes
======================= ======== ====== ========================
BUILTINAdministrators Alias S-1-5-32-544 Group used for deny only
It's also worth noting that UAC does not affect service, network or batch logons. Once the user is logged on with the restricted token, subsequent attempts to perform potentially sensitive actions, such as installing software or interacting with portions of the Control Panel, will cause a dialog box to appear, requesting confirmation that you indeed intend to take this action. Herein lies the greatest challenge to UAC -- convincing users to leave it enabled. Left enabled, UAC plugs a fairly large hole in most organizations' and users' security model: running as administrator.