Results 1 to 35 of 35
  1. #1

    Question SymLink Vulnerability cPanel

    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?

  2. #2
    Join Date
    Oct 2012
    Location
    Europe and USA
    Posts
    915
    Disable the symlink and shell functions in php.ini

    Open /usr/lib/php.ini

    Find this line:
    Code:
    disable_functions =
    and modify it to

    Code:
    disable_functions = "symlink,shell_exec,exec,system,chmod"
    then restart Apache
    Code:
    httpd restart
    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.
    Network Panda :: Web Hosting SSD Powered :: Reseller Hosting
    Instant activation, fast servers, SSD disks, cPanel, Softaculous 1-click apps installer, R1Soft, SSL certificates
    Multiple hosting locations: USA, Canada, France, UK, Germany, Italy, Spain, Poland, Finland

  3. #3
    Quote Originally Posted by NetworkPanda View Post
    Disable the symlink and shell functions in php.ini

    Open /usr/lib/php.ini

    Find this line:
    Code:
    disable_functions =
    and modify it to

    Code:
    disable_functions = "symlink,shell_exec,exec,system"
    then restart Apache
    Code:
    httpd restart
    This will prevent the creation of symlinks and execution of shell commands by PHP scripts

    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?

  4. #4
    Join Date
    Oct 2012
    Location
    Europe and USA
    Posts
    915
    Quote Originally Posted by kshazad86 View Post
    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?
    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)
    Network Panda :: Web Hosting SSD Powered :: Reseller Hosting
    Instant activation, fast servers, SSD disks, cPanel, Softaculous 1-click apps installer, R1Soft, SSL certificates
    Multiple hosting locations: USA, Canada, France, UK, Germany, Italy, Spain, Poland, Finland

  5. #5
    Easyapache and mod_security are already installed, Suhosin is not supported as I am running PHP v5.3.

  6. #6
    Join Date
    Oct 2012
    Location
    Europe and USA
    Posts
    915
    Quote Originally Posted by kshazad86 View Post
    Easyapache and mod_security are already installed, Suhosin is not supported as I am running PHP v5.3.
    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.
    Network Panda :: Web Hosting SSD Powered :: Reseller Hosting
    Instant activation, fast servers, SSD disks, cPanel, Softaculous 1-click apps installer, R1Soft, SSL certificates
    Multiple hosting locations: USA, Canada, France, UK, Germany, Italy, Spain, Poland, Finland

  7. #7
    Join Date
    Dec 2011
    Location
    Germany
    Posts
    1,140
    You can use this SymLink patch for EasyApache:

    1. http://spasov.us/patch/Apache.zip

    Login as root go to /var/cpanel/easy/apache/custom_opt_mods/Cpanel/Easy/Apache

    upload this files SymlinkProtection.pm SymlinkProtection.pm.tar.gz on this directory /var/cpanel/easy/apache/custom_opt_mods/Cpanel/Easy/Apache

    2. Run /scripts/easyapache, and select SymlinkProtection from the "Exhaustive Options" list
    Also you can have a look at this article: http://www.hostbreak.com/blog/tech-t...erver-security
    JavaPipe LLC: Global Tomcat Hosting & DDoS Mitigation Solutions
    In business since 2001 | Contact us: salesrequest[at]javapipe.com
    █ Remote Protection | Dedicated Servers | Virtual Servers | Unmetered VPS | Tomcat Hosting

  8. #8
    Quote Originally Posted by NetworkPanda View Post
    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.
    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?

  9. #9
    Join Date
    Dec 2011
    Location
    Germany
    Posts
    1,140
    Quote Originally Posted by kshazad86 View Post
    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?
    No, safemode is deprecated in recent PHP versions.
    JavaPipe LLC: Global Tomcat Hosting & DDoS Mitigation Solutions
    In business since 2001 | Contact us: salesrequest[at]javapipe.com
    █ Remote Protection | Dedicated Servers | Virtual Servers | Unmetered VPS | Tomcat Hosting

  10. #10
    Join Date
    Oct 2012
    Location
    Europe and USA
    Posts
    915
    Quote Originally Posted by kshazad86 View Post
    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?
    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.
    Network Panda :: Web Hosting SSD Powered :: Reseller Hosting
    Instant activation, fast servers, SSD disks, cPanel, Softaculous 1-click apps installer, R1Soft, SSL certificates
    Multiple hosting locations: USA, Canada, France, UK, Germany, Italy, Spain, Poland, Finland

  11. #11
    Quote Originally Posted by infinitnet View Post
    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
    Is this a custom patch? It wont break cPanel in anyway?

  12. #12
    Join Date
    Nov 2009
    Location
    /etc/my.cnf
    Posts
    10,035
    Quote Originally Posted by NetworkPanda View Post
    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.
    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

  13. #13
    Join Date
    Mar 2006
    Location
    Servers
    Posts
    1,588
    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.
    QHoster.com - Web Hosting with DDoS Protection | Shared & Reseller in Europe/North America
    Linux/Windows RDP VPS 13 Locations : UK, US (5 states), Mexico, Canada, Bulgaria, Lithuania,
    Italy, France, Germany,Netherlands, Switzerland, Rissia, Singapore | OpenVPN/PPTP Enabled
    INSTANT | PayPal, Skrill, Payza, Bitcoin, WebMoney, Perfect Money, Ukash, CashU, paysafecard

  14. #14
    Join Date
    Dec 2011
    Location
    Germany
    Posts
    1,140
    Quote Originally Posted by kshazad86 View Post
    Is this a custom patch? It wont break cPanel in anyway?
    It's from the cPanel forums and written by Rack911 afaik.
    JavaPipe LLC: Global Tomcat Hosting & DDoS Mitigation Solutions
    In business since 2001 | Contact us: salesrequest[at]javapipe.com
    █ Remote Protection | Dedicated Servers | Virtual Servers | Unmetered VPS | Tomcat Hosting

  15. #15
    Quote Originally Posted by infinitnet View Post
    It's from the cPanel forums and written by Rack911 afaik.
    ok great, will give this a try thanks

  16. #16
    Quote Originally Posted by kshazad86 View Post
    ok great, will give this a try thanks
    Just tried to run easyapache and got this error:

    -- Begin opt 'SymlinkProtection patch' --

    -- Begin step 'Applying SymlinkProtection patch' --
    Testing patch 'symlinkprotection.patch' -p1...
    The text leading up to this was:
    --------------------------
    |--- httpd-2.2.22.orig/server/request.c 2012-03-03 17:39:45.000000000 -0400
    |+++ httpd-2.2.22/server/request.c 2012-03-03 17:29:22.000000000 -0400
    --------------------------
    File to patch:
    Skip this patch? [y]
    3 out of 3 hunks ignored
    Testing patch 'symlinkprotection.patch' -p0...
    The text leading up to this was:
    --------------------------
    |--- httpd-2.2.22.orig/server/request.c 2012-03-03 17:39:45.000000000 -0400
    |+++ httpd-2.2.22/server/request.c 2012-03-03 17:29:22.000000000 -0400
    --------------------------
    File to patch:
    Skip this patch? [y]
    3 out of 3 hunks ignored
    !! Patch test 'symlinkprotection.patch' failed !!
    !! Restoring original working apache !!
    Any ideas how to get this patch installed correctly?

  17. #17
    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.

  18. #18
    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.

  19. #19
    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.

    chmod 760 /bin/ln
    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?

  20. #20
    Join Date
    Oct 2012
    Location
    Europe and USA
    Posts
    915
    Quote Originally Posted by WebHostDog View Post
    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.
    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.
    Network Panda :: Web Hosting SSD Powered :: Reseller Hosting
    Instant activation, fast servers, SSD disks, cPanel, Softaculous 1-click apps installer, R1Soft, SSL certificates
    Multiple hosting locations: USA, Canada, France, UK, Germany, Italy, Spain, Poland, Finland

  21. #21
    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?

  22. #22
    Does the patch only prevent php files and not perl files?

  23. #23
    Join Date
    Nov 2007
    Location
    Iceland
    Posts
    31
    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

  24. #24
    Join Date
    Mar 2003
    Location
    Canada
    Posts
    8,908
    Quote Originally Posted by kshazad86 View Post
    Does the patch only prevent php files and not perl files?
    Prevents it all.

    ... why cPanel doesn't implement it into EasyApache, who knows!
    Patrick William | RACK911 Labs | Software Security Auditing
    400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com

    www.HostingSecList.com - Security notices for the hosting community.

  25. #25
    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.

  26. #26
    Join Date
    Jul 2011
    Location
    Sittingbourne, Kent, UK
    Posts
    194
    Quote Originally Posted by kshazad86 View Post
    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?
    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.
    RackSRV Communications Limited
    UK specialists in Dedicated Servers & Server Colocation
    Company: 06856870 VAT: GB 934 7073 15 Tel: 0330 111 4444

  27. #27
    Quote Originally Posted by Lee-RackSRV View Post
    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.
    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.
    Patrick P.
    HostGator.com LLC
    patrick(@)hostgator(.)com

  28. #28
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    827
    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.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  29. #29
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,677
    Quote Originally Posted by gatorpatrick View Post
    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.
    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 ...

  30. #30
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    827
    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.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  31. #31
    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.
    Patrick P.
    HostGator.com LLC
    patrick(@)hostgator(.)com

  32. #32
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    827
    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.
    Igor Seletskiy
    CEO @ Cloud Linux Inc
    http://www.cloudlinux.com
    CloudLinux -- The OS that can make your Shared Hosting stable

  33. #33
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,267
    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.
    Steven Ciaburri | Proactive Linux Server Management - Rack911.com
    Managed Servers (AS62710), Server Management, and Security Auditing.

  34. #34
    Quote Originally Posted by iseletsk View Post
    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.
    Yep, this is what I was getting at. Thanks for the clearer explanation.
    Patrick P.
    HostGator.com LLC
    patrick(@)hostgator(.)com

  35. #35
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,677
    Quote Originally Posted by iseletsk View Post
    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.
    Permission on root filesystems (/home, etc) should prevent most exploration.

    Quote Originally Posted by iseletsk View Post
    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).
    Ah - brilliant - thanks for sharing this.

    Quote Originally Posted by iseletsk View Post
    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.
    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.

    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.
    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.

Similar Threads

  1. cPanel Vulnerability?
    By joecooper in forum Web Hosting
    Replies: 6
    Last Post: 02-22-2012, 06:07 PM
  2. Password Protect Symlink in cPanel
    By w00ts!te in forum Hosting Software and Control Panels
    Replies: 0
    Last Post: 07-23-2009, 02:17 PM
  3. cPanel Horde Vulnerability Found - Please update your cPanel ASAP
    By Virtuoso Host in forum Hosting Security and Technology
    Replies: 14
    Last Post: 03-09-2008, 02:35 PM
  4. SIM installer symlink attack + race condition local root vulnerability
    By jpetersen in forum Hosting Security and Technology
    Replies: 0
    Last Post: 04-29-2007, 01:54 PM
  5. CPanel vulnerability
    By aah-jim in forum Hosting Software and Control Panels
    Replies: 1
    Last Post: 02-19-2003, 09:27 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •