6

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!

Gray
  • 728
  • 4
  • 15
  • 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 08: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

2 Answers2

4

What you describe can be called an information disclosure vulnerability. You could use this technique as a method of fingerprinting (looking for specific operating system files, common web framework folders and files, etc.) and could prove useful in identifying a version of something on the system that is susceptible to a separate vulnerability. As you've indicated it's a web server, it could aid in exploring web application vulnerabilities such as arbitrary file upload (if the functionality exists) or otherwise.

Jason Higgins
  • 647
  • 4
  • 8
  • Thanks. I think you are right that this type of vulnerability can best be described as information disclosure. I was hoping that there was something like a password hash stored as a filename somewhere, but that isn't very realistic. Getting version information was probably the most useful finding. – Gray Jan 21 '16 at 18:10
1

You could grab important files as suggested. For example, web.config files or other application configuration files may contain sensitive information such as passwords.

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.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • That's useful to know about the repair folder, but unfortunately, I am unable to actually read any files. web.config was one of the first I tried to get, haha. I can just tell if a file exists or not, not its contents. – Gray Jan 21 '16 at 14:15