Find potential security glitches before they find you
The proliferation of malware threats and the popularity of shared-user Windows Terminal Services systems makes correctly implementing Windows security more important than ever. But the Windows security model, with its flexible discretionary ACLs (DACLs), can be difficult to manage. Windows includes no built-in tools for quickly determining which files, directories, and registry subkeys particular users can access, nor is there an easy way to find out whether users have unauthorized accesses to sensitive directories or registry subkeys buried deep in a system. That's where Sysinternals' AccessEnum comes in. This free tool scans a specified volume, subdirectory, or registry key to help you find potential trouble spots in your security settings.
Download AccessEnum (http://www.sysinternals.com/utilities/accessenum.html) to a Windows Server 2003, Windows XP, or Windows 2000 system, then execute the program. Figure 1 shows the tool's main window. In the text box at the top of the window, enter the root path of the directory tree or registry subkey that you want to examine, then click Scan. AccessEnum examines the security descriptors of each object under the specified root, then displays only those objects that have security that differs from their parent containers'. AccessEnum abstracts permissions into one of three categories—Read, Write, and Deny—which it shows as columns. If a user or group is granted any type of Read access (e.g., Read Permissions, Read Data) to a file, AccessEnum shows the user as having Read access. The tool handles Write and Deny accesses similarly. (The tool groups permissions in this way to prevent its output from becoming overwhelming.) Thus, if a user has any of the possible Read accesses to a particular directory but not to the parent directory, AccessEnum lists the directory name in the Path column and the user account in the entry's Read column. For example, suppose a user has Write access to the \Windows\System32 directory and all subdirectories but not to the \Windows directory. AccessEnum will return an entry for \Windows\System32, listing the user account in the Write column.
Another way in which the tool optimizes output is to condense displayed accounts into group memberships. When a group has Read access to a directory but not to the directory's parent directory, and the same is true for one or more group members, AccessEnum will list only the group in the Read column rather than listing the group and each group member.
AccessEnum's Options menu offers two settings that you can use to modify the way the tool operates. The first option, Show Local System Account, is enabled by default. When you disable this option by toggling the menu entry, AccessEnum ignores permissions that reference the Local System account. Only Windows services and core OS components use the Local System account, so if you're simply trying to determine permissions discrepancies of users and groups on your system or network, you can safely disable this setting. However, the Local System account must be able to access numerous system directories and registry keys if Windows is to boot and operate properly. Therefore, leaving this option enabled (so that AccessEnum can check for permissions problems involving the Local System account) can help you prevent or correct problems that can arise after you've been too aggressive locking down security.
The second option, File Permissions Options, affects the way AccessEnum handles file permissions. By default, the tool lists files that have less-restrictive permissions than their parent directories do. The File Permissions Options, which you can access by selecting Options, File display options from the menu bar, lets you configure AccessEnum to treat files as it does directories, displaying a file when its permissions differ from those of its parent directory in any way.
Spotting and Resolving Problems
Using AccessEnum to find potential security misconfigurations is relatively easy. You can quickly hunt down directories and registry subkeys that have security that might be too lax: Click on the column headers to sort the access columns, then look for entries that list the Everyone group or non-administrator user accounts. For example, the highlighted entry in Figure 1 shows that the Test account has Write access to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Policies registry subkey (and everything underneath).
When you find a potential problem, right-click the entry to display AccessEnum's context menu. If the entry represents a file or directory, the context menu gives you direct access to the item's Windows Explorer Properties dialog box; go to the Permissions tab to examine the item's security settings. For registry subkeys, select Explore from the context menu to open regedit, then navigate to the selected subkey. Then, you can open regedit's Permissions editor, which Figure 2 shows, by right-clicking the subkey, or you can choose Edit, Permissions from the regedit menu bar. As Figure 2 shows, the Test account in our example has Full Control and Read permissions—opening a security hole because the specified registry subkey controls important system-wide settings.
When you're updating security over time (by using Group Policy settings, for example) or have computers on the network that need to be configured similarly, you can use AccessEnum's comparison feature to find changes and differences. Simply save the output of a scan. You then can compare the results of future scans to a saved scan by choosing File, Compare to Saved. Figure 3 shows a comparison that points out the differences between a scan I performed before giving the Test account full access to the Policies subkey and a scan I performed after doing so.
AccessEnum is a simple yet powerful tool for auditing security settings on systems throughout your network. Taking a few minutes to run scans and look for potential security misconfigurations can save you the pain and hassle of dealing with a security breach.