Windows Registry Security - Part One

In previous articles, available on this website, you can read about the basics of the
Windows Registry.

In this two part article you will be taken beyond the registry fundamentals and
introduced to the more advanced topic of registry security.

Windows Registry security is not a particularly thrilling subject, but it is however
an important subject for any person with responsibility for looking after Windows
PCs as part of their job.

If you are serious about your job as an IT Specialist or System Administrator
overseeing your company's network security then you should take the task of
upgrading your Windows Registry Security seriously. However if you are an
average home user there is no immediate need to dwell on these advanced topics
about registry security. Nowadays, you can download and store these upgrades and
security software on your external hard drive straight from Microsoft's Safety and
Security Center for free.

When Microsoft released Service Pack 2 (SP2) for Windows XP, on the 25th August
2005, they dramatically improved security for the Windows client operating system.
So this two part article will focus on registry security topics for Windows XP SP2
and above. Where there are specific features that relate to Windows Vista and
Windows 7 I will make you aware of these.

So onto the first item.
HKLM\SAM
HKLM\SAM holds local and domain account information, such as user passwords,
group definitions, and domain associations. By default, this important key is
unreadable by even the system administrator account. "SAM" stands for the
Security Access Manager and is essentially a database of security information and
user permissions and passwords. It is sometimes referred to as the Windows local
security database.

For the average home user there is no need to know any more than this about the
HKLM\SAM.

However if you support Windows PCs for a living then the following information
about the HKLM\SAM, may be useful.

1) The HKLM\SAM Hive path file is:

%SystemRoot%\System32\Config\Sam (e.g. C:\System32\Config\Sam )

2) It is an "alias" or "link" to the key HKLM\Security\SAM.

3) By default, Windows XP stores its logon passwords in the HKLM\SAM using a
cryptographic hash called LM Hash, rather than in clear-text. Unfortunately this
is not good news due to the inherent security weaknesses of LM Hash, discovered
over the many years it has been in use. (There is actually a security setting in
Windows XP that can turn off using LM Hash for passwords, but for backwards
compatibility it is NOT turned on by default!)

However there is a way to stop Windows XP from storing an LM hash of your
password - use a password that is at least 15 characters long.

In Windows Vista and Windows 7, password security is much stronger as these
more modern operating systems do not use LM Hashes to store your logon
passwords. Instead they take your logon password and apply some clever
mathematics to it called a "hashing function" and this creates a 128 bit number. It is
this number that is actually stored locally on the PC in the SAM, or in Active
Directory if you are connecting to a network via a domain controller. This is far
more secure than storing your password as an LM Hash, which can be "cracked"
by an experienced security professional good or bad!
HKLM\SECURITY
The Windows kernel will want to access the HKLM\SECURITY to read and enforce
the security policy applicable to the current user at logon.

It contains a "SAM" subkey which is dynamically linked to the SAM database of
the domain onto which the current user is logged on (a local system domain or the
network domain controller via Active Directory.)

As with HKLM\SAM it will look empty, even to system administrators, unless
ownership is granted via the keys ACL (Access Control List), not something I
recommend you playing around with!

Viewing The HKLM\SECURITY and HKLM\SAM Hives

By default the Registry editor will not allow you to navigate your way through the
HKLM\SAM and HKLM\SECURITY hives, they will appear empty if you try.
These important Registry hives are protected by the System Account and a
currently logged on user, or even a member of Administrators Group, do not have
permissions to view them.

BUT what if you need too? For instance, if you are a network administrator there
are valid times when you may need to check a particular key exists.

The way I recommend is to use a 3rd party utility, from Mark Russinovich and
Windows SysInternals, to force the Registry to open under the System Account.

This way you do not have to make any changes to the ACL (Access Control List)
yourself, so limiting the potential for any mistakes. And as the utility only works per
session that you initiate there are no permanent access changes made to the
Registry.

First you will need to download the PSTools utility pack from Windows
SysInternals available here:

http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx

The actual utility you will be using is:

Psexec.exe http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Step 1) Unzip the downloaded files and place into a new folder called "PSTools" in
the existing "Program Files" folder.

Step 2) In Windows XP go to Run on the Start menu and type in cmd then hit the
OK button. The Command line window will now open.
In Windows Vista/Windows 7 you will have to launch the Command line with
administrator privileges. Go to the Start menu and type in cmd When the cmd icon
appears in the search list "right-click" and select Run as administrator from the
context menu.

Step 3) In the command prompt window (see Fig 1.0) you will need to change the
directory to the folder where you placed the utilities PSTools. Type the following:

cd %programfiles%\PSTools

now hit the enter key.

Now you will need to type the following to have the utility Psexec.exe open the
Registry editor under the local system account:

psexec.exe s i regedit.exe

now hit the enter key.

The Registry editor will now open and you can now navigate your way through the
HKLM\SAM and HKLM\SECURITY hives see Fig 1.1 When you have finished
just close the Registry editor window and the temporary elevation to system account
authority will cease.

The Command Prompt Window

The Registry Editor Displaying the HKLM\SAM and HKLM\SECURITY hives




Windows Registry Security - Part Two
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 todays 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 users 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\SecurePipeServ
ers\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 keys 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!