Windows Confidential: Hiding in Plain Sight
How do you prevent Windows Explorer from showing files to which a user shouldn’t have access? Try these tips to keep someone from your hidden files.
When you ask Windows Explorer to show you the contents of a file system directory, it will show you the contents of the directory as directed by the file system. If the file system has Hidden items, then by default, Windows Explorer will suppress the item from display.
You can configure the items Windows Explorer suppresses from the list from the Folder Options control panel. You can even choose to show Hidden items and “protected operating system files” (known internally as “Super-Hidden,” as if they had a giant H printed on their shirts). One thing Windows Explorer doesn’t have, though, is a setting to suppress the items to which the user doesn’t have access.
Windows Explorer relies on the file system to do the heavy lifting. If the directory contains an inaccessible subfolder, the file system enumeration function doesn’t care. You asked for the contents of the directory, and that’s what you get.
You can confirm this by dropping to a command prompt and doing a dir: command. The result is the contents of the directory, whether you have access to all those contents or not. The file system enumeration functions care only about the FILE_LIST_DIRECTORY permission, known within the UI as “list folder permission.” If you grant a user permission to list the contents of a directory, then the user can see the contents of the directory.
Why doesn’t Windows Explorer have an option to filter out items to which the user doesn’t have access? For one thing, that option would make directory enumeration slower. For every item that comes back from FindNextFile, Windows Explorer would have to perform a security check on the file to see whether the user has access permission. If you’re enumerating a file on a remote computer (which is a common scenario), that means one or possibly two roundtrip network calls per item.
A directory with 1,000 files, which used to take only 12 network requests, will now take 1,012. When you’re talking to a network server halfway around the world with a 500ms ping time, your directory listing that used to take six seconds now takes more than three minutes.
Another major problem is that attempting to access each file to determine user access permission can result in a lot of failed accesses. This in turn means a lot of audit entries in the security logs. These audit entries are a source of concern to companies that study them in the security logs (and the people who ask for this feature often study their security logs).
They generate a lot of noise, which makes it more difficult to identify real security threats within an organization. With this feature enabled, every user ends up looking like a hacker methodically testing every file in the system looking for one with weak access control lists.
Early attempts to bring the Windows XP-style logon to domains ran into a similar problem with IT administrators. Windows XP automatically logged the user on if his password was blank. To do this, it tried to log the user on with a blank password. If it failed, then it displayed the password prompt.
This algorithm resulted in security logs filling up with “invalid password” logon attempts. This drew concern from IT administrators not only for making it harder to find genuine attempts to infiltrate their systems, but also for making it much more likely users would accidentally lock themselves out of their accounts following too many failed logon attempts.
When people asked the Windows Explorer team about adding this feature, the Windows Explorer folks explained all these problems. They also pointed out a solution—you just have to ask a less-specific question. Instead of asking Windows Explorer to do the filtering, do the filtering in the file system.
The traditional workaround for hiding items from users who don’t have access permission is to put them in a subdirectory where the users don’t have folder permissions. Windows Server 2003 SP 1 introduced a feature known as Access-based Enumeration (often abbreviated ABE). If you configure a share with Access-based Enumeration, the server will filter out files and directories to which users don’t have access.
Given this feature is implemented in the file system redirector, the setting applies only to shares. Access via local paths continues to behave as before. Because you’re asking the server to do more work, directory enumeration will be slightly slower. Each item must be checked before it’s returned to the client. For more details, consult the Access-based Enumeration white paper.