Hello Today I will discuss on FPD web application attack.
------------------------------------------------------------------------------
What is Full Path Disclosure?
------------------------------------------------------------------------------
To put it simply, Full Path Disclosure (FPD) is the revelation of the full path of a given file. FPD is performed by causing an error within a targeted website, which in turn, spits out an error message for an attacker to see. FPD vulnerabilities are generally looked upon as low risk and are too often overlooked by web-masters as nothing to worry about, I will take care of it later. This can sometimes be a fatal mistake.
------------------------------------------------------------------------------
When and why are path disclosure vulnerabilities useful?
------------------------------------------------------------------------------
While FPD vulnerabilities are low risk, they can be used in conjunction with other exploiting techniques and can often be the key to a successful hack.
One example of such a relationship would be the use of an LFI (Local File Include) vulnerability partnered with FPD. With LFI, the attacker may not be able to find the containing folder for a certain file they wish to view (for example: config.php) or maybe the standard includes folder has been renamed. If an attacker can cause an error that will spit out the location of the folder, it would make the hack much faster, smoother and easier then trying to guess the path. The attacker might even get lucky and find that the web-master uses txt files to store database information rather then SQL (do not laugh, it happens).
------------------------------------------------------------------------------
How do I find a path disclosure vulnerability?
------------------------------------------------------------------------------
There are a number of ways to test for FPD vulnerabilities, each take little time to achieve.
The first method is to find a page that calls from an array, for example: index.php?page=home. To check this for a vulnerability, one would add an inoperable value to the URL. There are a number of ways to do this. The most effective of which would be to add open and closed square brackets [] to the end of the page value, this makes the call for the page defunct. The URL for this example would be index.php?page[]=home. This method would call such errors as:
Warning: opendir(Array): failed to open dir: No such file or directory in /home/www/example/kei/photo/index.php on line 297
Warning: pg_num_rows(): supplied argument is not a valid PostgreSQL result resource in /usr/home/example/html/pie/index.php on line 131
Another method that can cause an FPD is to add an inoperable value to a cookie. The easiest and most common of which is to null the session cookie. In order to do this, one must use Javascript injection to inject the invalid value. To do this, add the following line into the URL bar in a web browser: javascript:void(document.cookie='PHPSESSID='); (If you do not know how or why this works, refer to the Javascript injection article). This can cause the following error:
Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /home/example/public_html/includes/functions.php on line 2
Array[] Parameter Injection is made possible when a script is devising a call via the $_GET parameter. If the $_GET parameter is wrapped in a function that expects a string—for instance, htmlentities() or opendir()—but receives an array, it will result in an error message. The output of the error message will look similar to the following:
Warning: htmlentities() expects parameter 1 to be string, array given in /var/www/foobar.php on line 16
As the function is expecting that parameter to be a string, the result of the given array will render the parameter call defunct, outputting only the error from the function.
------------------------------------------------------------------------------
How do I prevent such vulnerabilities?
------------------------------------------------------------------------------
The simplest way to prevent these vulnerabilities is to simply turn off error reporting within your server. This will immediately turn off any errors that may be caused. The problem with this method however is that if you do have a problem with one of your scripts, it can be hard to determine where and what the problem is without the aid of the error message.
Regular expressions are also useful in disabling the errors, especially in the case of the cookie injection. With the array vulnerabilities, the is_array() function can be used to patch the vulnerability. The good thing about these last two methods is that you can also use them to echo fake errors to confuse your attacker.
------------------------------------------------------------------------------
Conclusion
------------------------------------------------------------------------------
In conclusion, I would like to once again stress that these vulnerabilities are useful only in certain circumstances and wont allow you to penetrate a server/site with this technique alone. You will have to rely on other techniques in conjunction with this vulnerability or other insecure practices (bad file extensions etc).
I hope you enjoyed the article and learned something from it.
Thank you (zer0w0rm)
------------------------------------------------------------------------------
What is Full Path Disclosure?
------------------------------------------------------------------------------
To put it simply, Full Path Disclosure (FPD) is the revelation of the full path of a given file. FPD is performed by causing an error within a targeted website, which in turn, spits out an error message for an attacker to see. FPD vulnerabilities are generally looked upon as low risk and are too often overlooked by web-masters as nothing to worry about, I will take care of it later. This can sometimes be a fatal mistake.
------------------------------------------------------------------------------
When and why are path disclosure vulnerabilities useful?
------------------------------------------------------------------------------
While FPD vulnerabilities are low risk, they can be used in conjunction with other exploiting techniques and can often be the key to a successful hack.
One example of such a relationship would be the use of an LFI (Local File Include) vulnerability partnered with FPD. With LFI, the attacker may not be able to find the containing folder for a certain file they wish to view (for example: config.php) or maybe the standard includes folder has been renamed. If an attacker can cause an error that will spit out the location of the folder, it would make the hack much faster, smoother and easier then trying to guess the path. The attacker might even get lucky and find that the web-master uses txt files to store database information rather then SQL (do not laugh, it happens).
------------------------------------------------------------------------------
How do I find a path disclosure vulnerability?
------------------------------------------------------------------------------
There are a number of ways to test for FPD vulnerabilities, each take little time to achieve.
The first method is to find a page that calls from an array, for example: index.php?page=home. To check this for a vulnerability, one would add an inoperable value to the URL. There are a number of ways to do this. The most effective of which would be to add open and closed square brackets [] to the end of the page value, this makes the call for the page defunct. The URL for this example would be index.php?page[]=home. This method would call such errors as:
Warning: opendir(Array): failed to open dir: No such file or directory in /home/www/example/kei/photo/index.php on line 297
Warning: pg_num_rows(): supplied argument is not a valid PostgreSQL result resource in /usr/home/example/html/pie/index.php on line 131
Another method that can cause an FPD is to add an inoperable value to a cookie. The easiest and most common of which is to null the session cookie. In order to do this, one must use Javascript injection to inject the invalid value. To do this, add the following line into the URL bar in a web browser: javascript:void(document.cookie='PHPSESSID='); (If you do not know how or why this works, refer to the Javascript injection article). This can cause the following error:
Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /home/example/public_html/includes/functions.php on line 2
Array[] Parameter Injection is made possible when a script is devising a call via the $_GET parameter. If the $_GET parameter is wrapped in a function that expects a string—for instance, htmlentities() or opendir()—but receives an array, it will result in an error message. The output of the error message will look similar to the following:
Warning: htmlentities() expects parameter 1 to be string, array given in /var/www/foobar.php on line 16
As the function is expecting that parameter to be a string, the result of the given array will render the parameter call defunct, outputting only the error from the function.
------------------------------------------------------------------------------
How do I prevent such vulnerabilities?
------------------------------------------------------------------------------
The simplest way to prevent these vulnerabilities is to simply turn off error reporting within your server. This will immediately turn off any errors that may be caused. The problem with this method however is that if you do have a problem with one of your scripts, it can be hard to determine where and what the problem is without the aid of the error message.
Regular expressions are also useful in disabling the errors, especially in the case of the cookie injection. With the array vulnerabilities, the is_array() function can be used to patch the vulnerability. The good thing about these last two methods is that you can also use them to echo fake errors to confuse your attacker.
------------------------------------------------------------------------------
Conclusion
------------------------------------------------------------------------------
In conclusion, I would like to once again stress that these vulnerabilities are useful only in certain circumstances and wont allow you to penetrate a server/site with this technique alone. You will have to rely on other techniques in conjunction with this vulnerability or other insecure practices (bad file extensions etc).
I hope you enjoyed the article and learned something from it.
Thank you (zer0w0rm)
0 comments:
Post a Comment