Windows Security Registry
Windows Registry Security
This article continues on from Security and the Windows Registry - part one, where we looked at the two Registry hives related to security and how to access them if required. Read on to continue with our overview of Windows Registry security-related topics.
File and Registry Virtualization
Windows XP has been a hugely popular operating system and is still loved by millions of users. However it was never designed for today’s demanding environment and it shows in its inherent inability to fully protect the users from modern security threats! With the introduction of Windows Vista in 2007, Microsoft radically overhauled the security features of its replacement for Windows XP.
One of the major areas of concern, when running applications under Windows XP, is that the application was given permission to freely read and write "system files" and "registry keys", especially keys in the Software hive (HKLM\Software). Basically a security nightmare!
Since the introduction of Windows Vista (and later with Windows 7), software developers are forced to write applications that stick to strict guidelines on where they can write and read in the operating system.
This is all well and good for new applications, but what about legacy applications… software that was not written specifically with the new security changes in mind? If they try and write to any of Registry keys in the Software hive (HKLM\Software), the application will fail to launch and either hang or possibly even crash your PC.
With this issue of backwards compatibility in mind, Microsoft introduced the concept of "Virtualization" of important locations such as system files and registry keys. This "File and Registry Virtualization" is part of the much written about UAC (user Access Control) mechanism in Windows Vista and Windows 7.
Now if a legacy application attempts to write to the restricted the Software hive (HKLM\Software). Registry virtualization will redirect the keys and data to the HKCU\Software\Classes\VirtualStore subkey.
If you are wondering where Windows Vista and Windows 7 redirect attempts to write data to protected system locations such as C:\Program Files and C:\Windir\system32 By default, the application is redirected to a special folder in located in the users profile. By default this location is:
C:\Users\User_name\AppData\Local\VirtualStore\Program Files\Application_name
It is possible to turn off this setting, called "Virtualize File and Registry Write Failures to Per-User Locations" via the Local Security Policy in the Group Policy Editor console (Gpedit.msc) available in all business editions of Windows Vista and Windows 7. However this is not advised by Microsoft. Note: There is no access to this setting via the UAC settings in the Control Panel.
AccessChk
AccessChk is a free downloadable Windows XP, Vista and 7 command line utility. It is part of Microsoft's Windows SysInternals range of utilities for troubleshooting in the Windows environment.
The accesschk.exe utility has many functions that allow you to check folder and file access, as well as access to processes, services, registry keys and OS components.
You can download it here: http://technet.microsoft.com/en-us/sysinternals/bb664922.aspx
Create a new folder called access in the main Program Files folder on your PC and then unzip the utility accesschk.exe and EULA.txt files into the new folder.
Note: On Windows Vista/Windows 7 you will need to run CMD as an Administrator.
So, open a command line window and then type in the following commands:
cd %programfiles%\accesschk
You are now free to start using the tool. If you type: accesschk.exe /? You will get all the available switches and syntax available for this utility.
For example, to see the security (read, write etc.) on a registry key, let's say HKLM\software, you would type:
accesschk -k hklm\software
If you would like the details dumped into a text file to read in notepad, type:
accesschk -k hklm\software > filedump
A files called filedump has now been created in the accesschk folder on your PC.
Preventing Local Registry Access
A common Windows Registry related security question is this: "How can I prevent access to the local Registry?"
The simple answer is that you cannot.
Every user’s profile will require access to the Registry at various stages, so you cannot block its access. However, you can try and limit user access to the Registry editor so that no direct editing of the hives/keys can take place.
But, even if you use an existing policy to restrict editing in the Registry, such as "Prevent access to registry editing tools" this only applies to Regedit.exe and not any of the many 3rd party shareware editors that can be downloaded via the Internet.
A security conscious network administrator can however try and use the Software Restriction Policies (a policy-driven mechanism for identifying software programs running on computers in a domain) available for Windows XP, Windows Vista and Windows 7 versions that support gpedit.msc. More information here:
Note: Microsoft has introduced a new "software restriction" tool, called AppLocker, which is a complete revision of software restriction policies, but is available for Windows 7 Ultimate and Enterprise editions only.
Restricting Remote Registry Access
A little known fact is that the Windows Registry allows for remote access via another PC/Server.
Now this is not open access for all, Windows does place many restrictions to maintain security on the local PC.
First of all is that you have to explicitly add a user (or group) to the ACL (Access Control List) of the following sub key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
Even this step alone is still not enough, as it only grants remote access but does not bypass the ACL on each Registry key that is to be editited. A remote user (or group) will still have to be added to a key’s ACL.
From a security standpoint, it should ONLY ever be a domain administrator that is added to the winreg sub key. Do not go and grant just user remote access!
Comments