Applying the Principle of Least Privilege to Windows 7

Transcription

1 1 Applying the Principle of Least Privilege to Windows 7

2 2 Copyright Notice The information contained in this document ( the Material ) is believed to be accurate at the time of printing, but no representation or warranty is given (express or implied) as to its accuracy, completeness or correctness. Avecto Ltd, its associated companies and the publisher accept no liability whatsoever for any direct, indirect or consequential loss or damage arising in any way from any use of or reliance placed on this Material for any purpose. Copyright in the whole and every part of this document belongs to Avecto Ltd ( the Owner ) and may not be used, sold, transferred, copied or reproduced in whole or in part in any manner or form or in or on any media to any person other than in accordance with the terms of the Owner s Agreement or otherwise without the prior written consent of the Owner. Trademarks Microsoft Windows, Windows Vista, Windows Server, Windows PowerShell, ActiveX, Visual C++ and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

3 3 Contents Summary... 4 Windows 7 and User Account Control (UAC)... 5 UAC Overview... 5 The UAC Elevation Process... 5 Limitations of UAC... 6 Policy Based Elevation with Privilege Guard... 8 Privilege Guard Overview... 8 Privilege Guard Benefits... 8 Conclusion About Avecto... 11

4 4 Summary This paper introduces the application of least privilege on Windows 7 (and applies equally to Windows Vista). It provides an overview of User Account Control (UAC), its benefits and limitations, and why a policy driven approach is more suitable for corporate environments.

5 5 Windows 7 and User Account Control (UAC) UAC Overview Microsoft has continued to improve the security in each version of Windows and as a result have reduced the operating system s attack surface. One of the most common and wide spread security holes has been the granting of administrator privileges, to otherwise standard users, often to resolve application and configuration issues. User Account Control (UAC) was introduced in Windows Vista to mitigate the risks of logging on with an administrator account. If a user is logged on as a local administrator then UAC disables a user s administrator rights and prompts the user when their administrator rights are required. If a user logs on as a standard user they are asked to provide the credentials of an administrator account if they attempt to perform any task that requires administrator rights. Ultimately the user has control over when to use administrator privileges as UAC does not have the ability to be controlled via centralized policy. Standard users must still have access to an administrator account to perform administrative tasks, which makes it less suitable for most corporate environments, as the user may freely abuse these privileges, as decisions to run applications with administrator rights are at the discretion of the user. The UAC Elevation Process When a user logs on with administrator rights, in addition to creating an access token corresponding to this privileged account, a filtered token is also created. The filtered token has the administrator rights removed, and is only granted the privileges of a standard user. Processes launched by the user are assigned the filtered token by default. Applications that require administrator rights can be marked by the developer as requiring elevation, and many of the system configuration applications in Windows are marked as requiring elevation. When an application requires elevation the user is prompted with a UAC consent dialog. If the user approves the elevation then the application runs with the unfiltered token, which includes their full administrator rights. UAC also has heuristic rules that it applies to determine whether an application is likely to require elevation even though it may not be marked as requiring elevation. This is aimed at trying to handle applications that are not UAC aware. If all else fails the user can run any application with the unfiltered token by using the shell context menu and selecting the Run as administrator option. It should be noted that elevation can only occur when a process starts, so once an application is running with a filtered token it is not possible for the process to ask for elevation during execution. A prime example of this limitation, which is imposed by the operating system, is task manager. By default task manager will run with the filtered token, but if the user clicks the Show processes for all users button then task manager will prompt

6 6 for elevation. Task manager achieves this by spawning a new task manager process, which asks the user for consent to elevate. If the user agrees to the consent dialog then the original task manager will exit with the elevated task manager taking over. Standard users are treated differently with UAC, in that they only have a single access token when they logon, as they do not have administrator rights. When an application requires elevation the user is prompted, but this time they will be asked to enter the credentials of an administrator account. Assuming they have access to an administrator account then the user can enter the credentials and the application will launch with an access token created with these privileged credentials. The end result is not dissimilar to Run As on Windows XP, where the processes running with administrator rights are running under a different user account. Although UAC is a welcome addition to the security features within Windows, and reduces the threat of running with elevated privileges, it was met with mixed reactions. In order to alleviate this, Microsoft made a number of changes to UAC with the release of Windows 7. The main aim was to automatically elevate actions carried out by administrators when using trusted Windows configuration options, thereby reducing the number of UAC prompts. Third party software will still trigger an elevation prompt and administrators also have the option to change UAC behavior using the UAC Slider, ranging from Always notify to Never notify. However the ability to reduce the notification level of UAC becomes a compromise between security and usability. For standard users the behavior of UAC on Windows 7 is the same as Windows Vista. The user will always receive an elevation prompt, regardless of the notification level, as they must enter the credentials of an administrator account in order to run any application with elevated rights. Providing standard users with alternate administrator credentials opens the environment to abuse, allowing users to elevate applications and features which have not been authorized by central IT. Users need to manage multiple accounts and running applications under different credentials can cause a whole host of issues, as the applications do not have access to the user s profile or environment. Limitations of UAC When used in a corporate environment UAC suffers from a number of issues: The user must be an administrator or have access to an administrator account in order to make use of UAC. The user is in complete control and may run any application with administrator rights. There is no way to limit UAC to particular applications. Although the number of end user prompts can be reduced, it is the operating system that determines when to show a prompt to the user. It is not possible to restrict these

7 7 prompts to specific applications or to configure the message to be more suitable for a corporate environment. Applications either run with standard user rights or full administrator rights. It is not possible to assign more limited rights to an application, such as specific privileges. There is no audit trail of applications that the user has launched with administrator rights.

8 8 Policy Based Elevation with Privilege Guard Privilege Guard Overview Although UAC provides obvious security benefits, it has serious limitations for corporate environments, which were outlined earlier in this paper. The primary concern is that users must either be a member of the local administrators group or have access to an administrator account for UAC to launch an application with elevated rights. This gives the user far too much freedom to make decisions that could lead to serious security issues or operational problems. The lack of an audit trail makes it difficult to detect deliberate or accidental abuse of these privileges. Avecto Privilege Guard introduces a policy driven approach for controlling administrator rights in corporate environments. Privilege Guard can automatically elevate individual applications, based on policy settings, without granting the user access to an administrator account. All applications run in the context of a standard user account and Privilege Guard elevates the process token for applications that require administrator rights. The decision to run an application with administrator rights is defined by Privilege Guard policy settings and not by UAC, ensuring the IT department has complete control over which applications should be granted administrator rights. For advanced users, a shell integration option enables users to elevate applications on demand, but unlike the Run as administrator option in Windows 7, all applications run under a single user account, with the user never having access to an administrator account. Privilege Guard automatically suppresses UAC prompts for applications that are under its control. In addition, Privilege Guard may be configured to replace any remaining UAC prompts with custom messages to the end user, avoiding unnecessary help desk calls, given the confusion that these prompts may create. Finally, all elevated applications may be audited, providing complete visibility to the IT department. If more detailed application forensics are required then Privilege Monitoring may be enabled in the Privilege Guard policies, which will provide detailed auditing of all privileged operations. Privilege Guard Benefits Privilege Guard provides the following benefits when used on Windows 7: Removes the need to give a user administrator rights or access to an administrator account. Allows applications to be elevated under a standard user account, based on policy settings.

9 9 Eliminates or replaces inappropriate UAC prompts and consent dialogs. Enables advanced users to elevate applications on demand from a standard user account. Provides visibility to the IT department through auditing of elevated applications, including detailed application forensics of privileged operations, if required.

10 10 Conclusion This paper has provided an overview of UAC in Windows 7, and outlined the benefits and limitations. Although UAC is a welcome addition to Windows, its user driven approach makes it less practical for corporate environments. Policy driven approaches are more suitable for corporate environments and Avecto Privilege Guard provides such an approach. It is centrally managed through Active Directory Group Policy, eliminating the need to provide users with access to an account with administrator rights. Privilege Guard ensures that decisions to run applications with elevated rights are made by the IT department and not by the user, with all privileged activity being audited.

11 11 About Avecto Avecto is a pioneer in least privilege management, helping organizations to deploy secure and compliant desktops and servers. With its innovative Privilege Guard technology, organizations can now empower all Windows based desktop and server users with the privileges they require to perform their roles, without compromising the integrity and security of their systems. Customers of all sizes rely on Avecto to reduce operating expenses and strengthen security across their Windows based environments. Our mission is to enable our customers to lower operating costs and improve system security by implementing least privilege. Avecto is building a worldwide channel of partners and system integrators and is headquartered in Manchester, UK. For more information, visit