Wednesday, February 1, 2012


OK so you shelled a site but don’t have much access or you just want to try out symlinking because you heard it was what the cool guys do. Well today I am going to show you a few methods we can use to accomplish this. Here goes nothing…

Assumptions & Pre-requisites:
-          Assume you already have Shell on site
-          Assume you either have permission or we are performing black box test scenario
o   Either way I am in no way responsible for anything you do with this information and am surely not responsible for any damages or destruction you might cause as a result of any misunderstandings of this material. Tread at your own risk.
-          Assume you have a brain and some basic prior experience with *nix environments or aren’t afraid of using Google to fill in the gaps as I will not be providing a lot of hand holding following this tut
OK so we have shell uploaded in the /images folder and we want to symlink to read the content of some other files. I will start simple and then build up from there…

We create a new folder to have a clean start and controlled environment, name it whatever you want although you might consider something inconspicuous if you don’t want it to stand out and set off any bell sand whistles:

I created folder “01” at location:  /home/pwnduser/public_html/images/01

COMMAND: mkdir /path/to/location/NewDirName

Now we are currently sitting in some image folder where we were able to upload our shell, but we don’t have much access. We will use Symlink method to bypass these restrictions and access files on other sites which we would otherwise be unable to access. We will now issue another set of commands to create the symlink between the file we want to read and the local file we actually have access to. In order to do this we issue this command:

ln -s /home/targetuser/public_html/path/to/file/you/want.file /home/pwnduser/public_html/images/01/sym-test.txt

You will need to replace targetuser with the username of your environment and the path to the file you want will obviously be up to you and will potentially vary from one site to the next. Here is an example so you can better understand:

ln -s /home/targetuser/public_html/includes/config.php /home/pwnduser/images/01/sym-test.txt

Now we check our file to see if it worked…

If we are lucky we will see a file created in our “01” directory called “sym-test.txt”. You should now be able to open it up and view the content of the remote file we linked to via the Symlink (in this case the “” file). When you open the sym-test.txt file on your controlled site it should be as if you were opening the target file directly (as if you were on the site it exists on):

NOTE: In order to get started if this is totally unfamiliar and completely alien to you; I suggest you try linking to a known file first. If this means simply linking to an index file a directory below you just to see how it works than do this until you get the gist of things and then move forward with the next steps as everything builds upon abusing this simple shortcut or link feature. If linking to unknown directories a little trial and error may be needed…

ALSO NOTE: in most cases, you can access the newly created symlink via URL as well if you care to share the find with a friend or just want to navigate to it outside of your immediate shell for the clear visual:

Once you have found a juicy file we can now try to gain DB access with the credentials just gathered from our symlink and in most cases it will be successful – then you can try to login direct to target site with the newly found credentials OR maybe update them using SQL if you can’t crack them - w00t!  

You can use built in SQL connectors in most shells or you may use an independent script its really up to you and what preferences you have or what features you like to have available for MySQL activities. In most cases shell tools will do but sometimes it is nice to have a specialized shell available for working a little SQL magic so either make your own or search the web for a good one…

You can continue creating symlink(s) to additional files as needed, although it does take a little trial and error to get things right if you’re guessing the remote system’s infrastructure. It also helps to know what type of CMS is in use as it can help to narrow down the search for juicy files which contain critical data which can be used for further escalation (Google and specialized dork searches can be your best friend for finding out what sites are on a given IP and what types of CMS software they are using).

Some common files to check (especially if using a blind approach):
Flashchat room: /includes/config.php or /chatbd/includes/config.php
vBulletin: /includes/config.php
IPB: /conf_global.php
MyBB:  /inc/config.php
Phpbb:  /config.php
Php Nuke: /config.php
Php-Fusion: config.php
SMF: /Settings.php
Joomla: configuration.php , configuration.php-dist
WordPress: /wp-config.php
Drupal: /sites/default/settings.php
OScommerce: /includes/configure.php
e107: /e107_config.php
Seditio: /datas/config.php

JOOMLA:  /home/target/public_html/configuration.php
WordPress: /home/target/public_html/wp-config.php

vB type of configuration file: /home/target/public_html/includes/config.php


If you want to remove the symlink you created you can’t simply delete it (in most cases), you need to actually do a hard deletion of the symbolic link itself. You can accomplish this by treating it like a directory instead of a file when using the “rm” command. Here is an example of how to remove the above so I can create a new link to a new file using the same name without any issues.

COMMAND (to remove): rm –r /path/to/folder/01/sym-test.txt
COMMAND (to create another symlink): ln -s /home/targetuser/path/NextFileName /home/pwnduser/public_html/images/01/sym-test.txt

Part I is a nice introduction to the basic principles of symlinking, but you may be asking how can I do this blind it will take forever or how to find those juicy files. You are right it can take a while, but let’s go over a few tricks we can use to help speed the whole process up a bit as  this method is not limited to our local site/user; we potentially can use and abuse it to also read files from ALL other sites located on the server. We can use reverse lookup or to check for other sites hosted on the same IP address as our hacked site to start things out (a few minutes up front can save you hours on the backend so always do your homework and lay out a plan of sorts).

NOTE: if the server is configured with multiple interfaces you may only get a partial finding of what is actually hosted on the server due to interfaces being configured with different IP addresses (very common), but this will certainly give you more than enough to stay busy for a while in most cases J

Once we have some potential targets to link to, we then use some more *nix commands to find out which users are linked to what sites. In order to do this we check the /etc/valiases by using this command:

COMMAND: ls –la /etc/valiases/
NOTE: replace with the domain name of your site (i.e.,, etc). DO NOT include the http:// or www

ACTUAL: ls -la /etc/valiases/
-rw-r----- 1 ukpussyt mail DATE:TIME /etc/valiases/

This method also needs to be combined with a quick viewing of the /etc/passwd file contents which contains a list of all users on the system as well as a showing of the path to their home directory. We can use this combined with the /etc/valiases results to determine the username and full path to our target site(s).

COMMAND: cat /etc/passwd

The /etc/valiases is a nice way to speed things up in a targeted attack although you can use just the /etc/passwd, some logic on the naming convention in use (gained from our site we already have access to), and a little trial and error if /etc/valias is not available to you. Either way the goal is to determine the path to the target site and knowing the username helps to speed things up and allow us to get started. If neither of these tricks work you can simply issue a “ls /hsphere/local/home/” or whatever is needed to fire at your base location listing all users directories (typically a directory below your current user base location). Another long reach is to use the “locate” command to try and enumerate locations and user names from information gleemed from the results (but this is long shot). We can then use these as potential lists for targets to symlink to.

Once we have a path to use for a target site we could start repeating the steps outlined in PART I: SIMPLE SYMLINKING, but instead of having to use trial and error to find a needle in a hay stack (i.e. config file) we will see if we can use another neat trick tied to symlinking. We will instead of linking to a single file try to create a folder link between a folder we control and the remote target site we want to now access from our already hacked site location. A folder to folder link! In order to do these we use very similar syntax was introduced in PART I but we leave it open-ended. The link will be created from wherever we execute the command so keep this in mind. Basically we give the command to create a symbolic link and then we give that link a name rather than pointing it to anything in particular.

ln -s /home/VictimUserName/public_html/ Gotcha

The above will create a symlink (ln –s) to the VictimUserName’s websites base directory (/home/VictimUserName/public_html/ ) and the link created will be labeled or called “Gotcha”. Once created we can open Gotcha and we will be staring at the VictimUserName’s site instead of a file located on our controlled site.

NOTE: You can also test it out with a simple “ln –s / root” which will create a link to the base directory of the server and label the link “root”

Once you know the full and direct path to specific files you can then easily create another symlink using Part I method to directly link or you can simply view them using the Gotcha link.

NOTE: If you can’t seem to access the link directly from your shell, try accessing the link as a URL and you might find better results. You may also need to upload an .htaccess file into your controlled /01/ directory to allow proper following of symlinks and indexing (in addition to anything else you might want to do in this folder). You can use Google to search and learn more about .htaccess as it is an entire subject which I can’t go into here. The short explanation is we can abuse .htaccess file to control the behavior for our directory and any “sub-directories” within it, in many cases overriding system wide global settings established in the apache config file (depends on options and overrides being allowed of course). This can be the key to bypassing 403 forbidden errors when you’re trying to link or view links so be weary this can make or break your attempts, especially if you try to use some of the famous CGI scripts which can automate this whole process – I HIGHLY RECOMMEND YOU SPEND TIME RESEARCHING THIS SUB-TOPIC ON YOUR OWN!

Now this concludes my introduction to symlinking and how to do it manually. There are indeed other ways to go about doing this as it can also be done with the assistance of Perl, CGI, and PHP scripts but if they don’t work now you know how to go about at least attempting things yourself manually. I hope you found this to be informative as I have not seen very many tutorials on this subject which have been clear in nature. If time permits and my knowledge can catch up I may do a follow up article on .htaccess techniques as well as some hints or highlights on other methods to use to get the job done, like doing the same thing we have done here with *nix commands with PHP. Going to end it now though and keep it simple so as to not take away from this being an introduction level tutorial. If you need further assistance you can find a wealth of help by searching on symlinking or symbolic links on the *nix forums and you can find more about .htaccess files in the Apache forums - I can’t recommend this part enough as it will save you from countless headaches when repeatedly encountering 403 and 500 error messages during your adventures :p

Until next time, Enjoy!

No comments:

Post a Comment