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:
http://technet.microsoft.com/en-us/library/bb457006.aspx
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!
