SSHD Rootkit

[lbeachmike]

Jesse / Jeff - You are recommending a reformat/rebuild - however, with such a large volume of servers breached and the specific vulnerability unknown, how are you protecting yourself with a rebuild? We'd first have to know how to avoid the breach in order for a rebuild to not suffer from the very same vulnerability.

 

[lbeachmike]

Is there currently any benefit to reinstalling ssh or to turning off ssh in WHM's service manager until the source of the vulnerability and resolution is found?

 

[BianchiDude]

Is there currently any benefit to reinstalling ssh or to turning off ssh in WHM's service manager until the source of the vulnerability and resolution is found?

May be a good idea, however there is no evidence at this point its an SSH vulnerablity.

 

[BianchiDude]

Have you reported this IP to OVH? Or this is your IP?

On WHT they are saying that is an IP the hacker is using, its a cPanel server in Spain.

Web Hosting Talk - View Single Post - FEATURED SSHD Rootkit Rolling around

 

[biodocs]

If you follow the thread at SSHD Rootkit Rolling around - Page 21 - Web Hosting Talk you will find there is nothing solid on any thing yet still under investigation by many

 

[lbeachmike]

If you follow the thread at SSHD Rootkit Rolling around - Page 21 - Web Hosting Talk you will find there is nothing solid on any thing yet still under investigation by many

I've been following the thread. I did not want to post there because I don't want to disrupt the investigation efforts. However, my question here was whether or not turning off ssh entirely (on an already-infected box) would seem to serve any useful purpose? From the WHT point, I'm not perfectly clear on the point re: whether or not ssh must actually be active in order for the attacker behavior to be occurring. A few of the details are beyond my level of expertise.

Thanks.

 

[biodocs]

There are conflicting options on that subject, some say its only part of the issue. It getting way above my head i must say.

 

[TheVisitors]

I had a fresh copy of CentOS 6.3 updated with a fresh copy of cPanel current (updated), just installed yesterday.

Surprise!

Guess I'll need to wait for a fix on this.

 

[lbeachmike]

I had a fresh copy of CentOS 6.3 updated with a fresh copy of cPanel current (updated), just installed yesterday.

Surprise!

Guess I'll need to wait for a fix on this.

Saw your post there. Wondering if any boxes with SSH entirely disabled were vulnerable. Though it wouldn't prove anything, because they simply may not have been targeted. Though it's noteworthy that non-standard port SSH boxes were hit, which somewhat argues against the password authentication theory (which I believe was disproven either way.)

 

[biodocs]

Its seems this is not fixed with new install either glad i didnt take that option earlier.

see the whm thread i quote

Originally Posted by TheVisitors
Well doesn't it figure....

I install a fresh copy of CentOS 6.3 with cPanel current and in less than 2 hours.... BAM

I had changed Ssh ports and made a pass code over 400 letters, numbers, and symbols long.... Still got despite all this.

Little "tool" keeps changing my ssh log-in now. Can't turn it off, we need ssh.

 

[BianchiDude]

I've been following the thread. I did not want to post there because I don't want to disrupt the investigation efforts. However, my question here was whether or not turning off ssh entirely (on an already-infected box) would seem to serve any useful purpose? From the WHT point, I'm not perfectly clear on the point re: whether or not ssh must actually be active in order for the attacker behavior to be occurring. A few of the details are beyond my level of expertise.

Thanks.

It seems no, as they seem to be getting in, at least initially without SSH, but it hasn't been conclusively disproven that this is not an SSH exploit.

 

[Tam]

We haven't had any of our boxes compromised as detailed, but we lock down SSH...

disable password authorisation
use SSH keys
close port 22 allowing certain IP addresses only

 

[lbeachmike]

Although I realize this has been seen on non-cpanel boxes, I'm wondering if cPanel is using internal resources to investigate this as well, given the suggestion that it would seem cpanel has access to a lot of data points and resources which could prove extremely productive for this investigation.

Given the current line of thinking on the WHT thread, looking for correlation to possible a possible tainted RPM, I can't help but think about the fact that cPanel had recently converted to RPM-based install.

My system had complained about Munin's RPM on Jan 31, I did a YUM Update late Feb 1, and my changed file date on the hacked file is Feb 2 just about four hours thereafter.

I've posted more extensive details on the WHT thread.

SSHD Rootkit Rolling around - Page 28 - Web Hosting Talk

 

[nibb]

How about this?
Security Advisory SA52103 - cURL / libcURL "Curl_sasl_create_digest_md5_message()" Buffer Overflow Vulnerability - Secunia

curl uses libkeyutils

 

[BianchiDude]

How about this?
Security Advisory SA52103 - cURL / libcURL "Curl_sasl_create_digest_md5_message()" Buffer Overflow Vulnerability - Secunia

curl uses libkeyutils

Possible, what version of curl do you have?

 

[alex[nl]]

How about this?
Security Advisory SA52103 - cURL / libcURL "Curl_sasl_create_digest_md5_message()" Buffer Overflow Vulnerability - Secunia
curl uses libkeyutils

Affected versions: curl 7.26.0 to and including 7.28.1
Not affected versions: curl < 7.26.0 and >= 7.29.0

I only see 7.24.0 on my cPanel (VPS) Servers (CentOS 5.9), can it be that's the cPanel default?

 

[BianchiDude]

No I have a few different versions.

 

[lbeachmike]

No I have a few different versions.

My version shows as follows -

[email protected] [~]# curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Looks like I need to upgrade via EasyApache? Does anybody know what the current EasyApache version being installed is? This is odd, because I just did an EasyApache rebuild a couple days ago ...

 

[BianchiDude]

That exploit seems to be for the curl binary and not the curl module for php installed via easy apache.

There's not a PoC for it that I've found so its not likely that is MoE

 

[Tam]

Doubtful, on a compromised machine curl-7.19.7 was installed.