# Path Disclosure without ability to read files

So I am a pentester, and I have discovered "feature" on a server that allows me to, essentially, blindly traverse a web server's files (without executing or reading them). The problem is that I cannot figure out a way to demonstrate this as a vulnerability. The general question is: what files, by their nature of knowing their name, represent a vulnerability (if any)?

In my specific scenario, the operating system is Windows, and I can make a request like this.

http://example.com?site=file://C:\Users\Administrator

The server will return a page which indicates that it cannot load this file, whereas if I make a request like this:

http://example.com?site=file://C:\Users\namethatwouldneverexist, it will tell me that the file cannot be found.

Essentially, the server checks if the file exists before checking if I have permissions to read it.

Here are some things I tried:

• ../../../ (etc) This just results in a valid directory, which means it will tell me it is forbidden. Not helpful.
• %appdata% This results in a different kind of error, the application does not like percent signs in the path, so it does not expand it for me.
• C:\Windows\system32\ping.exe 8.8.8.8 This will result in a "not found" error, as it does not pass parameters (or execute the file).
• file://x this will expose the pwd to me, but this is not particularly interesting in my scenario.

I was able to enumerate what network drives are mapped, but this is not particularly useful. I can also essentially port scan the server from the local network to expose private ports, but I am more interested in the filesystem for now.

Essentially, my question boils down to: does the ability to positively identify a file exists on a server constitute a vulnerability, and if so, how? Obviously, if you have an idea for turning this into RCE, then that's fine too!

• Sounds like you've investigated pretty thoroughly and this is just "file fingerprinting" not "file reading". You won't get RCE from this but I would still report it as a low risk vulnerability. One other thing to try is null byte injection. – paj28 Jan 21 '16 at 8:30
• @paj28 I forgot to mention that I tried null bytes, as well as including the parameter multiple times. No luck. :-/ – Gray Jan 21 '16 at 14:16

You could also try grabbing the SAM and SYSTEM files - the only trouble is that these will almost certainly be locked. In that case you could grab the backups from the repair folder. See this answer. You can then run an offline cracking attack against them in order to grab Windows account credentials.