Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: Internet Storm Center Internet Storm Center

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Discovering contents of folders in Windows without permissions

Published: 2020-02-18
Last Updated: 2020-02-18 06:17:32 UTC
by Jan Kopriva (Version: 1)
0 comment(s)

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.

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")
			Console.WriteLine("Access permitted");
		catch (Exception e)
		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
Alef Nula

0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

curl and SSPI
Feb 17th 2020
12 hours ago by DidierStevens (0 comments)

SOAR or not to SOAR?
Feb 16th 2020
1 day ago by Guy (0 comments)

bsdtar on Windows 10
Feb 15th 2020
2 days ago by DidierStevens (0 comments)

Keep an Eye on Command-Line Browsers
Feb 14th 2020
4 days ago by Xme (0 comments)

Auth-mageddon deferred (but not averted), Microsoft LDAP Changes now slated for Q3Q4 2020
Feb 13th 2020
4 days ago by Rob VandenBrink (0 comments)

March Patch Tuesday is Coming - the LDAP Changes will Change Your Life!
Feb 13th 2020
5 days ago by Rob VandenBrink (0 comments)

Malpsam pushes Ursnif through Italian language Word docs
Feb 12th 2020
6 days ago by Brad (0 comments)

Microsoft Patch Tuesday for February 2020
Feb 11th 2020
6 days ago by Renato (0 comments)

View All Diaries →

Latest Discussions

Wireshark - To analyze "TCP sequence numbers" or not to analyze.
created Feb 15th 2020
2 days ago by Anonymous (0 replies)

TikTok app possibly using DNS over HTTPS directly
created Feb 15th 2020
3 days ago by jauntysankey (0 replies)

Zip password recovery
created Jan 17th 2020
1 month ago by Anonymous (0 replies)

Strange Google-ish domain name lookups after update to Android 10
created Dec 21st 2019
1 month ago by jauntysankey (0 replies)

SANS IP data inconsistency
created Dec 14th 2019
2 months ago by phbits (0 replies)

View All Forums →

Latest News

Top Diaries

An infection from Rig exploit kit
Jun 17th 2019
8 months ago by Brad (0 comments)

Wide-scale Petya variant ransomware attack noted
Jun 27th 2017
2 years ago by Brad (0 comments)

Using a Raspberry Pi honeypot to contribute data to DShield/ISC
Aug 3rd 2017
2 years ago by Johannes (0 comments)

Second Google Chrome Extension Banker Malware in Two Weeks
Aug 29th 2017
2 years ago by Renato (0 comments)

Detection Lab: Visibility & Introspection for Defenders
Dec 15th 2017
2 years ago by Russ McRee (0 comments)