I recently noticed an interesting side effect of the way in which Windows handles local file permissions, which makes it possible for a non-privileged user to brute-force contents of a folder for which they don’t have read access (e.g. Read or List folder contents) permissions. It is possible that it is a known technique, however as I didn’t find any write-ups on it anywhere, I thought I’d share it here.

UPDATE: It turns out that John Page, aka @hyp3rlinx, actually did a write-up on the vulnerability in September 2019 - you may find it here.

The issue/vulnerability belongs to the CWE-203: Information Exposure Through Discrepancy[1] family and lies in the fact that Windows returns different messages/errors when a user attempts to access existing file or folder for which he doesn’t have read permissions and when he attempts to access a non-existent file or folder. This is true even if he attempts to access existing and non-existent files within a folder for which he doesn’t have any permissions.

The behavior is similar to a vulnerability commonly present in log in functions of web applications. In case of a vulnerable web apps, a log in function returns different responses when user tries to log in with existing username and a wrong password and when he tries to log in with a non-existent username. This vulnerability is customarily checked during penetration tests since, although a valid username by itself doesn’t help potential threat actors too much, it isn’t something we want to offer to them freely.

To demonstrate the issue present in Windows, I created two user accounts on a Windows 10 test machine. First one was an admin account named "user" (and yes, in hindsight this was not the most fortunate name for an admin account) and the second, a non-privileged account, was named "Test". I further created a folder named "Secret", containing a file "secret.txt", with explicit Full control permissions set up for SYSTEM, the Administrators group and the "user" account and no permissions for the "Test" account.

It is obvious that the "Test" account wouldn’t be able to access the folder or list its contents. However, using error messages, for example those generated by attempts to change the currently open directory (cd), the user might infer whether a file or subfolder exists.

Using the error messages, it would be a trivial matter to automate guessing of filenames using a dictionary or a brute-force attack.

Before I noticed that the cd command (and many others) might be used in this way, I wrote a very simple C# PoC app, which can provide the same information and which could easily be converted to brute-force filenames or “guess” them, based on a dictionary.

static void Main(string[] args)
{
	Console.WriteLine("Input a path to a file to see whether it is accessible, or - if inaccessible - weather it exists or not.");
	Console.WriteLine("Input 'exit' to exit.");
	string input = Console.ReadLine();
	while (input != "exit")
	{
		try
		{
			File.OpenRead(input);
			Console.WriteLine("Access permitted");
		}
		catch (Exception e)
		{
			Console.WriteLine(e.Message);
		}
		input = Console.ReadLine();
	}
}

Similar guessing of paths to the one, which we could employ here, is often used to discover contents of different paths on web servers. Unlike on web servers however, in Windows environments we usually can’t access the contents of the files and subfolders we discover through a simple HTTP GET request. So is this vulnerability actually useful in any way?

By itself not so much, at least in most cases. Although it is definitely unpleasant, without chaining it with some exploit that would actually enable an attacker to read the data in discovered files, all it can do is let a potential malicious actor infer that some file or folder exists. This may be useful for some red teaming activities, but that’s about it.

The only exception I can imagine would be in a situation when a folder would be present on a file system with misconfigured explicit permissions set for subfolders contained within it. In Windows operating systems, it is possible to grant a user permission to interact with a subfolder, even though they don’t have any permissions set for the parent folder. In real life, cases of this nature will be far and few between and most will probably be the result of a mistake by an administrator. Nevertheless, if such a folder was present on a target machine, finding and accessing it would be at least plausible for an attacker. To demonstrate this concept, I’ve created a subfolder "Not_secret" within the C:\Secret path, containing a file named "not_secret.txt".

Afterwards, I gave explicit permissions for this subfolder to our "Test" user.

As you may see from the following output of the PoC app I mentioned above, the “Test" user would be able to interact with the subfolder, if he were to find it, even though he can’t interact with the parent folder.

As far as I’ve been able to determine, the CWE-203 condition is only present when interacting with local drives and not with remote file shares. A malicious user would therefore have to have direct access to the machine on which folders he wants to brute-force are present... Moreover, discovering their contents would definitely not be quick work for him. Nevertheless, although the speed of guessing, which an attacker might achieve, would be slow, and even though the confidentiality impact would be quite limited, this behavior of Windows is certainly less than ideal.

I’ve informed Microsoft Security Response Center about the vulnerability, however as they have determined that it does not meet the bar for security servicing it will not be patched. Although this may be viewed as less than optimal result, one positive point does come out of it – in future, if we ever need to determine what a folder, which we can’t access, actually contains, we have at least this (very inefficient) technique available to us to find out.

-----------
Jan Kopriva
@jk0pr
Alef Nula