Exploit in RHEL Servers

[Cloaked]

I haven't see this posted here. There is a nasty root exploit that affects CentOS and CloudLinux. From various discussions I've read no one has yet found the cause. The rootkit puts file /lib64/libkeyutils.so.1.9 on 64bit systems and /lib/libkeyutils.so.1.9 on 32bit systems

I know CentOS is pretty popular and many hosts use it so if I were you I'd check the thread at http://www.webhostingtalk.com/showthread.php?t=1235797 and also this blog post http://www.cloudlinux.com/blog/clnews/sshd-exploit.php.There is a link to a bash script to clean this up, however, since this is a root exploit it's probably better to reload the OS. Those files might not be the only nasties that this dropped on the box.

This is pretty nasty. One user reported a clean install of CentOS on a new server and it was exploited in minutes.

The thread at WHT is long with a lot of good info so make sure you read it all.

[Dmacleo]

had been watching threads on that since CSF specifically mentioned it on last update. so far not seeing it on my end LOL

[Aiwa]

:cry: My eyes are watering after reading that thread... Good lord it's HUGE... Haven't seen it on mine, though it's a fresh OS w/ only basics installed on it ATM...

[p4guru]

thanks for heads up, all my CentOS based servers are loaded with CSF firewall by default though

[thompsone]

I feel bad for anyone getting rooted by stuff like this because it's a huge annoyance more than anything. But you have to admit it's usually their own fault. Why wouldn't someone take 5 seconds to set up some basic security? I can't think of any reason SSH needs to be public, can you? Regardless, from the looks of this it appears to be a local exploit on a work station. While it's a common configuration it's also a configuration of someone who should know better. IMHO.

::ducks for cover::

[handsoffsam]

Public SSH is fine, but don't allow password-based authentication. Make sure the ssh key is randomly generated and long. Don't use the same key as your account password (for sudo!). Allow only specific accounts in. Use KeePass (or your favorite tool) to generate random account names.

robert

[Rhett]

This turned out not to be an exploit and was actually a server within cpanel's own support system that was compromised and the hackers had support data to get into these boxes if you had filed a support ticket directly with cpanel in the last 6 months.

If you have you would have also received a notice from cpanel explaining this issue and to update your passwords.

:)

[thompsone]

- redacted -

[Rhett]

I don't think it matters how impossible a user pass combo may be since they are key logging. Locking down SSH would have prevented the access even if they had the user information.

In this case it wouldn't matter, if the access info was provided in the support ticket for cpanel to access the server, they had that info.

[thompsone]

Actually I redacted that post because you and I were posting at the same time. Given I had no idea it was a CPanel issue. However the fact that it was only strengthens my point. If you lock down SSH regardless of who has the credentials they can't use them. CPanel and Plesk like most services are bound to a port and can be restricted the same way. Regardless my posts were my thoughts on managing services open to the public, certainly not meant with any contention. I have always had the Lifelock philosophy. Who cares if they have the keys to my house if the doors are bolted shut.

Respectfully.

[Makoto]

I feel bad for anyone getting rooted by stuff like this because it's a huge annoyance more than anything. But you have to admit it's usually their own fault. Why wouldn't someone take 5 seconds to set up some basic security? I can't think of any reason SSH needs to be public, can you?

How in the world can you possibly not think of a reason someone may need a publicly accessible SSH server?

I don't think many of us are running forums off servers we host in our closet or basement. Obviously, we need a way to be able to remotely access and administrate our servers located in a datacenter we can't physically access.

It is however important to secure your SSH installation. Disable password authentication where possible and only use encrypted keys as a means of remote access. You should also have root login disabled.

[Royzee]

You should also have root login disabled.

No. Because that is something I use often on a self managed server.

[Makoto]

No. Because that is something I use often on a self managed server.

I mean in your SSHD configuration. Don't be lazy. Connect to a user account and su.

There's no reason to have root login enabled on your SSH server.

[thompsone]

All I'm saying is there are better options available to everyone other than having services, like SSH, globally accessible.

How in the world can you possibly not think of a reason someone may need a publicly accessible SSH server?

I don't even know how to respond to that question. Do you provide public access to SSH on your machine?

[Makoto]

All I'm saying is there are better options available to everyone other than having services, like SSH, globally accessible.

I don't even know how to respond to that question. Do you provide public access to SSH on your machine?

Perhaps you should define what you mean by "public access," because I'm hoping you're just confused here.

What are those "better options?"

Do I have a remotely accessible SSH server running on my laptop? No. On my server? Yes.

[thompsone]

I am not confused at all.

Those better options depend on how SSH is being used, what types of services are available to you, and how secure you want to be.

Is your laptop wirelessly connected to a router?

[Royzee]

I mean in your SSHD configuration. Don't be lazy. Connect to a user account and su.

There's no reason to have root login enabled on your SSH server.

As long as I periodically change the root password there is no difference between a user account and root.

[Makoto]

As long as I periodically change the root password there is no difference between a user account and root.

Yes there is. You shouldn't be connecting to your server directly as root, especially when you're using tunneled cleartext passwords. Why are you even giving people a chance, however minuscule (with hopes that you're actually using a secure password), of being able to brute force your root login credentials? Regardless of if you use a service such as CSF, it's simply a good security practice to disable root SSH login.

I am not confused at all.

Those better options depend on how SSH is being used, what types of services are available to you, and how secure you want to be.

Is your laptop wirelessly connected to a router?

Production web server running a single IPB website. Give me one valid example please. I don't think you understand what you're trying to preach.

[thompsone]

A valid example of what exactly?

[Royzee]

Yes there is. You shouldn't be connecting to your server directly as root, especially when you're using tunneled cleartext passwords. Why are you even giving people a chance, however minuscule (with hopes that you're actually using a secure password), of being able to brute force your root login credentials? Regardless of if you use a service such as CSF, it's simply a good security practice to disable root SSH login.

Production web server running a single IPB website. Give me one valid example please. I don't think you understand what you're trying to preach.

They cannot brute force my password unless they can do it on two tries. On the third try their IP is added to the firewall IP ban. I only use the root for Putty terminal access, which is much faster than cpanel for deleting or moving large folders.

[thompsone]

They cannot brute force my password unless they can do it on two tries. On the third try their IP is added to the firewall IP ban. I only use the root for Putty terminal access, which is much faster than cpanel for deleting or moving large folders.

That's a neat trick. How did you manage that? What happens if your caps lock key is on and you enter your password wrong three times? Are you locked out?

[Makoto]

That's a neat trick. How did you manage that? What happens if your caps lock key is on and you enter your password wrong three times? Are you locked out?

You can use a service like CSF or Fail2Ban, as I already mentioned in my previous post.

And since you will, again, not provide an example as to what you should use as a universal alternative to SSH on a production web server despite me asking 3 times, I am going to assume you truly have no idea what you're talking about.

And Sandi, I said using su over directly logging in as root is a recommended security standard for any server that uses tunneled cleartext passwords. It's not hard to do. But you should avoid using password authentication wherever possible anyways, as I've already said.

[Rhett]

For info, the best protection for SSH imo is the following, use some or all to suit.

1. run on non standard port (most critical and recommended to all)

2. ban on port scans (csf or other)

3. ban after x failed attempts if using pw's

5. allow ssh from secure vpn or static ip only

6 allow keys only

[Makoto]

Running your SSH server on a non-standard port is a good idea as well. It's also probably important to use CSF or another type of service to prevent port scans if you do this, as Rhett also recommended in his above post.

(Because if you don't, someone could probably just easily nmap your box and find what port your SSH server is running on)

If you have the privilege of having access to a secure VPN or have a static IP, you should definitely try and take advantage of that by only allowing connections to the SSH server from that IP. I don't think many of us have such, but basically everything Rhett listed I agree with.

[thompsone]

Well I don't know why you're attacking me and insulting my intelligence, but yes I do know what I'm talking about and I do run my SSHD on its standard port but the port is only accessible to IPs that need access, which is usually just myself. In your situation you have a service (granted secure in itself) open to the public. They can in essence see the door they are trying to get into and they can try to access your machine. In my situation they don't even see the door unless I allow them to. It's why I have no problem putting my root password on IPS site or anyone elses site. It's not because I trust that their site is secure, it's because I know that without access their key (username / pass) means nothing. In the case where the credentials were taken from CPanel it wouldn't have mattered if they had mine because they wouldn't have been logging in from an authorized IP address. A configuration like this is much more secure than any globally open service. When someone finds an exploit they go after the easy machines first. I won't be in that group.

My intent was to share a different view so others could harden their security or at least enhance it. Your throw down style is to aggressive to allow that to happen. Sorry I offered a second opinion on the matter.

Best of luck all.