Symlink attack is one of the newest and eaiesty way of exploitation as the attacker gets full root access to the entire server from a compromised website . The hackers are more likely to attack more websites if the server is in a shared environment.
Thus, How do they get root privileges?
++++ Create symlink to Root or / ++++
Most of the shared servers only give restricted FTP access to their customers. So the end-user can only see the content of their own home directory. This scenario provides an extra level of security because end-users cannot use or view other user’s contents
However, this is an old technique that attackers perform to link a sub- directory within the domain’s document root to the root ‘/’ directory, allowing them to browse the whole server by running a simple PHP command.
The directory ‘forroot’ is symlinked to the root directory. Thus some of the shared hosts put restrictions on their end users and controls on their PHP settings by restricting file access to only the user home directory. But it can be bypassed if suppose the hosting provider supports customized cron jobs, procmail rules or even cgi-bin scripts itself.
In some cases, the attackers or hackers will create a customized php.ini file to overwrite the default ones and will create their own rules to exploit the server. It doesn’t matter how the attacker work around to get the root access, In most cases the attackers put a .htaccess . The worst part is that the files can then be viewed remotely by anyone.
Read an example, It is taken from a compromised server and the directory ‘ forroot’ is symlinked to root directory of the server.
ftp /www/ > cd forroot
ok. current directory is /www/forroot
ftp /www/forroot > ls -la
drwxr-xr-x 46 user1 user1 4800 May 20 11:32 .
drwxr-xr-x 36 user1 user1 48006 May 20 11:32 ..
-rw-r–r– 1 user1 user1 186 May 20 11:32 .htaccess
lrwxrwxrwx 1 user1 user1 1 May 20 11:32 root -> /
If you look at the .htaccess, it contains custom rules to treat all conf,php,log and sql files as texts, so it is visible in a browser.
AddType textplain .php
AddType textplain .conf
AddType textplain .sql
AddType textplain .log
AddHandler server-parsed .php
AddHandler txt .html
And the attackers can access the files via a regular browser.
> symLinksIfOwnerMatch protection
This is an apache level protection and it is the quickest solution for this specific attack is to prevent Apache from following symlinks (FollowSymLinks) in apache configuration.
You can also prevent end-users from overwriting the default security rules (AllowOverride None). If you really need links, you can use the “symLinksIfOwnerMatch” option to only allow create links from within the specific user not to / .
Options ExecCGI Includes IncludesNOEXEC Indexes SymLinksIfOwnerMatch
The changes should be like this.
This alone doesn’t solve whole problem, but the client still is having php access and can just use opendir(“/”) and can reach all other directories directories they wish. Inn order to prevent from users who access any file outside of their home directory, the hosts need to specify the (open_basedir) setting to give permission to their own directory only.
>> Using cloudlinux
CloudLinux provides comprehensive protection against symbolic link attacks which is known and common threat in shared hosting environment. Mostly cloudlinux itself give minimum protection
against symlink attack, there is another thing plays an important role in this category and that is Securelinks.
See yourself, the role of securelinks in symlink attack [https://cloudlinux.com/securelinks]
Also if the server is using cloudlinux , there are some options that should be configured.
To protect against symlink attack , enable this option to 1 .
If you set this option to 1 , it will prevent any process running under
gid fs.symlinkown_gid is to follow the symlink if owner of the link doesn’t match the
owner of the symlinked file.
These are the defaults options:
fs.enforce_symlinksifowner = 1
fs.symlinkown_gid = 48
fs.enforce_symlinksifowner = 0
· It will not check symlink ownership
fs.enforce_symlinksifowner = 1
· It will deny if symlink ownerships don’t match target file.
While fs.enforce_symlinksifowner set to 1, processes with GID 48 do not able to follow symlinks if they are owned by user-1, but point to file owned user-2.
Note// fs.enforce_symlinksifowner = 2 will cause issues for the server operation.
Usally Apache will be running under GID 48.
On cPanel servers, Apache user will be nobody, thus GID 99.
To change GID of processes which cannot follow symlink, edit file /etc/sysctl.conf,
fs.symlinkown_gid = XX
Inn order to disable ‘symlink owner match’ protection option,
Set fs.enforce_symlinksifowner = 0 in /etc/sysctl.conf,
# sysctl –p
Other security measures:
>> Do not allow users to change php settings through php.ini or .htaccess file.
>> Enable Apache mod_userdir Tweak and do not exclude any of the hostname .
Because via ‘ sampledomain.com/~username/ ‘ php.ini global settings can be changed.
>> Disable symlink for all users.
>> disable following functions in php.ini (disable_functions) , globally.
[show_source, shell_exec, passthru, exec,
dl, escap, eshellarg, escapeshellcmd, popen.]
You can run the script to find symlink hack:
[find /home*/*/public_html -type l >> /root/symlinks.txt]
These are the practical methods that can be used against symlink exploitation, although there are many other methods such as kernel level protection ,mod_ruid + jail shell method , easy apache symlink protection; the options which mentioned above (using cloud linux) are the best and newest for these type of exploitation.