All these threads about hacking...hmmm.

Some rules to live by:
1. Treat local root exploits as remote root exploits.
2. Remember that giving someone PHP or cgi access is as good as giving them shell access.
3. Make sure your normal user passwords are different to root's password. Make sure root can't log in except by using su. Never ftp as the root user.
4. Use sftp instead of ftp.
5. Corollary to 3: For random Internet accounts (like this forum, other forums, games, PayPal etc.) for god's sake use a password other than your root password! If you have some web-based administration stuff (does CPanel, Ensim et al. use HTTP or HTTPS?) make sure that the control panel software (a) can't change the root password (b) doesn't know the root password and © you don't use the root password for your control panel admin. Cobalt RaQs are particularly bad - the admin stuff is unencrypted and it can change the root password.

It's quite possible that passwords were sniffed from ftp sessions. All it takes is one compromised box on your subnet, or a compromised router between home and the server. If your non-privileged accounts have different passwords to root, it seriously limits where a password sniffer can go.

On cgi scripts and PHP scripts: Your customers or users typically aren't the threat; skript kiddies rarely buy service to hack a box (but it HAS been known so don't discount the risk).
All it takes is a badly written PHP script. A vhost on my server had this little beauty:



$some_variable wasn't initialized. So the attacker could pass in this to their browser:

http://the-vsite.com/program.php?some_vari...om/phpshell.php

and they were running a PHP shell on my server. From this, they used wget to download a bindshell (opens a TCP port they can telnet to to access a shell) into /tmp, then used the bindshell to try and exploit a local root exploit in the 2.4.19 kernel. Are you running kernel version < 2.4.20? If you are, you're vunerable to being rooted this way. Fortunately, I had implemented a workaround that stopped this exploit from working, and caught the cracker red-handed.

This was through a buggy PHP script - not an Apache exploit, or a buffer overflow, or anything like that. If you host virtual sites, there are probably hundreds of PHP or CGI scripts installed by your users. The probability that one of these scripts is a pile of insecure cruft is very close to 1.

Quite frankly, with the speed of the RS network (and therefore, the extreme desirability of the RS network to DDoS skript kiddies - one RS box has the destructive power of 200 exploited cable modem users) I'm suprised this forum isn't filled with reports of hacked servers.

5) Yes Ensim forces HTTPS on the panel.

Thank you for your story of root exploits. Fortunately Ensim chroots all the virtual domains, so even if someone obtains shell access on one, it doesn't help a lot. In fact, I give all my users shell access. The virtual domains don't have root access, it's just not an option.

Not to say that it's not exploitable. Everything has a weakness if you look long enough. But I think most hackers would go for a plain Redhat box or even a Cpanel box before going through the hassle of dealing with Ensim's chroot system.

Btw, I know that RS is taking all hacker attempts VERY seriously and there are several FBI cases ongoing. Hackers should learn that this is not a game. The damage they do are costing the owners of the servers real money and they will be found, procecuted and punished sooner or later.

If the server is running a firewall they cannot run bindshell uploaded through PHP, correct? Unless they could find a port that you had opened on the firewall that nothing was binded to? Or am I totally wrong?

Regards,

Steve

No, you're not wrong. It depends on what you do with your box, and how you configure firewalling.

The trouble is, in the case of the 'find a bad PHP script, then try a local root exploit', bindshell isn't even necessary. The same exploit can be made to work via a little bit of extra scripting and using the PHP vulnerability outlined earlier. Instead of interactively entering the commands to own the server via bindshell, the attacker just needs to add some code to the program that performs the local root exploit to switch off the firewall on whatever port they choose. Or maybe add a user to your server, so they can use ssh. Or switch off the firewall completely.

Firewalls are useful, but they are no subsitute from keeping track of and eliminating local root exploits.

Winston outlined one possible solution. Another would be if they were able to get the appropriate access (root?) they would be able to issue the appropriate IPTable command to open a port for their bindshell.

It's a null-point anyway. As winston pointed out, they'd just have to write a longer list of commands in their script.

Also, there are plenty of boxes at RS that are NOT running a firewall -- so hackers can ignore the hard-to-get boxes, and go for the easy ones... Especially if all they want to do is DDoS something.

I understand this :-) I just want to make sure my box is relatively safe... Running perl under suexec will prevent users from using it to get root, correct? How can I protect PHP?

Well, not if there's something on your swerver that has a local root exploit hole in it.

What suexec does is makes your cgi-scripts run as the user they belong to, instead of the 'apache' user. The advantage of using suexec is that users can make files that contain database passwords and the like only readable under their uid, instead of having it readable by user 'apache'. If a user's file is readable by user 'apache', a hostile user could write a cgi-script that reads their file containing the things they don't want to get out (like the aforementioned database passwords). Suexec is really about protecting your users from each other.

true.. with all the bandwidth RS has and the sheer number of servers it has in the building, you guys are "BIG" blip on the hacker radar... and it does not matter how good the security is, you will always have a few boxes that get owned in one way or another.... its what makes the job fun EH?