Configuring UAC on Windows 7

Starting with Windows Vista, Microsoft has included a user account management mechanism (UAC for short) in the operating system. The majority of users perceived the UAC operation mechanism negatively, since endless additional validations in the form of screen shading and clicking the Yes button could even make the most patient one go crazy. Often, UAC did not function correctly, which led to the inability to work with a number of programs that were written for earlier versions of Windows. With the release of SP1 for Vista, UAC has been finalized, but users have already managed to disable UAC and forget what it is.

In Windows 7, UAC acquired additional settings. And I would like to tell you exactly how to make UAC a really useful tool for protecting the OS.

Windows Vulnerabilities

It so happened that most Windows users work under an administrator account with all the ensuing consequences. Since the administrator is practically unlimited in his rights, virus writers actively use this to distribute their code.
There are several of the most important targets for virus attacks:

1. File system (typically: infection of executable files)
2. Windows Services
3. Registry

And here the question arises, how to isolate the user from the system even when working under the administrator. For these purposes, and serves as UAC.

When UAC is enabled, any attempt to access system files, services or the registry will be blocked and a window will appear that will require user confirmation for further actions.

UAC setup

Windows 7 introduced the ability to configure the warning level for UAC. The UAC setup screen is as follows:

Fig. 1. Configuring UAC on Windows 7.

In total, four levels of UAC alerts are available:

1. The highest level - warnings for any attempts to modify system settings and files, as well as when installing software
2. The second level - warnings only when trying to make changes to the system configuration and user settings
3. Third level - warnings only when trying to make changes to the system configuration
4. The fourth level is the complete disabling of UAC.

But much more important, in my opinion, are additional UAC settings in security policies (Fig. 2):

Fig. 2. UAC settings in security policies.

Let's take a closer look at some of the UAC policies:

1. Behavior of the elevation prompt for administrators - allows you to set the behavior of the validation window when increasing administrator rights. For example, you can enable confirmation of rights with a password (prompt for credentials) or leave confirmation of rights only by clicking OK (prompt for consent).
2. Behavior of the elevation prompt for users - similar to the first item, but for user mode accounts.
3. Switch to the secure desktop when prompting for elevation - switch the desktop to safe mode during validation. For the user, the inclusion of this policy is reflected in the form of a shading of the desktop during the test. In reality, the role of this policy in isolating the validation procedure from other running programs in order to prevent programmatic interception of the UAC window.
4. Virtualizes file and registry write failures to per-user locations - file and registry virtualization. Allows you to work with programs in virtualization mode to eliminate damage to the file system and registry (sandbox mode).

Recommendations for configuring UAC:

Personally, I use the highest UAC security settings, including the need to enter a password for validation. This gives me complete protection for system files, registry and Windows services. Typically, the software uses system files and a read-only registry. Exceptions here can only be represented by system utilities, where confirmation of access rights to the system is justified. The use of the password is due to the fact that sometimes not only I work under my account, therefore, just clicking the Yes button is not a sufficient security condition.

Problems with old programs

As a rule, problems in the work of old programs with UAC turned on are due to incorrect interaction with the system and the complete unwillingness of developers to adhere to any security standards and to restrict user access to system resources. Typically, the problem can be solved by running the program as administrator, but this is especially dangerous in the case of network applications, as it allows full access to the system if vulnerabilities of this program are used.

As an example, we can take the old programs that store user profiles not in user mode folders, but in Program Files, as a result, correct operation is possible only from the administrator, since all created files and directories in Program Files inherit the write and modify access level only for the administrator. The easiest way to solve the problem is to add rights to modify profile data for ordinary users.

In general, you can advise against installing old programs in ProgramFiles to avoid access rights problems.

Additional protection

Although the purpose of UAC is to protect system data, you can also use UAC to protect user files. This is done by simply trimming the file permissions for the user account: it is enough to remove the rights to modify and write, leaving them only for the administrator.

File permissions can be configured in earlier versions of Windows, but working under an administrator account, any program can change the level of access without asking the user. In the case of enabled UAC, the extension of rights is possible only with the passage of validation.

Verifying UAC Protection Functionality

As already mentioned, the purpose of UAC is to protect the user from changing system files and settings. Therefore, the best way to check the security of the system here is to study the operation of viruses with UAC turned on.

I will give an example of the functioning of the virus when UAC is on.

As an example, I'll take the Win32.Injector Trojan. This trojan acts quite simply: it writes itself to the C: \ Windows \ System32 directory and registers its download in the registry. As a result, after restarting the computer, a large number of cmd.exe and services.exe are launched. The easiest way to distribute is to run from autorun on flash drives.

Let's try to launch this trojan with UAC enabled. I have this executable file nsshell.exe, which by default is also hidden.

Fig. 4. The Trojan program nsshell.exe.

To make sure that this is really a virus, check nsshell.exe using an antivirus:

Fig. 5. Antivirus shows that nsshell.exe is a trojan.

Attempting to run this executable file will trigger the UAC mechanism, since the trojan is trying to register itself in the system directories and the registry:

Fig. 6. UAC triggering when nsshell.exe is started.

As you can see, the header in the UAC window in this case turned yellow. A closer look reveals that the program also lacks a trusted publisher and certificate of authenticity. Thus, few dare to confirm the launch, especially if this happened when mounting the flash drive.

Conclusion

Thus, the use of UAC is truly justified from the perspective of operating system security. If the application program required an elevation of privileges to the level of administrator when starting, then this is somewhat annoying, especially if there is no information about the publisher and digital signature. I recommend that you familiarize yourself with the UAC mechanism in more detail and still leave it enabled.

PS: Most of the described settings and actions are true for Windows Vista.