Welcome back my fellow noob!
In this tutorial we are going to talk about an attack called Full Path Disclosure.
Full Path Disclosure
Full Path Disclosure attack allows an attacker to see the full path of file and the attacker can use this information for exploiting some other vulnerabilities like Local File Inclusion.
Have you ever seen an error like this?
<span style="font-size: xx-small;">Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in <span style="color: #ff0000;">C:\wamp\www\en\events_detail.php</span> on line <i>47</i></span>
Looks like the web application threw an error and it also contains full path of the file. You can see that right?
Well its an example of a Full Path Disclosure attack.
Attacking The Web Application
So how do we exploit it? Its simple, all we have to do is to make the application misbehave.
Messing with parameters
Lets say we have the following URL in sight:
vulnerable.com/page.php?<span style="color: #00ff00;">view</span>=<span style="color: #ff0000;">value</span>
Here the view is a parameter and value is its value. Now lets add some special characters in the value like this:
vulnerable.com/page.php?view=value<span style="color: #ff0000;">';></span>
And our shot landed right on the target:
Well I could have caused this error by injecting a single quote ‘ but using a string like this <\*;'”//> should be preferred as the nature of the web application is unknown.
We can also disturb the parameter itself. If we add a null array in the parameter name like this:
vulnerable.com/page.php?view<span style="color: #ff0000;"></span>=value
Then if the web application is misconfigured, we will get an error like this containing the full path of the file:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/web/domains/vulnerable.com/public_html/project/gallery.php on line 124/pre>
If the parameter value is a number, try changing to a string. The thing is that we want to make the web app do something which is not intended.
Now lets mess up with cookies.
lets say we have have three cookies issued by 3 different websites:
Now lets change there values:
So in the first cookie, I changed the parameter name as well as the value which may cause an error in the application. In the second case, i entered a lot of characters (130 chars in the total). If you enter a string of 129 bytes or more in a PHPSESSID, it may throw an error. In the third one, I just removed the cookie value hence making it null which may cause an error.
You may use any of these 3 distortions to achieve your goals.
Eat those cookies! Yummmm…
Asking for invalid resources
Lets say we have a URL
Looks that the open parameter opens different pages for the user.
Now lets replace gallery.php by a page that doesn’t exists on the web server.
If you are lucky, it may cause the application to throw an error which may contain the full path of the file.
If you are dealing with .asp or .aspx pages instead of .php, Full Path Disclosure attack is a piece of cake because you just have to cause a 404 error. For example,
If you are lucky, you may receive an error like this:
Note: It works with websites running asp/aspx technology only, and not always.
Can I have phpinfo please?
So I tried to visit http://vulnerable/phpinfo.php and got this error:
So you should try to hit these paths as well:
So thats how you can make a web application throw errors with juicy info. Our aim is just to make the application do something which its not supposed to.
I hope you liked this tutorial of Full Path Disclosure.
Do you know some other techniques? Let me know in the comments and I will add them here.
Keep learning! Keep hacking!