We setup a demo account on one of our boxes to demonstrate Cpanel3. As we were monitoring the server we found someone trying to take advantage of this to break into the server. Fortunately we monitor the server regularly so they didn't get anywhere, but there is a security threat.

What happened was someone uploaded 2 files to the demo account. A PHP Script and a CGI script. The PHP was a simple script to execute commands on the server, the CGI script was some kind of brute force password attacker. The hacker would start the perl CGI Script (named banner.cgi so it would look like a legit script in a top or ps aux) and it would run as nobody.

Below, we describe what steps I recommend anyone with a CPanel3 demo do to prevent the problem:

1) Do not setup CGI script execution on the demo account
2) Do not setup MySQL, Email, Frontpage or Subdomains with the demo account.
3) Change ownership of the entire demo account file structure to root/root.
4) Modify the quote of the demo account to 5 mb/month.

All of these steps combined should stop an attack like we experienced.

Take care,

Brian

The best thing to do, is disable the demo altogether. The demo account can pretty much do anything any regular user can, let alone, that any other Cpanel user can do. You also have to worry about other means of compromised and people screwing around. People can use the Cpanel to view any file on the server that any other regular user can. Just disable it. If you want to have demo's, just go through it, create static HTML pages for user's to see.

No one needs to actually upload files, use the file manager, add POP email names or forwards (and those two last one's can also be used to get information, files and do other various things). Just disable the thing, use HTML and have people click through the static HTML pages to get an idea how it works, they don't need to do anything. If you want me to show you some other things of why I say this and how that's not going to solve your problem, email me and I'll show you. Just turn it off though, really.

It's bad enough when user's on a system can run these scripts, but non account holders to have near the same access, is not a good idea. Again, I urge you to turn the demo account off.

CPanel has several very large security holes, you can usually gain root access on any box with a cpanel demo account. Use static HTML instead.

DO NOT use the demo setup.

Also people who are aware of the steps to perform the "hack" please don't post it, VDI, and DarkOrb already are aware of the problem, so we don't need the script kiddies demonstrating on host who don't know.

hmm. security by obscurity? :-p

Originally posted by ckizer
CPanel has several very large security holes, you can usually gain root access on any box with a cpanel demo account. Use static HTML instead.

DO NOT use the demo setup.

Also people who are aware of the steps to perform the "hack" please don't post it, VDI, and DarkOrb already are aware of the problem, so we don't need the script kiddies demonstrating on host who don't know.

don't you remember what I told you, guys, several mounths ago???

here it is
http://www.webhostingtalk.com/showthread.php?s=&threadid=8546

by the way, THE HOLE STILL REMAINS!!!

wanna talk about it again?

So if you can gain root using a demo cp account, can't you do it if you're a customer with a real cp account?

sure I can! But this is not my goal.

CPANEL Security Holes are well Known
CPANEL demo suffers from the ability to upload and view files which can be used to exploit the system. You can easily upload a script that will allow you to run commands on the server as the web server user id. This basically grants an anonymous user a shell account that can be accessed via a browser.

Using CPANEL, you can then upload various files to help you exploit the machine. You can then compile, execute, and change these files at whim using the CPANEL file manager, which provides you a nice interface to try to get root.

Using the combination of shell access and the ability to upload files, you can easily try any number of exploits that are readily available on the web to gain root on a server. This is only a little different than having someone gain an unprivileged shell account on your server and use it to gain root.

This issue is well know to VTI (the makers of CPANEL) and to other security experts.


Issue not limited to CPANEL
This security issue is not limited to CPANEL. Any program that allows an abritrary user upload scripts (PERL, ASP, PHP) into a directory where the scripts will be executed has a potential security issue. Many early bulletin boards compromised systems by allowing the upload of files. You should be sure that if you allow uploads they cannot be executed via the web server.


Unrestricted use of PHP
One major issue is the use of PHP. PHP scripts exist to give you a web gateway to a shell. There is no way to prevent your users from installing a PHP shell script on your server (assmuming of course you allow php). If you have PHP compiled into apache or as a module, then the scripts will have the user id of the web server. To limit users from using php shell scripts, you could compile php as a cgi-bin application and run it through a cgi-wrapper. Thus making php scripts run under the user's name. Howerver, compiling php as a cgi-bin results in sigificantly lower performance.

Host-based DoS
Another type of attack is to use CPANEL and a shell program to make a perl script that simply hogs computer resources. This is a type of DoS that can be executed directly on the server. A simple infinite perl loop that builds large hashes of large random numbers would do the trick. Memory would quickly fill up causing problems. Also, you can use scripts to quicky fill up a disk by writing large files to insecure directories. (There was a very old perl script that would cat the dev directory and then write the output to tmpin sequentially numbered directories, thus filling up the tmp space -- this would bring some older sunos boxes to their knees).


What you can do
IMHO, I would not use a full demo of a cpanel account on a machine that is used for other purposes, e.g. serving clients web sites. Also, I would not run any program that allows anonymous users to upload and execute scripts on the server. This is a huge security issue. By using a variety of system monitoring scripts, a hacker could get a huge amount of info on the server, install packet sniffers, etc.

Can my clients hack using CPANEL?
Of course, any client can use CPANEL to exploit your machine. But this is true for any client who has access to your server. I don't know of any hackers who want to pay for access to a web server when they can easilly hack one for free, so the only threat is from your own clients. If you find a client trying to hack the web server, then simply cancel their account.

That is the essence of the problem people speak of. The _only_ reason why Cpanel is brought up into the issue of being insecure, is the demo account. Read this carefully!! THE ONLY REASON WHY CPANEL IS A SECURITY ISSUE, IS BECAUSE OF THE DEMO -- NOT CPANEL PER SE! READ IT AGAIN, AND AGAIN, AND AGAIN, if you need to.

Simply put, and as stated above, this is an issue for any shared server. This is not related to CPanel. Everyone knows I despise CPanel, and for many reasons. However, what I meant by insecure, is that the demo account basically allows people to be able to have the same type of access as any other user on the system.

That said; of course people can try exploits with the demo account -- and they don't have to sign up, show anyone whom they are and can use proxies, etc. via the web and their browser -- which is a lot easier than spoofing addresses, etc.

Turning off the demo is a good idea, simply because you are giving the outside world the same access as anyone else on the system. Any regular user, that is. That DOES NOT include root or any other privileged user. Yes, there might be exploits of the CPanel software that can result in gaining root access -- BUT I HAVE YET TO SEE IT! What people are talking about here, is just having the same access through the demo account, as they do if they were a user on the system -- because the demo account is a real user. That's all it is, there is no "exploit". There is no "gaining root". The only way someone can gain root using the Cpanel demo (or a regular user's Cpanel), would be the same way any other user on the system would via their shell, their account, via Cpanel or otherwise uploading some type of exploit. That is NOT related to CPanel.

The issues that ARE related to Cpanel are the following:

-> System access, just like any other user.
-> Ability to upload, compile and maybe even get shell access via the demo account, or mimic shell in a script.
-> Ability to utilize Cpanel and it's functions to read, write and alter files of the demo and other user accounts that have poor permissions anyway, or are running as the same global web server user.

These issues, can be immediately solved by not using the demo. This DOES NOT mean that people can gain root access. All it means, is that the demo user (just as ANY OTHER user of Cpanel -- just as ANY other user with shell or FTP access can do anyway) can snoop around the system and view any file that they are not denied from viewing anyway. Is that a Cpanel issue? NO! This is and has been simply an issue of permissions and ownership. The global web server user issue creates the problem of allowing other user's on the system to create, alter, delete and view any files that the web server's global user has permission to. That again, is NOT an issue with Cpanel! The ONLY reason why it's an issue with Cpanel, is because Cpanel will error if you implement a CGI wrapper such as SuEXEC, and that sucks, but that's the reason why Cpanel is part of the issue.

However, CGI Wrappers don't, as mentioned above, resolve the problem of user's using PHP to view, create, delete and alter files that PHP has access to still. Is that a Cpanel issue? NO, definitely not. That is an issue on any shared server running PHP as a web server module and not CGI. As mentioned above as well, the only realistic manner to resolve that, is to use it as CGI -- which completely takes the point out of PHP's efficiency to even use it anyway!

This whole "Cpanel means people can get root" type of post, is completely ridiculous and inaccurate, BigAl. I mean, enough already. The ONLY reason why Cpanel is an issue, is because it gives outside user's these same opportunities to exploit these system and configuration faults that ALREADY EXIST anyway, provided the Cpanel demo user is enabled. That's all it means. I do, however agree, that currently, it's better to not allow the outside world the same access to the system. That goes without saying, but that also doesn't mean that Cpanel has a huge security hole either. Again, it's possible one or many exist, but I have YET TO SEE IT! I also haven't gone through and tried a lot of exploits, because too many other problems exist in Cpanel to worry about, other than how it only opens up the same problem that exists when you give user's access to the system anyway -- and that is all it is!

Provided these things, the demo account wouldn't pose this 'big, scary' issue of allowing outside user's this trivial access -- and that's all it is, since this problem does and will continue to exist on any shared servers;

-> Disable the demo account, make sure it doesn't have FTP or shell access either. OR, keep the demo account available and;

-> Make it so the demo account can't FTP or get shell account -- only allow access to the panel. This also means, no access to file manager, telnet (shell) through the control panel, cron, mail, etc.

-> Find a way to implement SuEXEC for CGI and remove all the globally accessed scripts on the system and put them into the user's directories to be ran, not one system wide file (since it would obviously fail).

-> Disable CGI access on the demo account.

-> Make it so PHP will not run in the demo account.

-> Set the proper permissions and ownership on the user's directories and other files to deny anyone but the user. Okay, you still have the PHP issue, but NOT for the demo account.

-> Implement chroot and some other wrappers to have more control.

-> Either remove the demo user from having a system account, or set the permissions on the demo account to be owned by root and make it so the files are only readable, to where people can't upload, create or alter any file or directory on the demo account. Remove their access to any temporary directories as well.

-> Take away every feature in Cpanel that an outside user can use to gain access, get file information or files from, or otherwise gain access to the system and create, alter, delete or view anything.

-> As you can see, it's just and mainly the issue of anyone having access to the server via the demo account. This is the only reason why it's an issue. There's not an exploit, it's just a problem because of allowing non system account holders access. You can limit that access and limit CGI, PHP and file uploading, etc.. but, at that point, you take away any means for someone to interact and test the demo of the control panel. What does that mean? Well, why not save the hassles of trying to allow an account on the system with limited access and try and ensure that access can't be abused, and just simply use a static HTML template system and screen shots to demonstrate the control panel.

Again, I can't stress this enough, what's being discussed here, even means to gain root access by exploits or obtaining information from files to get root that way, etc., this is NOT a Cpanel issue! If you allow the world access to any type of account on a shared server, this SAME problem will still exist due to how the web server is set up and how the system is configured, what permissions and ownership are used and what other security measures are implemented. That is NOT a Cpanel issue.

Let's face it, this is only about allowing outside access to the system, even if you do limit some of the things the outside world can do -- it's still risky and not a good idea. This, however, and once again, is an issue anyway and has nothing to do with the Cpanel -- but the moral is to not allow people on the outside an interface to assist them in abusing the access you do allow -- and that's an issue for any manner of allowing any type of account access. Therefore, there's not really any security issues with Cpanel, since these issues already exist on the system. I'm not sure how many more times I can explain that to BigAl, but so be it.

The point is, don't worry, I've yet to see any evidence that an actual exploit exists. I'm not saying it can't or doesn't, but definitely not what BigAl is talking about. If your web server is configured in a manner to allow user's to view other user's files and compile and execute exploits, then you have a problem anyway, and that has nothing to do with Cpanel, other than the simple fact that the demo just might be allowing everyone in the great wide web to have the same opportunities as the account holders on the system to abuse these aspects.

That is the problem, in a nutshell, it's not a huge deal... just disable the demo account, or configure it and the system to not allow the demo user any type of access that would have that result. Disabling the demo and simply using screen shots and HTML, is just a safer and faster way for most people. That's all there is to it, the rest of the issues are only related the the system, not the Cpanel -- unless someone truly does find an exploit -- and I have yet to see any.

Thanks Tim... BTW, could you repeat that? I didn't catch it all. :)