OSSEC says "Suckit" rootkit possibly detected
 

Hi,
I am running Ubuntu 9.10 desktop on a Dell Inspiron E1505. OSSEC is hitting on a possibly trojaned file. The alert is:

I ran RKhunter and it said it did not detect "Suckit" rootkit, but it is hitting on a similar file (sbin/init) and some others. Then I ran ChkRootkit and it did detect "Suckit" rootkit. I can't find ChkRootkit's logs at this time though. /var/log/chkrootkit is empty.

So does anyone have any ideas as to whether I can confirm that there is or is not an infection? And if there is an infection, how can I remedy this problem?

I got it fixed. I just backed everything up and did a clean re-install. It seemed like the only way to make sure the job really got done right.

I kind of doubt it...
 

Shame you're just telling stuff instead of posting the Rootkit Hunter version and actual log and file details that could help us help you (at all, better).


Chkrootkit logs to stdout by default.


Quite a few things actually:

* Read The Signs
- An attack will often be preceded by reconnaissance. This means that reading logs and filtering for signs of potentially malicious network activity serves as an Early Warning system. Add passive and active response capabilities like `man hosts_access`, iptables, Snort (+Guardian?), Denyhosts, Fail2ban, mod_security, OSSEC-HIDS, et cetera provide (that's an AND'ed choice not OR'ed), a passive logfile reader like Logwatch or Swatch, an active filesystem integrity scanner like Samhain or a passive one like Aide (or maybe even tripwire), reading alerts and and acting on anomalies can help avoid more attacks or alert you an investigation is necessary.

* Rootkits in general
- In general rootkit infections have dropped dramatically over the past years. As far as I can see they're becoming pretty rare. That said False Positives, especially for Suck-IT, I think would be equally rare due to what sk-1.3 and 2.x subvert.

* Suck-IT specific
- The link count of the /sbin/init binary,
- Files with a '.xrk' or '.mem' suffix could "disappear" meaning it's active,
- Common installed files like /sbin/initsk12, /sbin/initxrk, /usr/share/locale/sk/.sk12/sk,
- If it was built on the box (depending on version) also a sniffer file, install script and login binary,
- Strings in the login and init binary,
- The 'skdet' binary finding a hidden process,


The only way to do the job right would be making certain that re-installation (and restoring anything from backup without inspection) does not re-introduce the same vulnerability that allowed the cracker to abuse the machine in the first place. There's actually quite a few thing you should do to harden a new installation. Please list the measure you took and then feel free to ask for comments.

Rgr, I will remember to include software versions next time. It was OSSEC HIDS 2.2, Rkhunter 1.3.4-5, and Chkrootkit 0.48-10. Rkhunter and Chkrootkit were both downloaded and installed via Synaptic. The only reason I didn't include the Rkhunter logs was because they seemed so ambiguous; it was hitting on similar files as suspicious, but then it said definitively that SuckIT was not detected. In any case I will include these next time.

The first thing I did was just saving stuff to a CD-RW; documents, pdf's, pictures, videos, MP3's, etc. I got into the habit of routinely backing stuff up anyway so this was not a problem.

The second thing was the re-installation using the Ubuntu 9.10 disc. Integrity of the ISO was verified before it was burned. Then I did a clean re-install from scratch, completely reformatting the entire HDD, just as if I was blowing away the stock Windows installation.

As for possibly re-introducing the vulnerability/exploit, I have been extra careful with anything I put on the computer since the re-install. Where possible, signatures, MD5 and/or SHA1 hashes and sums have been verified, and each new file gets virus-scanned with ClamAV and Avast. However I have not yet imported any of the backed-up material onto the system; most of it isn't very important anyway.

Aside from that, if it was not a false positive, I'm completely at a loss as to how I could have stumbled across a malicious Linux rootkit. I never run anything as root unless the software in question is essentially required by the operating system and needs such privileges to function. I only download software from the repositories, the only exception being OSSEC, and I make use of the hashes and signatures they provide. And for the most part, I don't download random files or code that cannot be verified as legitimate, the only (very rare) exceptions being a video or MP3 file.

Thank you for your response! Any further criticisms or comments are welcome!

Detection capabilities may change between SW versions. OSSEC currently is at 2.3, Chkrootkit is 0.49 and RKH is at 1.3.6. Logs can show us clues or false positives to check. With most things security-wise you'll want to read logs (and well in advance of serious trouble so you have time to respond) and in some cases run tests from a Live or rescue CD to bypass manipulation.


Backing up stuff is always good (OK, as long as you have independent means of verifying the integrity of what you store.)


Still you might want to have a look at your firewall policies and other access controls. Reading ubuntuforums it seems some get caught by (unknowingly) allowing remote VNC-ish connections. I don't know if that's enabled by default on a desktop installation BTW as I only have on headless server install.


I'm not saying it was a rootkit. The problem is that without "evidence" there is no way to tell if it was a false positive or not...

I really like OSSEC and Rkhunter so much because they email their logs to you. It just makes things so much easier to have "one-stop shopping" when performing routine maintenance activity, especially given time constraints, other demands, etc. However I don't actually mind reading the logs themselves. They have not only helped me learn more about my system and Linux in general, but have helped me tell the difference between the "normal" activity and the suspicious activity.

Will do. But I'm not completely sure of how to check the firewall thoroughly. I ran "sudo ufw status verbose" and got the following:

I also ran "lsof -i" and didn't see anything strange (Empathy had the only active connections). As for VNC, I am not sure what that is yet, but Gnome's Remote Desktop server was enabled on startup, and I think I disabled that (went into the list of apps that launch on startup and removed it). I'll do some research on VNC but it does not appear to be an issue at this point. Do you have any other recommendations? Thanks again!

I wish more people could say that. Until they do we'll still see peoples machines getting compromised and the admins doing nothing while recon started months ago...


In terms of policies that looks good for a workstation (e.g. not providing any services). Running 'echo -en "raw\nfilter" | sudo xargs -iX /sbin/iptables -n -L -t 'X';' should produce a more complete list of iptables rules to look at.


That's what I meant! I think.


Good!


No, not really: you already make backups, you already restrict access to your machine and you regularly audit it.