Page 2 of 2 FirstFirst 12
Results 26 to 35 of 35
  1. #26
    Join Date
    Jul 2011
    Location
    Sittingbourne, Kent, UK
    Posts
    197
    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

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

  3. #28
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    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

  4. #29
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    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 ...

  5. #30
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    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

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

  7. #32
    Join Date
    Jun 2001
    Location
    Princeton
    Posts
    1,029
    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

  8. #33
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    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 | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

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

  10. #35
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,737
    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.

Page 2 of 2 FirstFirst 12

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
  •