ethicalhack3r

Many people including developers, vendors and security professionals believe that Full Path Disclosure (FPD) is mainly a Security Misconfiguration problem rather than a Input Sanitation or Error Handling problem. I’m not saying that they are wrong, but I hope to convince them that it is more of a coding bug than a configuration bug. I want to put my argument over as to why I think FPD is a bug in source code and not in configuration.

What is Full Path Disclosure (FPD)?

According to OWASP:

“Full Path Disclosure (FPD) vulnerabilities enable the attacker to see the path to the webroot/file. e.g.: /home/omg/htdocs/file/. Certain vulnerabilities, such as using the load_file() (within a SQL Injection) query to view the page source, require the attacker to have the full path to the file they wish to view.”

https://www.owasp.org/index.php/Full_Path_Disclosure

For me this is a very vague description of what FPD really is. FPD occurs when a web application encounters an error that is displayed to the user; the error includes the full path to the file the error occurred in possibly along with other debugging information.

Why is it a problem?

It’s just the path of the file from the root directory, what’s all the fuss about?

Let’s look at a WordPress FPD:

Fatal error: Call to undefined function is_multisite() in /home/bob/public_html/wp/wp-includes/wp-db.php on line 505

From the above error a username is disclosed which can later be used in a brute force attack:

/bob/

From the above error we know the web root folder name and location, this can be useful when combined with a Local File Inclusion (LFI) if the web root is not in the default location:

/home/bob/public_html/

In reality it’s not a massive deal, we can glean some server side information, so what, it’s not as serious as SQL Injection or Cross-Site Scripting (XSS). But, when there is no SQL Injection or XSS, bob’s weak password maybe our only way in or that LFI vulnerability we found earlier is now more useful.

Security Misconfiguration or Sloppy Coding?

Many people believe that FPD is a Security Misconfiguration and I can see why they think that. By simply turning ‘display_errors’ to ‘Off’ in your php.ini file the problem goes away. The same applies most other web server technologies. (note: FPD is widely known to effect PHP more than any other technology but it does effect most if not all web server technologies)

If we do the above the FPDs are gone, right? No. They are still there, all you have done is hide them. If for example a developer turns ‘display_errors’ to on by accident, the bug returns. We can say the same about a WAF in an extreme example. Just because the WAF stops the SQL Injection from happening, it does not mean that it is not there and that one day that WAF maybe turned off. *cough* barracuda *cough*

I think it is mostly due to sloppy coding practices because of the following triggers of FPD. (taking some of OWASPs examples)

Empty array: (input sanitation)

Original: http://site.com/index.php?page=about
Crafted: http://site.com/index.php?page[]=about

Fix: Ensure the parameter is a string not an array.

Null Session Cookie: (input sanitation)

Original: Cookie: PHPSESSID=ef7f786sd78f6ds78f6;
Crafted: Cookie: PHPSESSID=;

Fix: Deal with unexpected cookie values.

Direct Object Reference: (error handling)

http://localhost/wp/wp-includes/wp-db.php

Fix: Deal with errors gracefully when a file is not located in the location is should be.

Invalid File Names: (configuration)

Original: http://www.host.com/default.aspx
Crafted: http://www.host.com/default~.aspx

Fix: Now this one, I think, the only fix is configuration. You could argue that this could be fixed by the ASP developers, but in reality, that’s not going to happen.

The bigger problem

The bigger problem for me is not the information disclosure through FPD itself but rather the reluctance of vendors and developers to fix FPD. It’s too easy for them to put the blame back onto the user, “not our problem, hide the bug with configuration”.

The biggest culprit for me is WordPress. This is from their own Security FAQ:
“Why are there path disclosures when directly loading certain files?
This is considered a server configuration problem. Never enable display_errors on a production site.”

The earliest version of WordPress I could get installed (0.71-gold) had 44 FPDs, the newest release at the time of writing (3.2.1) has 155. Most of these are due to “directly loading certain files” but not all of them. One example; http://wordpress-3.2.1/index.php?s[]=FPD

It is not only WordPress either, the YEHG have kindly been collecting logs of vulnerable applications;
http://code.google.com/p/inspathx/source/browse/#svn%2Ftrunk%2Fpaths_vuln

My job is to reduce software [security] bugs, I think this bug is underestimated and deserves more attention. All FPD bugs found in WordPress will soon be implemented into my tool WPScan.

To check your web applications for FPD vulnerabilities I recommend using the YEHG’s inspathx awesome tool which checks for all and more of the triggers outlined above.