SymLink Vulnerability cPanel

Portal Home > Knowledgebase > Articles Database > SymLink Vulnerability cPanel

Posted by kshazad86, 01-11-2013, 08:23 AM
I have had lots of websites hacked on a shared cPanel server, and it appears that it is a Symlink vulnerability on the server. Can anyone advise how to protect against these attacks and how they are carried out?
Posted by NetworkPanda, 01-11-2013, 08:43 AM
Disable the symlink and shell functions in php.ini Open /usr/lib/php.ini Find this line: and modify it to then restart Apache This will prevent the creation of symlinks and execution of shell commands by PHP scripts Last edited by NetworkPanda; 01-11-2013 at 08:50 AM.
Posted by kshazad86, 01-11-2013, 08:47 AM
Thanks, any other change I can make, e.g. edit httpd conf file? How about turning off symlinks completely on the server? or will this break cPanel?
Posted by NetworkPanda, 01-11-2013, 08:49 AM
No, don't ever do this, symlinks are necessary for Linux and cPanel. Just disable their creation by PHP. Regarding your other question, no, you do not need to edit httpd.conf Some other security measures: Run EasyApache and install mod_security and suhosin (if now already done so)
Posted by kshazad86, 01-11-2013, 08:50 AM
Easyapache and mod_security are already installed, Suhosin is not supported as I am running PHP v5.3.
Posted by NetworkPanda, 01-11-2013, 08:52 AM
Suhosin is supported officially by PHP 5.3 and cPanel. We are already running it for several months on our servers with PHP 5.3.x Check again. If you can't install it via EasyApache, maybe you are not running the latest cPanel version.
Posted by Infinitnet, 01-11-2013, 08:54 AM
You can use this SymLink patch for EasyApache: Also you can have a look at this article: http://www.hostbreak.com/blog/tech-t...erver-security
Posted by kshazad86, 01-11-2013, 08:55 AM
Yep my mistake thanks, suhosin is already installed. One other thing, will enabling PHP Safe mode in the global php.ini file also help with these kind of attacks?
Posted by Infinitnet, 01-11-2013, 08:57 AM
No, safemode is deprecated in recent PHP versions.
Posted by NetworkPanda, 01-11-2013, 08:58 AM
This will protect from hacks but it will also disable some functions required by a lot of PHP scripts. I don't recommend it, it will disappoint your customers.
Posted by kshazad86, 01-11-2013, 08:59 AM
Is this a custom patch? It wont break cPanel in anyway?
Posted by Server Management, 01-11-2013, 09:02 AM
Safemode won't protect from anything in this instance since its deprecated as of PHP 5.3 and shall be removed as of PHP 5.4 http://php.net/manual/en/features.safe-mode.php
Posted by WebHostDog, 01-11-2013, 09:04 AM
Disabling all these PHP functions will kill the functionality. Also if there is some vulnerability attacker can upload own php.ini and override all these php.ini restrictions implemented by web hosting company.
Posted by Infinitnet, 01-11-2013, 09:08 AM
It's from the cPanel forums and written by Rack911 afaik.
Posted by kshazad86, 01-11-2013, 09:10 AM
ok great, will give this a try thanks
Posted by kshazad86, 01-11-2013, 09:19 AM
Just tried to run easyapache and got this error: Any ideas how to get this patch installed correctly?
Posted by kshazad86, 01-11-2013, 10:04 AM
Ok, managed to get it working, it seems the patch was written for Apache v2.2.22 rather than for the latest current version v2.2.23. To fix this error, simply update the patch file to use 2.2.23 and it should then install successfully via EasyApache.
Posted by HostingCraze, 01-13-2013, 11:43 AM
I would suggest you to get a cloudlinux kernal with cagefs enabled. So that symlinks from an account to root or home wont be accessible for that user.
Posted by kshazad86, 01-14-2013, 12:48 PM
I read on cPanel forum that you can also change the permissions of ln and this will stop users from being able to execute the symlink command, e.g. I am assuming this would remove the execute permission of 'ln' command for other users? Are there any negative impacts of using this approach also?
Posted by NetworkPanda, 01-14-2013, 01:10 PM
PHP web applications have no reason to run shell commands, so these disabled functions in my previous post do not cause any problems at all. Also, functions disabled on the entire server by the global php.ini can not be enabled by local php.ini files uploaded by the users. The disable_functions directive can not be overridden by the users. Last edited by NetworkPanda; 01-14-2013 at 01:23 PM.
Posted by kshazad86, 01-31-2013, 09:49 AM
Ok, seems like after I installed the patch few weeks ago, I got hacked again. Patch does not seem to be 100% effective, as a user managed to create a symlink to the root folder due to a weak cPanel login password for a specific user. Does anyone know if the server or cPanel will break if I change the permissions of ln to 760?
Posted by kshazad86, 01-31-2013, 10:46 AM
Does the patch only prevent php files and not perl files?
Posted by Emil Vals, 01-31-2013, 11:19 AM
Upgrade to CloudLinux, it has protection against this as well as CageFS. http://www.cloudlinux.com/blog/clnew...for-apache.php http://docs.cloudlinux.com/index.html?securelinks.html
Posted by Patrick, 01-31-2013, 12:21 PM
Prevents it all. ... why cPanel doesn't implement it into EasyApache, who knows!
Posted by gatorpatrick, 01-31-2013, 12:52 PM
We (HostGator) reported this vulnerability to Bugtraq in 2009 including a patch for Easyapache at that time (which has since been evolved into an even larger patch we utilize on our shared servers now). If you google for 'hostgator bugtraq symlink' you'll see our report in the first result. You can use our original patch, one of two patches provided in a huge forum thread on the cPanel forums about this issue, or cloudlinux as previously stated in this thread to resolve the issue for now. However it should be noted that attack vectors still exist without kernel level patching if you go with the apache patch route.
Posted by Lee-RackSRV, 01-31-2013, 01:07 PM
Was this definitely a recent exploit as opposed to one that was created prior to the patching ?, in some cases you'll find the site / server was exploited in the past and left for future exploits.
Posted by gatorpatrick, 01-31-2013, 06:23 PM
As I said previously, if you only apply the Apache patches attack vectors still exist. Not only that, but I know for a fact script kiddie distributed tools exist to take advantage of those vectors and the script kiddies specifically target shared cPanel hosting providers with said tools. Kernel level patching is needed. I believe Igor at Cloudlinux and Spengler over at GRSec have already implemented similar kernel work to what we run on our shared kernel to patch these vulnerabilities. If you want to be truly secure and free of these types of hacks you need to employ one of their methods or develop something similar.
Posted by iseletsk, 01-31-2013, 10:34 PM
For anyone who things that preventing some functions at PHP level will work: You can always use PHP script to create/modify .htaccess file and add a CGI handler (even if you have CGI disabled at cPanel level). After that create & execute perl script as CGI -- creating all the links you want, and bypassing any PHP related restrictions.
Posted by brianoz, 02-01-2013, 04:08 AM
While this is a common feeling, it's not actually true that kernel level patching is required to fix this, nor is it actually a kernel bug per se. The unix kernel is doing what it's always done; what introduces the security hole is partly the way Apache interprets symlinks in a multi-user environment running suphp, and partly the lack of protection in file modes (ie usually 644 instead of 600). The problem here is that Apache can be asked to read a file that is not normally accessible if a symlink is created. There is a setting in Apache called SymLinksIfOwnerMatch that mostly fixes this, but it may be possible for a user to override it and we've seen hackers do just that. The thing that makes this work is that it allows a hacker or skript kiddie to escalate a hack to cover the entire server. There are now several patches that help fix this - the StevenC/Rack911 one forces SymLinkIfOwnerMatches to always be on, and the bluehost patch fixes the race condition in checking the symlink ownership. A simple and very solid fix is to ensure the mode of PHP files on your system is 600 - that way the symlink doesn't have permission to read the files and the exploits don't work. I have some cron scripts that do this primitively but effectively at www.whmscripts.com and also there's a collation of some useful links and other patches there. Please note - I'm not knocking the obvious usefulness of patches created by Igor in CloudLinux, just wanting to introduce a little more clarity to the discussion. Apologies in advance if I'm wrong on some point. Unless I'm missing something, this isn't Unix permissions at all - the problem is that a process with group read permission to the folder is allowing access from another account. That doesn't hold true for other non-privileged processes - either running as PHP or CGI on the server (it does if you allow CGI to run as the generic apache user, but then you have very serious problems anyway as that's an issue in itself). ps: totally, utterly, agree with Igor that disabling PHP functions is a complete waste of time. There are 100 other ways of making symlinks ...
Posted by iseletsk, 02-01-2013, 07:39 AM
brianoz, you are correct -- kernel patch is not needed if you can make sure files are 600 or even 640 (and owned by user:user group). It doesn't prevent explaratory symlinks (like ln -s / 1.txt) that lets user browse the system, but it prevents user from reading php files. There is also a way (with a patch) to piggy back on SuexecUserGroup tag for virtualhost, and prevent symlinks attacks on php files -- even when they have other+read bit set -- which is quite secure (unlike SymLinkIfOwnerMatches). So, kernel solution by far is not the only solution. Yet, I see two problems with cronjobs: 1. Scanning all users files on regular intervals to see if they have proper permissions is undue stress on IO 2. You are still leaving time between scans for hacker to exploit. I know some hosting companies are using AV scanners that hook into FTP/sftp and check all uploaded files. Similar hooks can be used to 'fix' permissions. Also, some tools just use INOTIFY to monitor all filesystem changes in /home directory. This can also be used (but costly on start up) to fix permissions.
Posted by gatorpatrick, 02-01-2013, 11:01 AM
I still have to disagree. I've seen a 0 day PoC that leverages race conditions to exploit the behavior previously mentioned -- Igor I believe Dave may have mentioned or shown you as well. Plus even if that were not the case not using a kernel level solution at minimum causes dirty intensive workaround and leaves you open for information disclosure attacks.
Posted by iseletsk, 02-01-2013, 02:57 PM
Patrick, there are many things at once: 1. SymLinkIfOwnerMatch does have race condition/easily exploited 2. in my last discussion with Dave -- we concluded that Apache approach (which piggy backs on SuexecUserGroup) that we have & kernel approach are not exploitable via race condition 3. Information disclosure is still there -- no matter what you do. Kernel or not. We closed it down using CageFS - either way, symlinks is not the best way (though often used) to gain list of users or domains from the server.
Posted by Steven, 02-01-2013, 10:34 PM
One thing that people need to remember is, once you are compromised via this attack vector.. it doesn't matter how you patch it someone, has your customer scripts database details server wide. A pretty rigorous cleaning needs to be done, and you need to advise all customers to change their database passwords. Otherwise.. after you patch you will repeatedly be hacked.. despite being patched. Last edited by Steven; 02-01-2013 at 10:41 PM.
Posted by gatorpatrick, 02-02-2013, 02:13 AM
Yep, this is what I was getting at. Thanks for the clearer explanation.
Posted by brianoz, 02-02-2013, 06:44 PM
Permission on root filesystems (/home, etc) should prevent most exploration. Ah - brilliant - thanks for sharing this. True, there is time after a file is uploaded, however an hourly cron chmod job on the obvious public_html/*config* mostly closes this, and you'd have to be really unlucky for a hacker to guess. These are all fantastic solutions, I guess I've been pushing the quick non-kernel fixes as I see them as something any server owner can do very quickly with low impact, and very high coverage as far as the fix is concerned. I get your points about the window and the exploration though on another level - the kernel fix does close those nicely and it's awesome that you/CloudLinux have put such careful work and thought into producing a solid fix. Perhaps I'm paranoid but I see a place for solutions at a variety of levels as so often a fix at just one point is too easily bypassed by a future variation to the technique. eg the race condition workaround for the first stab at the SymLinkIfOwnerMatch patch. It's a little like the "switch to suphp and everything's secure" mentality. Steven - exactly, once bitten there's a hell of a lot of cleanup work. Now we need someone to help cleanups by writing a tool to go through and change all database passwords in both files and in the database! Last edited by brianoz; 02-02-2013 at 06:47 PM.

Add to Favourites Print this Article