Practice
Full Path Disclosure (FPD) is the disclosure of the full working path of a vulnerable script. An FPD error is triggered by injecting unexpected characters into certain web page parameters. The script does not expect the inserted character and returns an error message that includes information about the error, as well as the working path of the target script.
FPD vulnerabilities are generally regarded as low-risk threats that webmasters often overlook, believing there is nothing to worry about or that it is simply a quirk of the scripting language. While the latter is true, only the webmaster should see the output of error messages and log them appropriately; an attacker should never see the error message output on a web page.
Low to medium (indirect).
Extremely high.
Although FPD vulnerabilities are generally perceived as low risk, they can often be used in combination with other exploitation techniques and can mean the difference between a successful breach and a failed one.
One example of such a relationship would be exploiting an LFI vulnerability in conjunction with FPD. With LFI alone (whether via a normal include method or via SQL injection using load_file()), an attacker may be unable to locate the folder containing the configuration file they want to view, or perhaps the standard include folders have been renamed.
If an attacker can trigger an error that reveals the location of an important file or folder, they may be able to read the contents of the SQL configuration file and, in turn, gain full access to the database.
Although FPDs are usually used in combination with other attack techniques, sometimes they can be all an attacker needs to gain access to a database or server. An example of this would be a web application using flat files. A web application may be vulnerable to full path disclosure that reveals the location of the flat-file database; this could include administrative information such as admin panel passwords, email addresses, or user passwords.
Full Path Disclosure results from a script lacking an error-handling system. Error handling is a feature of the programming language designed to address errors that occur during the script's lifecycle. FPD can be triggered simply by supplying input that the script does not know how to handle.
Array [] parameter injection is possible when a script builds a call using the $_GET parameter. If the $_GET parameter is wrapped in a function that expects a string — for example, htmlentities() or opendir() — but receives an array instead, this will produce an error message. The error message output will look like the following:
Warning: htmlentities() expects parameter 1 to be string, array given in /var/www/foobar.php on line 16
Since the function expects this parameter to be a string, passing an array will cause the parameter call to be treated as nonexistent, outputting only the error from the function.
Invalid session injection is made possible by changing the value of the session cookie to an invalid or illegal character. There are many characters for injection that will cause the working path to be disclosed, but the most common and most widely (un)supported are null characters; doing nothing to the cookie To inject the PHPSESSID cookie, use a JavaScript injection via the URL string:
javascript : void ( document. cookie = "PHPSESSID =" ) ;
After performing the injection, the page needs to be refreshed. If the injection was successful, it will produce an error message similar to the following:
Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /var/www/foobar.php on line 3
Since the session_start() function does not expect invalid characters, it issues a warning, resulting in full path disclosure.
Web application developers sometimes fail to add security checks to files that require pre-loaded library/function files. This can lead to the disclosure of potentially sensitive information when these application URLs are requested directly. Sometimes this is the key to a local file inclusion vulnerability.
Regarding Mambo CMS, if we access the direct URL, http://site.com/mambo/mambots/editors/mostlyce/jscripts/tiny_mce/plugins/spellchecker/classes/PSpellShell.php , we get
<br /> <b> Fatal error </ b>: Class 'SpellChecker' not found in <b> /home/victim/public_html/mambo/mambots/editors/mostlyce/jscripts/tiny_mce/plugins/spellchecker/classes/PSpellShell.php </ b> on line <b> 9 </ b> <br />
This kind of check can be easily performed by developers using the inspathx tool.
Preventing FPD injection without an error-handling/management system is as simple as disabling the display of error messages. This can be done in the PHP php.ini file, in the Apache httpd.conf file, or through the PHP script itself:
php.ini:
display_errors = 'off'
httpd.conf / apache2.conf:
php_flag display_errors off
PHP script:
ini_set ( 'display_errors' , false ) ;
In the case of array [] parameter injection, the PHP function is_array() can be used to handle the injection and log the attempt to the desired file or database:
( isset ( $ var ) && is_array ( $ var ) ) ? logfunction ( ) : / * continue * / ;
In the case of invalid session injection, regular expressions can be used to filter invalid session values from the injection. Checking for characters other than a-z, A-Z, 0-9 and '-,' will prevent the disclosure attempt from reaching the desired file or database.
Although full path disclosure is a convenient reconnaissance technique that can be used in situations to achieve a successful outcome, it is highly unlikely that the vulnerability alone will lead to a successful compromise.
There are very rare cases where the vulnerability can be used as the sole technique for successfully penetrating a website. For this to happen, the webmaster's security practices must be very poor, such as using flat-file databases or bad extensions like .inc or .txt files.
In most cases, the vulnerability is used as a reconnaissance method employed to gather information about the target.
Comments