Twitter
File System Events Leak Folder Contents
Using the .NET framework's FileSystemWatcher class, it's possible to monitor a folder and it's sub-folders for file creations, modifications, and deletions. The Windows API fails to take NTFS permissions into account when raising these events. By logging these events, it is possible to obtain a partial list of files inside a private folder. This also extends to folders shared over the network.
Here's a quick review of NTFS permission settings, in case you are not already familiar with them.
On a Local Machine
Locally, this attack can be used by a limited user to monitor the actions of another user on the system, even if the second user's "home" folder (C:\Documents and Settings\<username>) is protected with NTFS permission settings. The limited user simply has to set up a program to log filesystem events, then use Windows' "switch user" facility to allow the second user to login. Whenever the second user creates, modifies, or deletes a file, the first user will receive the full path to the changed file in a filesystem event. This information can potentially be used to reconstruct the second user's actions by looking at what files were created/changed in folders that store temporary files or cookies. This is a serious privacy problem for systems shared between multiple users.
Demo
To demonstrate this, I created two accounts on a Windows XP system. The "firexware" account has administrator privileges and the "limited1" account is a limited user...
Firexware wants to make sure that nobody else on the system can learn anything about his files, so he makes sure his account's folder is private:
Limited1 logs on and notices he doesn't have access to firexware's files:
Limited1 wants to see what firexware is up to, so he starts a filesystem event monitoring program:
Firexware logs on and creates some files:
When firexware is done, limited1 logs back on and checks his filesystem event monitoring program. He gets a nice list of all the files firexware created:
On Shared Folders
The same attack extends to shared folders. If a client can map a network drive that is the parent folder to a private folder, their machine will receive the filesystem events for files inside the private folder, even though it doesn't have permission to access the contents.
To test this, I setup a Windows Server 2008 system and set it up to share the folder C:\ShareTest. I created a second non-administrator user on the Server 2008 box and setup C:\ShareTest so that it could be accessed from another PC. From a Windows 7 PC, I mapped drive O: to that shared folder. On the server, I created the folder C:\ShareTest\Private and set the permissions so that the second user was explicitly denied all access. I ran the filesystem event monitoring utility from the Windows 7 PC while I created some files in C:\ShareTest\Private on the server. The Windows 7 PC received the events and was able to see what files were being created and modified inside that folder.
If the connecting client can run a packet capture tool like Wireshark, they can get a bit more information about the file by looking at the SMB packets being sent from the server. Example: SMB file modification event packet. If there are two users on a system who can run packet capturing software, one will be able to see everything the other is doing on their network drives.
Affected Systems and Mitigation
Windows
The local version of the attack has been tested and verified to work in Windows XP, and Windows 7, all with the latest service pack and updates applied. I assume it would work on Windows Vista as well. All of the tests were done with a limited user account (called "standard user" in Windows 7), with default settings. It also works with the Guest account.
I can't find a way to block this attack using NTFS permissions alone. I even tried explicitly denying the limited account access, and the attack still worked.
The shared folder version of the attack has been tested and verified to work when the shared folder is being hosted by: Windows XP, Windows 7, and Server 2008. I assume it would work the same with Server 2003 and Vista. The only way I have been able to prevent this attack is by making sure users can't even map a share that contains any of the folders you want to keep private.
Doing something like the following does NOT help, even when it is applied recursivly to all subfolders and files.
There IS a fix!
After Microsoft finished investigating the issue, I recieved the following email reply:
Thank you again for reporting this issue to Microsoft. We have successfully reproduced this issue but believe this issue is by-design. We actually have a blog discussing this behavior at http://blogs.technet.com/b/markrussinovich/archive/2005/10/19/the-bypass-traverse-checking-or-is-it-the-change-notify-privilege.aspx. This functionality is controlled by the SeChangeNotifyPrivilege. By default this privilege is allowed for performance reasons but you can disable this in the Local Security Policy Editor (LSPE). In LSPE, it is listed under "Bypass traverse checking". See the blog for details.
The only security issue here is that Windows is not in a secure-by-default configuration. Due to this fact, I have pushed this to be fixed in the next version of Windows. As we will not be issuing a security update, I will not be able to track this issue and confirm or deny if the product team changes the default configuration of the SeChangeNotifyPrivilege. As a group, the MSRC pushes hard on development teams to make the next version of software more secure. Your report will continue to help us in this endeavor.
Samba on Linux
I also tested this with samba shares on Debian Squeeze. Samba does send the filesystem events to the client for folders the user is allowed to access. If you use unix permissions to deny the account access to the folder you want private, they will not receive the events. That's probably just because the samba process for that connection can't access the folder itself, so it couldn't even figure out when anything is being changed. I don't know if samba provides it's own per-directory permission settings, so if it does, I haven't tested it with this attack.
Demo Utility Source Code
I have made available the source code and compiled binary for the utility I created to do my testing. You will need the .NET Framework 3.5 to run the program. It is licensed under the GNU GPL v3 so feel free to modify it and redistribute it.
.exe (Requires .NET 3.5)
Source Code (VS2008)
Impact
At first glance, this attack doesn't appear to be a very big security problem because the attacker only gets filenames, not their contents. I argue that it is a problem, because many admins are TRUSTING and RELYING on NTFS permissions to keep the names of their files secret. This attack leads to serious privacy problems in multi-user and shared-workstation setups. It's also very likely that clever hackers could use other attacks along with this one to aid them in breaking into a Windows system or network.
