User account control
The User Account Control (also english User Account Control UAC) is a operating system Windows of Microsoft integrated security mechanism with Windows Vista was introduced. The aim of user account control is to improve the security of the system by initially running software with only simple user rights instead of administrator rights. Administrators can arrange for the rights to be increased should the application require them. The user account control was introduced because many users work with administrator privileges which, up to and including Windows XP, were transferred directly to started applications. This behavior represented a major security risk because any malware was also given administrative rights.
If an administrator logs on to the system with active UAC, programs started by him initially only work with the rights of a normal user. As soon as an application requests administrative permissions for its execution, a dialog box is displayed which must be explicitly confirmed in order to grant the rights.
On UNIX systems there is a mechanism with the command line command sudo that can be compared to the user account control. The behavior of the UAC can be adjusted in the local security guidelines. For example, there is also the option of requiring the login password to increase rights.
Furthermore, the UAC is the basis and requirement for sandboxing programs and directories under Windows. It enables the granting of privileges to processes and the isolation of processes and windows that run on the same system with different rights.
Risk and importance of full access rights
Versions of Windows older than or not descended from Windows NT (such as Windows 3.1 , Windows 95 , 98, and ME ) were single-user systems in which each user had full system control. Windows systems of the NT line , on the other hand, are multi-user systems, so that different user roles and rights can be assigned.
Under Windows XP , the user accounts created during installation receive administrator rights. As a result, many individual PCs equipped with Windows XP were operated by default with a user who had full administrator rights. This means that all software, including malware , is started with administrator rights so that it has full access to the system. In many older applications, restricted user rights were not taken into account, although Microsoft made this a minimum requirement in the “Designed for Windows” guidelines published for the first time with Windows 95. If you install or start such software with restricted rights, errors occur or the software does not work properly. In addition, there was the limited user friendliness: In order to be able to call up the calendar in Windows XP by clicking on the time, administrator rights are required. In the past, these problems were often circumvented by always working with administrator rights on single-user computers.
Unix and Unix-like systems (such as macOS from version 10 or e.g. Ubuntu ) were designed as multi-user systems from the start. Every registered user has a home directory for his personal data, where he can edit as he likes. Changes outside of the user account can generally only be made from the root account . This is not activated by default in some Unix-like systems such as Ubuntu. The members of the “Sudoers” group can, however, carry out administrative tasks with the sudo command , which then happens in the context of the rights of the root user. To prevent malware from using sudo, the login password must be entered for authentication to run the command. A special case with regard to Unixoid systems is Android ; Here the user system is not used for user administration, but rather to isolate the apps from one another: a separate "user account" is set up for each app when it is installed, and then the app is installed (as the only one) in its 'home directory'. The actual administration of the (a) real user is done separately; this makes Android basically a single user system. This one (real) user generally has no rights that would correspond to an admin user - Android must be "rooted" for this.
With Windows Vista, which applied Microsoft's Security Development Lifecycle for the first time , a comparable mechanism was introduced with the user account control to implement the principle of least user access or least-privileged user account (LUA) . Members of the Administrators group receive two tokens when they log on: One as an administrator and one as a standard user, who has been deprived of all administrative rights and privileges. These users are known as "Protected Administrators" (PA). While the Sudoers under Unix call their "big brother" with sudo, the Protected Administrators have a split personality, which they change depending on the task. In order to avoid manipulation of the elevation of rights by malware, this takes place by default on the secure desktop.
The end scenario is the same in both cases: Most users only travel with standard user rights and can only edit certain areas of the computer. The administrators of the system, i.e. the members of the Sudoers group or administrators , also work with restricted rights, but can increase these if necessary. In both cases, the principle of the Least-Privileged User Account (LUA) is implemented: everyone only works with the rights that they really need for this task. The book Windows Vista Security: Securing Vista Against Malicious Attacks by Roger A. Grimes (including CISSP , MCSE: Security , MVP ) and Jesper M. Johansson (Senior Security Strategist at Microsoft's Security Technology Unit) is interesting . On three pages they describe in detail the differences and similarities between sudo and UAC, their specific advantages and disadvantages, and why Microsoft decided against introducing a sudo command.
The Runas command has also been implemented in the user account control . The command can be used to carry out administration or administration tasks without a user with administration rights having to log in from scratch. To do this, the account and password of a member of the Administrators group must be entered. This UAC query is known as the “Over-the-shoulder” (OTS) elevation prompt, while the Protected Administrator elevation is known as “Admin Approval Mode” (AAM).
security concept
In addition to an access control list (ACL) and the privileges that were already available under XP for the finer assignment of rights (or prohibitions), the "Integrity Level" was added from Windows NT 6.0 (Vista). In German, this was translated somewhat unfortunately as “binding level”, but “integrity level” is also a common term. The binding level is a security mechanism that has priority over the access control list, i.e. it prevents access even if the access control list would allow it. To this end, every process is given a so-called integrity level (IL) in its access token, which is intended to express how trustworthy it is. The high binding level, together with the administrative privileges, form the two parts of the "administrative key ring", in addition to the access control list.
Integrity levels
Every object in the system is on one of five levels, identified by a label in its security descriptor. The basic idea of the Integrity Levels (IL) is that processes that run at a lower level cannot write to objects at a higher level (no write-up). A process with a lower binding level cannot harm the user data set to “Medium”, and certainly not the system components that are even higher. Access from the bottom to the top is restricted, while everything is allowed on the same level or from top to bottom - within the scope of the access control list. The five levels of integrity are:
- System binding level : The highest level, is only reserved for system processes such as svchost.exe, csrss.exe, winlogon.exe etc. and the user SYSTEM as well as LocalSystem, LocalService and NetworkService.
- High mandatory level: Is the level of the user groups administrators, security operators, network configuration operators and cryptography operators. This is necessary so that their processes cannot be influenced by standard user processes through User Interface Privilege Isolation (UIPI).
- Medium commitment level: Is the level of standard users (authenticated users). Most of the folders and directories on the hard drive have this integrity level, as do the processes of these users.
-
Low mandatory level: Corresponds to the "protected mode" of Internet Explorer , which was the first program to use this sandboxing. On the hard disk there is
%userprofile%\Appdata\LocalLowa directory with a low binding level to which these processes can write.HKCU\Software\AppDataLowAn equivalent directory path with IL “low” is available in the registry . The user group “Everyone” also has this binding level. - Untrustworthy commitment level: corresponds to a sandpit in a sandpit. This integrity level is used for anonymous logins. Since there is no directory path with this IL by default, these processes can only exist in the main memory. The tab of Google Chrome for running. B. with the security descriptor "untrustworthy binding level".
The main goals of Mandatory Integrity Control (MIC) are to separate standard user processes from processes with elevated rights, which is why the Component Object Model also takes the integrity levels into account. Furthermore, the binding levels guarantee write protection in the root directory of the computer, while, on the other hand, applications such as Internet Explorer have only limited options for changing user data and profiles. While generally only "No Write-up" applies to objects, the process management in the NT-6 kernel sets "No Read-up" and "No Write-up" for running processes in order to prevent manipulation of the higher-ranking processes. Only SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION and PROCESS_TERMINATE are possible.
Usually, every application gets the rights of the process that started it. However, this would mean that if a user started Internet Explorer, it would also run with a medium level of commitment. To prevent this, there is the entry TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN in the access token of an account, which is set for user accounts and not set for administrative accounts. If this entry is set, it means that processes that are started cannot get a higher integrity level than was assigned to the EXE file. Since the iexplorer.exe is only assigned the IL "Low", this file is only started at this level for normal users. If the administrator switches off UAC, all of his processes run with a high level of commitment, since the administrative token is assigned to each process. All documents and files that this administrator creates then have the "high" integrity level. If the user account control is now activated again, every process / folder clicked on will only see the standard user token (IL “medium”), which is why he can no longer open these files without admin rights.
The binding level of a folder applies either only to the folder itself (object inherit, OI) or to the entire directory (container inherit, CI). If a file is z. B. moved into %userprofile%\Appdata\LocalLowor a subdirectory of the same, this receives the low binding level, regardless of which it had before (grading provided).
Privileges
The administrative privileges are the second part of the "key ring". Under NT 6.0, the problems that arose when working with a standard user account have been defused by adding new privileges and some tasks are no longer administrative. Under XP, no distinction was made between time zone and system time, although only the latter is relevant for security. As of Vista, there is therefore a distinction between the privilege to change the system time (SeSystemTimePrivilege) and the privilege to change the time zone (SeTimeZonePrivilege). Furthermore, wireless internet connections and energy options of the computer can be configured without admin rights. The installation of critical Windows updates is now also possible as a standard user. In company networks, drivers and ActiveX elements can also be installed from certain sites if this has been approved by the administrators in the group policies. The privileges of the individual groups can be viewed or changed under Start> secpol.msc> Local policies> Assigning user rights . The following list does not contain all privileges and groups for NT 6.X systems. It is only used to illustrate the differences between administrators and users.
| privilege | user | Administrators | designation |
|---|---|---|---|
| SeSystemTimePrivilege |  |
 |
Change the system time |
| SeTimeZonePrivilege | |
|
Change the time zone |
| SeIncreaseBasePriorityPrivilege | |
|
Raising the scheduling priority |
| SeBatchLogonRight | |
|
Log on as a batch job |
| SeDenyRemoteInteractiveLogonRight | |
|
Deny login via remote services |
| SeIncreaseWorkingSetPrivilege | |
|
Increase the workload of a process |
| SeNetworkLogonRight | |
|
Access this computer from the network |
| SeChangeNotifyPrivilege | |
|
Skipping the crawling review |
| SeDebugPrivilege | |
|
Debug programs |
| SeManageVolumePrivilege | |
|
Perform volume maintenance tasks |
| SeUndockPrivilege | |
|
Remove the computer from the docking station |
| SeCreatePagefilePrivilege | |
|
Create a swap file |
| SeSystemProfilePrivilege | |
|
Create a profile of system performance |
| SeProfileSingleProcessPrivilege | |
|
Create a profile for a single process |
| SeCreateGlobalPrivilege | |
|
Create global objects |
| SeCreateSymbolicLinkPrivilege | |
|
Create symbolic links |
| SeRemoteShutdownPrivilege | |
|
Forcing a shutdown from a remote system |
| SeShutdownPrivilege | |
|
Shut down the system |
| SeLoadDriverPrivilege | |
|
Loading and removing device drivers |
| SeInteractiveLogonRight | |
|
Allow login locally |
| SeBackupPrivilege | |
|
Back up files and directories |
| SeTakeOwnershipPrivilege | |
|
Take ownership of files and objects |
| SeSystemEnvironmentPrivilege | |
|
Changing firmware environment variables |
| SeSecurityPrivilege | |
|
Manage monitoring and security logs |
| SeRestorePrivilege | |
|
Restoring files and directories |
technology
mechanism
The user account control consists of the Application Information Service (AIS), the UAC query itself with the secure desktop, the User Interface Privilege Isolation (UIPI), the installation detection and the application / data virtualization. Although the login process for administrators does not differ externally from that under XP, the Local Security Authority (lsass.exe) recognizes this when a member of the Administrators group logs in and creates two access tokens: a user token and an admin token . The user token is now used to start the Windows shell . Explorer.exe is in turn the parent process from which all other processes within the shell inherit their access tokens. All applications run with user rights as if a standard user were to log on. If an application is now running that requires administrator rights, the Application Information Service (AIS) starts a UAC query. If you refuse, the application will not be started; if you agree, it will run with the admin token. If this elevated application is terminated, the process with elevated rights is also terminated.
A UAC query is either provoked when a program in its XML - Manifest requesting increased rights or when the installation detection strikes. This uses a heuristic that recognizes installation routines, since the typical directories ( %programfiles%, %systemroot%\System32\config) can only be written by administrators. Update routines and uninstallation routines are recognized in the same way. The heuristic only works with 32-bit programs if they do not request a manual increase in rights through requestedExecutionLevel, and if LUA (standard user / protected administrator) is active. The heuristic searches for keywords such as “install”, “setup”, “update”, keywords such as provider, company name, product name, file description and name. It also searches for keywords in the side-by-side manifest and in the string tables of the executable file, as well as certain byte sequences and certain properties in RC Data. If an application requests admin rights, the following process takes place: The command ShellExecute (ExampleApp.exe) is sent to AIS ( %SystemRoot%\System32\Appinfo.dll). AIS, which runs within svchost.exe, starts Consent.exe ( %SystemRoot%\System32\Consent.exe). Consent.exe takes a screenshot and applies a darkening effect to the bitmap. Then you switch to a virtual desktop that only belongs to the user Local System (SYSTEM), the bitmap is inserted as the screen background and the query box of the user account control is displayed. This process is known as a secure desktop and prevents malware from influencing the decision.
If the querying program has been digitally signed by Microsoft and the image is in the Windows system directory, the box header is blue . Gray means that the program was digitally signed but not from Microsoft. Yellow stands for unsigned applications / programs and red appears for blocked applications. The icon, description, file name and publisher appear in the prompt, if signed. This is intended as a hurdle for malware to make it more difficult to fake serous software. The command line , which is passed on to increase rights, can be displayed under “Details” . In the case of blue UAC queries, the certificate can also be viewed here. If the user presses "No" / "Cancel", Windows sends an access-denied error to the process that made the request. If the user agrees by pressing "Yes" or entering an administrative password, AIS calls CreateProcessAsUser (ExampleApp.exe) to start the process with administrator identity. Because the process was technically started by AIS, a feature in the CreateProcessAsUser API is used that allows the process ID of the father to be set to that of the person who originally started the program (and thus the request). This is why processes that run with elevated privileges do not appear as child processes of AIS Service Hosting.
In practice, malware could emulate the UAC query, which is irrelevant in Admin Approval Mode (AAM), since clicking on “Yes” would not increase your rights. Entering passwords is more problematic, as this can be accessed by Trojans ( keyloggers ). Microsoft therefore recommended requesting a Secure Attention Sequence from Over-the-Shoulder (OTS) or generally blocking this type of rights increase. If a program tries to write to administrative paths without requesting an increase in rights, directories and registry are virtualized. A copy of the same is described by the program, which is stored in the user profile under %userprofile%\AppData\Local\VirtualStore\and HKCU\Software\Classes\VirtualStore\so that each user receives their own copy. Above all, this should enable older applications to run undisturbed. This is not possible with 64-bit applications, nor if a UAC query was answered negatively.
Some applications run with elevated privileges in the same desktop as lower-tier applications. If a user executes a process with elevated rights (via OTS or AAM), this process runs in a different account. This means that the lower-level processes cannot write any code to the higher-level process. However, the lower-lying applications could send the higher-level fake input in order to compromise them. The sandboxing through the integrity levels is intended to prevent this by restricting the rights of deeper processes to higher ones. This is known as User Interface Privilege Isolation (UIPI). Processes can only open processes with the same or lower binding level for writing. In order to prevent access to secrets in the main memory, processes with a lower IL do not have read access to processes with a higher binding level. This means that lower processes cannot execute window handle validation on a higher process. The commands SendMessage or PostMessage to higher processes receive success messages from the API, while the commands are silently discarded. Thread hooks and journal hooks against processes with a higher binding level are not possible, as is DLL injection .
UAC query
The UAC query can be adjusted to personal preferences via Start> Control Panel> User Accounts and Protection of Minors> User Accounts> Change User Account Control Settings . The options there are limited to a slider, where between the lowest level (Win7: UAC switched off; from Win8: UAC increased without prompt), two middle levels (UAC on, with whitelist for Windows programs) and the highest level (UAC on , without a whitelist for Windows programs). The top two levels activate the secure desktop; the second highest level is selected by default.
Full access to the setting options of the user account control is only available in the local security guidelines (secpol.msc) under Start> secpol.msc> Local guidelines> Security options . Buyers of an inexpensive Windows version such as Home Basic and Home Premium do not have a graphical user interface such as gpedit.msc and secpol.msc and must therefore make the settings in the registration database (regedit.exe) under HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Policies \ System . The setting options are therefore also given below with registration values in brackets. The default settings in Windows NT 6.1 and higher are printed in bold.
It is interesting that the administrator approval mode also has the option of entering the login password, which is typical for Unix, to increase rights, as is the case with sudo . You can choose between the normal (ConsentPromptBehaviorAdmin = 3) and the secure desktop (ConsentPromptBehaviorAdmin = 1). Also of interest is the ValidateAdminCodeSignatures option , where only programs that have been digitally signed and verified can obtain admin rights. With Windows 8 and later this is no longer necessary, as the function works in the SmartScreen filter, which only allows programs to be started that meet these requirements and / or have a reputation. All accessibility features (UIAccess) must have a PKI signature from Vista onwards , otherwise they will not be accepted. The "secure directories" (EnableSecureUIAPaths) can only be written by administrators. The increase in rights for standard users originally did not have a secure desktop (is not listed in older literature), the number jump from 1 to 3 may make this clear.
For paranoid people there is still the option to request the Secure Attention Sequence (SAS) to increase rights. To do this, under Start> gpedit.msc> Administrative Templates> Windows Components> User Interface for Credentials, the option “Trustworthy path required for credential entry” must be activated. The increase in rights hampers the workflow massively, but is intended to prevent passwords from being accessed. If an application is started that requests admin rights, a “Windows Security” dialog box appears, in which the process can be continued or canceled. If you select continue, you will be asked to execute the Secure Attention Sequence (SAS). Only then is the UAC query available for increasing rights.
| Directive | Security setting | Explanation |
|---|---|---|
| Administrator approval mode for the built-in administrator account (FilterAdministratorToken) | Deactivated (0) | UAC for the integrated administrator account |
| Activated (1) | ||
| Run all administrators in Admin Approval Mode (EnableLUA) | Activated (1) | UAC for the group of administrators |
| Deactivated (0) | ||
| Detect application installations and request elevated rights (EnableInstallerDetection) | Activated (1) | Installation detection heuristic |
| Deactivated (0) | ||
| When prompted by the user, switch to the secure desktop for elevated rights (PromptOnSecureDesktop) | Activated (1) | Switch to secure desktop |
| Deactivated (0) | ||
| Virtualize file and registry write errors in single user locations (EnableVirtualization) | Activated (1) | File and registry virtualization |
| Deactivated (0) | ||
| Elevated rights only for UIAccess applications installed in secure locations (EnableSecureUIAPaths) | Activated (1) | Accessibility features must be installed under% programfiles% or% systemroot% \ System32 |
| Deactivated (0) | ||
| Promote only executables that are signed and verified (ValidateAdminCodeSignatures) | Deactivated (0) | PKI signature verification for all applications that request elevated rights |
| Activated (1) | ||
| UIAccess applications can request elevated rights without a secure desktop (EnableUIADesktopToggle) | Deactivated (0) | Accessibility programs can turn off the Secure Desktop |
| Activated (1) | ||
Elevated Command Prompt Behavior for Administrators in Admin Approval Mode (ConsentPromptBehaviorAdmin) |
Elevated rights without prompt (0) | Everything is upgraded without asking |
| Credential prompt on secure desktop (1) | Login password on the secure desktop | |
| Prompt for consent on secure desktop (2) | Yes / No query on the secure desktop | |
| Credential prompt (3) | Login password to increase rights | |
| Prompt for consent (4) | Yes / No query to increase rights | |
| Prompt for consent for non-Windows binaries (5) | Yes / no query with UAC whitelist | |
| Elevated User Prompt Behavior for Standard Users (ConsentPromptBehaviorUser) | Auto-reject requests for elevated rights (0) | Red UAC prompt blocks elevation of rights |
| Credential prompt (1) | Administrative password to increase rights | |
| Credential prompt on secure desktop (3) | Ditto on the secure desktop |
Weak points
During the beta test of Windows 7 , Leo Davidson discovered that around 70 Windows programs were run with full administrator rights without being asked, and demonstrated the possible extension of rights .
Stefan Kanthak published a proof of concept for the expansion of rights using the installation recognition.
Stefan Kanthak showed another proof of concept, which allows the execution of arbitrary code as well as the extension of rights by means of the automatic rights increase and DLL hijacking discovered by Leo Davidson .
“Vozzie” showed another proof of concept that allows rights to be expanded by smuggling in a self-created manifest using the automatic rights increase discovered by Leo Davidson.
Integration in the operating system
development
“During the day I work as a Security Program Manager at Microsoft. I also write quite a lot for TechNet magazine on security. So it goes without saying that I take security very seriously. However, I have other interests as well. In my spare time I like to play Windows-based games. [...] There is a catch, however. Like my friends Jesper Johansson and Aaron Margosis, I refuse to play games with administrator rights unless absolutely necessary. This is partly because I want to make sure that when I play a network game, the "0wn3d" message is only displayed because of my lack of skill and not because someone bombarded me with a rootkit [...]. I take this point of view so consistently that I often can't play great new games. If I can't get a game to run under my standard user account on a client belonging to the SBS (Small Business Server) domain after installing and updating it under an administrator account, I immediately remove it. There is no excuse for such technical flaws, and I have enough games to choose from. I admit that this attitude may sound extreme, but I'm adamant on this point. "
The problem with Windows systems in the past has always been that although they allowed a separation of user and admin accounts for companies and child protection, most computers (75%) are single-user computers. Since every machine needs an administrator and most users also want to have full control over the system in order to make changes, there were practically only administrators as users. This also had an impact on the software, which could always assume that the user had admin rights and could make changes that were applicable throughout the system. Software written for this environment will not work if the user is just a standard user, which was only relevant for companies and parental controls back then. However, software that is granted administrator rights can damage the system, either on purpose (malware) or unintentionally (poorly programmed software). Companies partially circumvented the problem by adding these users to the power user group, who actually no longer exist under Vista.
The user account control should achieve two goals: eliminate the incompatibility of the software and make changes to the system clear to the user. For this reason, the Protected Admin (PA) was introduced, which is the first account on the system by default. The problem of unnoticed changes was solved by generating two access tokens - one as a standard user, one as an administrator. With third-party software, however, the path from administrator to user was a rocky one, since most applications were not designed for standard users when Vista was released (Wes Miller on Microsoft TechNet , May 2008: "My challenge to you: Feel the pain"). By telemetry data of customers Microsoft was able to follow the development of third-party software in the face of UAC good.
The number of applications that ran with admin rights could be drastically reduced. This has been well received by Microsoft as it has reduced the vulnerability of the operating system . In August (2007) after the release of Vista, the telemetry customers had a UAC query in 50% of their sessions (period from logging in to logging out, max. 24 hours). During this period, 775,312 different programs requested admin rights, including the installations. Here it was shown that most software still required admin rights. Three months later, the number dropped to 350,000 a month. A year later, in August 2008, there were only 168,149 UAC prompts per month. The fact that reinstalling and setting up the machine required more UAC queries was also recognized. The data from the Customer Experience Improvement Program also showed that from May 2007 to July 2008, the number of sessions with one or more UAC queries fell from 50% to around 33% (Vista SP1).
From Microsoft's point of view, this presented the next problem: Since Windows can intervene in the operating system itself, Windows now generated around 40% of all UAC prompts. As the application programmers did their job, the ratio of UAC queries shifted. Windows Components generated 17 of the top 50 UAC queries in Vista, and 29 of the top 50 in Vista SP1. With Vista SP1, minor improvements were introduced to further reduce UAC queries. The new Windows 7 operating system was seen as an opportunity to make more in-depth changes to further reduce the number of UAC queries from the system. It was z. B. also found out that users annoyed switched off the UAC, or simply waved through the queries. It was also found in a test environment that only 13% of the participants could say why the UAC dialog appeared. For telemetry users it was also observed that 89% of the prompts in Vista and 91% of the queries in Vista SP1 were answered positively. It was feared that users would click off the UAC dialog out of habit and would not make a conscious decision in the event of critical queries. A more informative UAC dialog and a reduction in UAC queries from Windows itself were aimed for so that users can better pay attention to critical UAC prompts.
The UAC whitelist was therefore introduced with Windows 7. The programs that are on this arm-long list are automatically given admin rights without a UAC query. To put it simply, these are almost all of the EXE files below %HOMEDRIVE%\Windows\System32. Notable exceptions are mmc.exe and especially rundll32.exe , as otherwise virus.dll could be started with admin rights. The program %HOMEDRIVE%\Windows\ehome\Mcx2Prov.exeis also on the whitelist. All programs that were on the whitelist when Windows 7 was released are listed below. With the exception of minor changes, the user account control modified in this way was adopted for all subsequent Windows versions. The whitelist can be deactivated if the UAC controller is set to the highest level.
| User Account Control whitelist |
|---|
%systemroot%\ehome\Mcx2Prov.exe %systemroot%\system32\AdapterTroubleshooter.exe %systemroot%\system32\BitLockerWizardElev.exe %systemroot%\system32\bthudtask.exe %systemroot%\system32\chkntfs.exe %systemroot%\system32\cleanmgr.exe %systemroot%\system32\cliconfg.exe %systemroot%\system32\CompMgmtLauncher.exe %systemroot%\system32\ComputerDefaults.exe %systemroot%\system32\dccw.exe %systemroot%\system32\dcomcnfg.exe %systemroot%\system32\DeviceEject.exe %systemroot%\system32\DeviceProperties.exe %systemroot%\system32\dfrgui.exe %systemroot%\system32\djoin.exe %systemroot%\system32\eudcedit.exe %systemroot%\system32\eventvwr.exe %systemroot%\system32\FXSUNATD.exe %systemroot%\system32\hdwwiz.exe %systemroot%\system32\ieUnatt.exe %systemroot%\system32\iscsicli.exe %systemroot%\system32\iscsicpl.exe %systemroot%\system32\lpksetup.exe %systemroot%\system32\MdSched.exe %systemroot%\system32\msconfig.exe %systemroot%\system32\msdt.exe %systemroot%\system32\msra.exe %systemroot%\system32\MultiDigiMon.exe %systemroot%\system32\Netplwiz.exe %systemroot%\system32\newdev.exe %systemroot%\system32\ntprint.exe %systemroot%\system32\ocsetup.exe %systemroot%\system32\odbcad32.exe %systemroot%\system32\OptionalFeatures.exe %systemroot%\system32\perfmon.exe %systemroot%\system32\printui.exe %systemroot%\system32\rdpshell.exe %systemroot%\system32\recdisc.exe %systemroot%\system32\rrinstaller.exe %systemroot%\system32\rstrui.exe %systemroot%\system32\sdbinst.exe %systemroot%\system32\sdclt.exe %systemroot%\system32\shrpubw.exe %systemroot%\system32\slui.exe %systemroot%\system32\SndVol.exe %systemroot%\system32\spinstall.exe %systemroot%\system32\SystemPropertiesAdvanced.exe %systemroot%\system32\SystemPropertiesComputerName.exe %systemroot%\system32\SystemPropertiesDataExecutionPrevention.exe %systemroot%\system32\SystemPropertiesHardware.exe %systemroot%\system32\SystemPropertiesPerformance.exe %systemroot%\system32\SystemPropertiesProtection.exe %systemroot%\system32\SystemPropertiesRemote.exe %systemroot%\system32\taskmgr.exe %systemroot%\system32\tcmsetup.exe %systemroot%\system32\TpmInit.exe %systemroot%\system32\verifier.exe %systemroot%\system32\wisptis.exe %systemroot%\system32\wusa.exe %systemroot%\system32\DriverStoreFileRepositorybth.inf_x86_neutral_65c949576945c2a9fsquirt.exe %systemroot%\system32\oobesetupsqm.exe %systemroot%\system32\sysprepsysprep.exe |
Trigger of a UAC query
As mentioned above, in a test environment with Vista in 2008 only 13% of the participants could say why the UAC dialog appeared. Under Vista the succinct comment in the UAC box read : "Your consent is required to continue the process". As of Windows 7, the phrase “Would you like to allow the following program to make changes to this computer?” Was chosen, which is more suitable for inexperienced users. The technically correct question is:
- "Would you like the following program to have administrator rights?"
Specifically, under Windows NT 6.0 and higher, there are three reasons why a UAC query requests an increase in rights: the access control, the binding levels and the privileges. The access control list of every file can be viewed if the permissions of the individual users and groups are viewed in Windows Explorer by right-clicking on a file > Properties> Security . The user SYSTEM (local system) and the group of administrators have full access practically everywhere, the user Mustermann is only allowed to read and execute in the root directory of the system C:\Windows(% systemroot%) and the installation directories C:\Programmeor C:\Programme (x86)(% programfiles%). The integrity levels and privileges are unfortunately nowhere displayed in the normal graphical user interface such as the task manager . The Process Explorer from Microsoft is practically imperative for this, since the binding level of the processes is displayed here and the privileges of the process can also be displayed under Details. The following processes require administrator rights and trigger a UAC query:
- When programs are installed, because% programfiles% can only be written with admin rights. The same goes for deleting, since deleting is just one way of writing.
- If drivers are (de) installed, because they are located
c:\windows\system32\driversunder% systemroot% and can only be written with admin rights. The SeLoadDriverPrivilege is also required. - When ActiveX elements are (de) installed, as it is
C:\Windows\Downloaded Program Filesunder% systemroot%. - When writing to administrative parts of the registry. These files (SYSTEM.DAT, SOFTWARE.DAT, SAM.DAT, SECURITY.DAT, BCD-Template.DAT and many more) are located under
C:\Windows\System32\configand therefore under% systemroot%. This is e.g. This is the case, for example, with changes to the user account control and Windows Update , as these are saved in SOFTWARE.DAT and thus under% systemroot%. - If changes are made in the control panel, as this almost always requires administrative privileges, e.g. B. SeSystemTimePrivilege (changing the system time), SeBackupPrivilege and SeRestorePrivilege (system restore etc.) and much more. In most cases, the administrative parts of the registry are also written to.
- When changes are made to the Windows Firewall , as these are stored somewhere under% systemroot%. Furthermore, privileges such as SeCreateGlobalPrivilege etc. a. needed.
- If you want to look into folders and directories that are not visible to standard users, and / or copy data between user directories.
The% programdata% directory plays a special role and is hidden by default. Here users have full access, %programdata%\Microsoftand its subdirectories can only be written by administrators. For reasons of self-protection, the Microsoft Antimalware and Windows Defender sub- folders can only be read and written by administrators, SYSTEM and TrustedInstaller. Changes to MSE or Defender therefore require admin rights.
Protected mode and AppContainer
With the advent of user account control, it was clear that malware would try to get by with standard user rights alone. This is where the binding levels come into play: All administrative paths are de facto protected from access by lower-level applications and users by access control lists and privileges. The binding levels only apply to the running processes that are protected by UIPI (No Read-up, No Write-up) through access from below. Directories that are protected with Integrity Level (IL) "high" do not exist by default. When developing Vista, Microsoft was already aware of the problem that a web browser runs in the same rights context as a company's payroll. The “low” and “untrusted” integrity levels are therefore used to sandbox applications and their directories.
With Internet Explorer 7 in Vista, the first application was created that runs with a low binding level. As mentioned above, there is %userprofile%\Appdata\LocalLowa directory on the hard drive with a low binding level that these processes can write to. HKCU\Software\AppDataLowAn equivalent directory path is available in the registry . A broker process ieuser.exe with IL “medium” is required so that data from the sandbox iexplorer.exe can get into the user profile. Meanwhile, the sandboxing has also been adopted by other software: When Chrome the broker process is running chrome.exe with Integrity Level (IL) "medium", the tabs chrome.exe "Untrusted Mandatory Level" with, d. H. without write access to the hard disk. The Adobe Reader now has a "Protected Mode", Microsoft Office 2010 "Protected View" etc.
If a file with IL “low” is moved from these sandboxes to a directory with IL “medium” using drag and drop , the “UAC query for poor people” appears in the picture on the right, as the rights would be increased from a lower to a medium binding level. This has nothing to do directly with the user account control, since the standard user himself has IL “medium”, so no admin rights are required to increase files “to his level”. The user account control under Windows Vista and 7 is relevant because switching it off (or working with the built-in administrator account, which has the same effect) destroys this sandboxing. TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN is only set for user accounts and ensures that processes cannot get a higher integrity level than was assigned to the application. If the user account control is switched off, all processes are assigned admin rights. For this reason, the IE's Protected Mode is switched off when UAC is deactivated.
Under Windows 8 , the user account control is not switched off when the UAC controller is at the lowest level. The increase in rights at the request of an application then takes place silently. This is necessary because sandboxing is enforced for the Windows apps . Since more and more Windows applications are running at a low level of liability, a way was also sought to prevent them from writing to the “low” directories of another application. That is why every Windows app (or its files and applications) is assigned an individual security identifier (S-1-15-2 -...). This encapsulation is known as an AppContainer. These AppContainer are %programfiles%\WindowsAppsstored under , the directory has a low binding level. Internet Explorer is the only application under Windows 8 that can also run as a desktop program in an AppContainer ("Extended Protected Mode"). With Windows 10 , the AppContainer should also find its way onto the desktop. In both operating systems, the user account control can only be switched off if “Run all administrators in administrator confirmation mode” is set to “Deactivated” in the local security guidelines (secpol.msc). Unsurprisingly, when a Windows app is to be started, an error message appears with the request to reactivate UAC.
Hurdle or burden?
If an attacker gets access to an account on a Unix system sudothat can carry out further authentication without restrictions, he has practically already won, as this gives him full access rights. This is no different with Windows Vista and higher. When Vista was released in 2007, Russinovich and Johansson made it clear that user account control is not intended to be annoying or as a protection against sophisticated attacks for the expansion of rights . That was the same problem that UNIX has been working on for 20 years. Furthermore, the UAC does not completely protect higher processes against manipulation by lower processes, since there is no complete sandboxing, which was also not planned. With protected administrators, malware with user rights runs in the same account as elevated processes. Since many applications write and read in the user profile, a loophole can arise here that leads to an expansion of rights. Russinovich named e.g. B. attaching malware to shell extensions in the registry in order to gain admin rights sooner or later. Furthermore, privileged processes share the same namespace with standard user processes. If malware knows when a privileged process (IL: high / system) is accessing a certain memory area, it could inject malicious code into the process through a buffer overflow . The simplest option is to trigger a UAC prompt under a melodious name in the hope that inexperienced users will click “Yes”. As Jesper M. Johansson aptly put it in Microsoft TechNet in 2007:
“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. "
“If the bad guys can't think of any other way to defeat UAC, they will surely take refuge in asking the user to do it. If there is a choice between dancing pigs and safety, we know from experience that the dancing pigs always win. "
Because of these possibilities, Microsoft's User Account Control was not seen as a security barrier either. Microsoft describes a security barrier as a barrier through which code or data can only pass if the security guidelines allow it. For example, a standard user cannot manipulate the data of another user or force him to execute certain code. If it were possible, it would be a security hole in Windows (or a third party program). This strict type of separation does not take place in the user account control as a compromise between convenience and security. This is why the integrity levels do not represent a security barrier, since by default only no write-up applies. The user account control was primarily a convenience that should make it easier to switch between user accounts to elevate rights. Your main concern is that all users only work with standard user rights in order to enforce the principle of the least-privileged user account (LUA).
In 2011, four years and a version of the UAC later (Windows 7), Microsoft also saw a use against malware. The malware writers began to adapt their software to standard user rights. For most malware this was not a problem. However, circumventing the UAC turned out to be very difficult for malware. Some of the malware therefore switched to deactivating the user account control in order to avoid nasty UAC prompts from the malware immediately after the restart. Sality viruses, Alureon rootkits, FakePAV, autostart worms, banking Trojans, etc. were named. To change the UAC settings, the malware already requires admin rights, which can be achieved through exploits, a shutdown of the UAC or a "Yes" click wrong time is possible. Microsoft responded by Microsoft Security Essentials now paying attention to whether software changes the UAC settings and using this as behavioral detection. As normal software makes fewer and fewer UAC queries, behavior detection has become easier. Since 23% of all infected computers had deactivated the user account control, the users were asked to leave it activated. It was pointed out again that UAC is not intended as virus protection, but improves the security of the operating system.
The user account control does not protect against malware per se, it only ensures a strict separation between user and administrator rights. A UAC query is made every time the limit is to be crossed from bottom to top. The "protection" consists in the fact that you can determine which program receives admin rights and which does not. All administrative settings that are made by hand on the computer can also be carried out using software; the only question is whether you want that. You should be more careful with dancing pigs, columns of numbers and Chinese characters that want administrator rights. The UAC prompt in the picture on the right comes from e.g. E.g. malware that was downloaded from the Malc0de database on December 30, 2014 for test purposes into a Windows 10 TP. The malware will run if the user either clicks Yes or has turned off User Account Control. Almost two days later, on New Year's Eve, Windows Defender recognized the column of numbers as Win32 / Sality . The SmartScreen filter was deactivated for test purposes because it would have blocked the malware in the absence of a PKI certificate.
As mentioned above, UAC is not intended to protect against sophisticated privilege escalation attacks. The Metasploit framework offers various options for bypassing the UAC, as well as the option of triggering a UAC prompt under a melodious name and brazenly asking for admin rights. The variants without UAC pop-up all work with DLL hijacking and DLL injection and use the automatic rights increase through the UAC whitelist (autoElevate) under Windows 7/8 / 8.1. Vista is immune to it. For this reason, it makes sense to set the UAC controller to the highest level or to work with separate accounts. Jesper M. Johansson made the following list of best practices in 2007 :
| Rating | attitude |
|---|---|
| Worst | Turn off user account control |
| Bad | Automatic rights increase without asking |
| Well | Working in Admin Approval Mode |
| Better | Separate accounts, increased rights through OTS |
| Preferably | Separate accounts, account switching for admin tasks |
Remarks
- ↑ All admins are also users, i. that is, they also have SeIncreaseWorkingSetPrivilege. But is not part of the privileges of the Administrators group
- ↑ This is also the reason why the UAC query does not appear with screen recorders or remote desktop applications. It takes place on a different desktop than the one where it is recorded.
- ↑ The details are not directly related to the user account control, which is why they are only dealt with superficially here. That not everything that looks like a Windows app is one, i.e. H. an AppContainer is not mentioned here either. "PC settings" e.g. B. has an app design, but is not an AppContainer. Details should be in the article Windows App .
- ↑ It makes sense to select the option “Automatically reject requests for increased rights” for “Behavior of the user request for increased rights for standard users”.
Individual evidence
- ↑ a b c d Roger A. Grimes, Jesper M. Johansson: Windows Vista Security: Securing Vista Against Malicious Attacks . Wiley, 2007, ISBN 0-470-10155-5 .
- ↑ DaniHalfin: User Account Control security policy settings (Windows 10). Retrieved May 30, 2019 (American English).
- ↑ Users in Windows 7. (PDF) com !, August 2010, accessed January 1, 2015 .
- ^ Russell Smith: Least Privilege Security for Windows 7, Vista and XP . Packt Publishing, 2010, ISBN 1-84968-004-3 .
- ↑ a b How the Integrity Mechanism Is Implemented in Windows Vista. Microsoft, accessed January 1, 2015 .
- ↑ a b c d Windows 8.1 Security Internals. Chris Jackson, November 11, 2014, accessed January 1, 2015 .
- ↑ "Integrity Level" (IL) security mechanism. WinFAQ, accessed January 1, 2015 .
- ↑ a b Windows Integrity Mechanism Design. Microsoft, accessed January 1, 2015 .
- ↑ Rights and Righteousness - The Security Architecture of Windows Vista, Part 1. c't, October 2007, accessed on January 1, 2015 .
- ↑ Windows Vista. TechNet Magazine, June 2008, accessed January 1, 2015 .
- ^ Martin Grotegut: Windows Vista . Springer, 2007, ISBN 3-540-38882-6 .
- ↑ a b c Understanding and Configuring User Account Control in Windows Vista. Microsoft TechNet, accessed January 1, 2015 .
- ↑ a b c d e f Inside Windows Vista User Account Control. Microsoft TechNet, June 2007, accessed January 1, 2015 .
- ↑ a b Windows Vista Application Development Requirements for User Account Control Compatibility. Microsoft, June 2007, accessed January 1, 2015 .
- ↑ a b PsExec, User Account Control and Security Boundaries. Microsoft TechNet, February 2007, accessed January 1, 2015 .
- ↑ User Account Control (UAC). WinFAQ, accessed January 1, 2015 .
- ↑ UAC group policy and registry key settings. Microsoft TechNet, accessed January 1, 2015 .
- ↑ Windows 7: CTRL + ALT + DEL - Require to Press to Approve UAC Elevation. Windows SevenForums, September 2013, accessed January 1, 2015 .
- ^ Leo Davidson: Windows 7 UAC whitelist: - Code-injection Issue - Anti-Competitive API - Security Theater . Retrieved August 25, 2015.
- ↑ Stefan Kanthak: Defense in depth - the Microsoft way (part 11): privilege escalation for dummies . In: Full disclosure (mailing list) . Retrieved August 17, 2015.
- ↑ Stefan Kanthak: Defense in depth - the Microsoft way (part 31): UAC is for binary planting . In: Full disclosure (mailing list) . Retrieved August 25, 2015.
- ↑ UAC Bypass Vulnerability on "Windows 7" in Windows Script Host . In: Bugtraq (mailing list) . Retrieved August 31, 2015.
- ↑ Play in a safe environment. Microsoft TechNet, February 2007, accessed January 1, 2015 .
- ↑ a b c d Engineering Windows 7. Microsoft, October 2008, accessed on January 1, 2015 (English).
- ↑ a b The desktop files. Microsoft TechNet, May 2008, accessed January 1, 2015 .
- ↑ Paul Thurrott, Rafael Rivera: Windows 7 Secrets . Wiley, 2009, ISBN 0-470-50841-8 .
- ↑ Enhanced Protected Mode on Desktop IE.Microsoft , accessed January 1, 2015 .
- ^ A b c Security Watch - The Long-Term Impact of User Account Control. Microsoft TechNet, September 2007, accessed January 1, 2015 .
- ↑ UAC plays defense against malware. Microsoft TechNet, August 2011, accessed January 1, 2015 .
- ↑ User Account Control - What Penetration Testers Should Know. Raphael Mudge, March 2014, accessed January 1, 2015 .