False positive for SucKit

[Lupe Christoph]

Binary package hint: chkrootkit

Searching for Suckit rootkit... Warning: /sbin/init INFECTED

According to http://cc.jlab.org/docs/security/alerts/ this is an indicator for a SucKit infection:

# ls -li /sbin/init /sbin/telinit
172240 -rwxr-xr-x 1 root root 199472 2009-10-15 21:19 /sbin/init
172791 -rwxr-xr-x 1 root root 96568 2009-10-15 21:19 /sbin/telinit

http://forums.gentoo.org/viewtopic-t-326062-highlight-suckit.html gives some hints how to verify an infection. As I expected, they show no sign of SucKit.

This false positive seems to be popping up since a few years. So I guess the check for SucKit needs improvement...

ProblemType: Bug
Architecture: amd64
Date: Sun Oct 18 12:42:45 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: fglrx
Package: chkrootkit 0.48-10
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-13.44-generic
SourcePackage: chkrootkit
Uname: Linux 2.6.31-13-generic x86_64

[Chuck Short (zulcss)]

Thanks for the bug report. I was wondering if you have any suggestion to improve it.

Thanks
chuck

[Lupe Christoph (lupe)]

On Monday, 2009-10-19 at 13:18:45 -0000, Chuck Short wrote:
> Thanks for the bug report. I was wondering if you have any suggestion to
> improve it.

Well, as there are some finer tests on the page I mentioned, what about
implementing them in chkrootkit?

Lupe Christoph
--
| There is no substitute for bad design except worse design. |
| /me |

[Chuck Short (zulcss)]

Thanks for the bug report. This will be looked at again for karmic+1.

Regards
chuck

[Ian MacGregor (ardchoille42)]

Confirmed in Karmic. I posted this to the Ubuntu forums and was referred this bug report.
My forums post is here:http://ubuntuforums.org/showthread.php?t=1386791

[Alex Muntada (alex.muntada)]

Just tried on latest karmic and it does not fail:

ii chkrootkit 0.48-10
ii upstart 0.6.3-11

$ ls -li /sbin/init /sbin/telinit
444149 -rwxr-xr-x 1 root root 169676 2009-12-10 17:19 /sbin/init
448912 -rwxr-xr-x 1 root root 79312 2009-12-10 17:19 /sbin/telinit

Can you please confirm that this is been solved?

[Lupe Christoph (lupe)]

I have seen this problem pop up a few times since I reported it and vanish again. Must be related to Phase of Moon. Right now it has disappeared:

Searching for Suckit rootkit... nothing found

chkrootkit:
  Installed: 0.48-10

The version of chkrootkit is still the same, only /sbin/init and /sbin/telinit have changed.

# ls -li /sbin/init /sbin/telinit
172201 -rwxr-xr-x 1 root root 199472 2009-12-10 18:00 /sbin/init
172637 -rwxr-xr-x 1 root root 96568 2009-12-10 18:00 /sbin/telinit

Looking at the code in chkrootkit, the difference is that /sbin/init does no longer contain the string "HOME". The changelog of the "upstart" package does not mention"HOME", so I can't tell if they fixed this intentionally. The only update since I created the bug report is 0.6.3-11, so this must have fixed it. The strange thing is that I see nothing in that update that would have deleted "HOME". http://launchpadlibrarian.net/36606433/upstart_0.6.3-10_0.6.3-11.diff.gz

I'd rather not rely on upstart taking care of problems in chkrootkit...

[Alex Muntada (alex.muntada)]

I don't think that chkrootkit alerting about this rootkit is related to upstart init changes, but the output from /proc/1/maps instead. Something like this should improve the test:

expertmode_output "${egrep} '^[^/]+${ROOTDIR}sbin/init.' ${ROOTDIR}proc/1/maps"

What do you think?

[Lupe Christoph (lupe)]

I'm pretty sure I saw the string "HOME" in /sbin/init, but I can't prove it anymore.

BTW, expertmode_output is just debugging:

expertmode_output() {
    echo "###"
    echo "### Output of: $1"
    echo "###"
    eval $1 2>&1
# cat <<EOF
#`$1 2>&1`
#EOF
    return 0
}

[Thierry Carrez (ttx)]

False positives with such tools come with the territory. Refused as a server papercut during 20100217 meeting.

[Chuck Short (zulcss)]

can you try to reproduce this on lucid please?

chuck

[Lupe Christoph (lupe)]

On Wednesday, 2010-04-28 at 18:09:39 -0000, Chuck Short wrote:
> can you try to reproduce this on lucid please?

Searching for Suckit rootkit... nothing found

I believe the false positive was gone for quite a while, probably due to
changes in init.

Lupe Christoph
--
| There is no substitute for bad design except worse design. |
| /me |

[Matt Eskes (matt.eskes-deactivatedaccount)]

I've got a reproduction here on a Lucid install.

Linux Neptune 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux

meskes@Neptune:/sbin$ sudo chkrootkit -V
chkrootkit version 0.49

Searching for Suckit rootkit... Warning: /sbin/init INFECTED

meskes@Neptune:/sbin$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.1 LTS
Release: 10.04
Codename: lucid
meskes@Neptune:/sbin$

------
Tried to include as much info about base software as possible. Tried the verification methods mentioned in the Gentoo doc and this system failed both, which is good since that means I have no infections. It also casts a false positive on Sun's Java as well as a few others which I will list here:
-------
Searching for suspicious files and dirs, it may take a while... The following suspicious files and directories were found:
/usr/lib/pymodules/python2.6/.path /usr/lib/firefox-3.6.8/.autoreg /usr/lib/jvm/.java-6-sun.jinfo /usr/lib/jvm/java-6-sun-1.6.0.20/.systemPrefs /usr/lib/xulrunner-1.9.2.8/.autoreg
-------

I know it doesn't matter all that much but I'm submitting since I can reproduce the event on Lucid and because Chuck asked for it so.. here is. If you guys would like any more info feel free to hit me up.

Matt

[Maxime (max-accadia)]

I can confirm the issue on Lucid. It's probably related to an upstart update to 0.6.5-7.

# lsb_release -d
Description: Ubuntu 10.04.1 LTS
# chkrootkit -V
chkrootkit version 0.49
# chkrootkit
[...]
Searching for Suckit rootkit... Warning: /sbin/init INFECTED
[...]

# strings /sbin/init | egrep HOME
# cat /proc/1/maps | egrep "init."
00e41000-00e5a000 r-xp 00000000 68:01 1572880 /sbin/init (deleted)
00e5a000-00e5b000 r--p 00019000 68:01 1572880 /sbin/init (deleted)
00e5b000-00e5c000 rw-p 0001a000 68:01 1572880 /sbin/init (deleted)

[moojix (moojix)]

i have exact the same behavior and output as Maxime wrote in #14.
This false positive happens on my box since 17.08.2010 after this update:

"Preparing to replace upstart 0.6.5-6 (using .../upstart_0.6.5-7_amd64.deb)"

[windracer (windracer)]

Same thing for me. After my Lucid box ran weekly updates I started seeing the "Searching for Suckit rootkit... Warning: /sbin/init INFECTED" message from chkrootkit.

[Lupe Christoph (lupe)]

On Thursday, 2010-08-19 at 08:02:45 -0000, Maxime wrote:
> I can confirm the issue on Lucid. It's probably related to an upstart
> update to 0.6.5-7.

> [...]
> Searching for Suckit rootkit... Warning: /sbin/init INFECTED
> [...]

> # strings /sbin/init | egrep HOME
> # cat /proc/1/maps | egrep "init."
> 00e41000-00e5a000 r-xp 00000000 68:01 1572880 /sbin/init (deleted)
> 00e5a000-00e5b000 r--p 00019000 68:01 1572880 /sbin/init (deleted)
> 00e5b000-00e5c000 rw-p 0001a000 68:01 1572880 /sbin/init (deleted)

I rechecked, and I get this, too:

# chkrootkit -q

Warning: /sbin/init INFECTED

Also the deleted /sbin/init. I rebooted the system, and now /sbin/init
isn't deleted anymore (surprise! ;-) and the INFECTED is gone, too.

So I suppose the cause of the INFECTED is that the running /sbin/init is
different from the one in the filesystem. Checking ... Jupp, here is the
line from chkrootkit:

      expertmode_output "cat ${ROOTDIR}proc/1/maps | ${egrep} init."

This triggers when there is an entry in /proc/1/maps where "init" is not
at the end of the line.

Googling, I found this was discussed for Gentoo in
http://forums.gentoo.org/viewtopic-t-326062-highlight-suckit.html
... and for Ubuntu in http://ubuntuforums.org/showthread.php?p=9741505

Alas, I could not find out what /proc/1/maps looks like when a real
Suckit is on the machine. Quite possibly Suckit removes /sbin/init and
links its own version there. If it dows this only once, the " (deleted)"
will disappear after the first reboot, so it's not a good indicator, and
it reaps many more false positives. So I think chkrootit would be
better off without this test.

Lupe Christoph

[Brownout (brownout)]

Confirmed on Maverick.

[Boyd Stephen Smith Jr. (bss03)]

+1 on Maverick after installing upstart 0.6.6-4 on 2011-02-11.

[Oliver (oliver-assarbad)]

Same here, also a falsepos (conclusion after doing the other usual tests for Suckit). The problem exists in Lucid Lynx:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.2 LTS
Release: 10.04
Codename: lucid

$ apt-cache show chkrootkit
Package: chkrootkit
Priority: optional
Section: misc
Installed-Size: 920
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Giuseppe Iuculano <email address hidden>
Architecture: amd64
Version: 0.49-3
Depends: libc6 (>= 2.7), debconf (>= 0.5) | debconf-2.0, binutils, net-tools, debconf, procps
Filename: pool/main/c/chkrootkit/chkrootkit_0.49-3_amd64.deb
Size: 339634
MD5sum: 9b369491740acda76ec586c535f5da98
SHA1: 1bf2e3f1738403aa07f682b82fea1db135ae0e09
SHA256: f0b970901ecc72494adbf6317df53a485c101f4a54311a6e3e1be838a57b859c
Description: rootkit detector
 The chkrootkit security scanner searches the local system for signs
 that it is infected with a 'rootkit'. Rootkits are set of programs
 and hacks designed to take control of a target machine by using known
 security flaws.
 .
 Types that chkrootkit can identify are listed on the project's home page.
 .
 Please note that where chkrootkit detects no intrusions, this does
 not guarantee that the system is uncompromised. In addition to
 running chkrootkit, more specific tests should always be performed.
Homepage: http://www.chkrootkit.org/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 5y

[Jay (cowb0y)]

For those similarly affected: I recently reinstalled the upstart package (0.6.5-8) on Lucid (10.04.4) and then received the Suckit [false] flag from chkrootkit 0.49-3 (as well as the version in Debian Wheezy (0.49-4.1)). After restarting the server, the flag disappeared. So, it appears to be sufficient that init is replaced on disk (even by the same version) to trigger the false positive, and that restarting the system will resolve it.

[Adam Funk (a-funk)]

This went away in 12.10 and reappared when I upgraded to 13.04.

[chrisfaron (chrisfaron)]

Yes same for me with a fresh install of 13.04 this bug still shows

[Jorik Jonker (jorik-kippendief)]

Problem still exists on 13.10 / amd64. I've dumped /sbin/init with debugfs, compared it with the one from the package and they are identical. /sbin/init seems to match 'HOME' and /proc/1/maps does not match 'init.'

[UBUCATZ (ubucatz)]

PROBLEM STILL EXISTS ON 14.04 LTS!!!

please either fix chkrootkit or change /sbin/init - I hope in a more security aware post snowden era this will now trigger some more action - certainly many users will be very irritated about this.

This does not happen on other distros. Must be fixed before release.

[Galen Thurber (godfree2)]

exits in
xubuntu 13.10 32bit
and you may get egrep not found error as well

[Sander (sander-p)]

In most major new distros (including redhat and ubuntu) "strings /sbin/init | grep HOME" returns:
XDG_CACHE_HOME
XDG_CONFIG_HOME

which still triggers an alert (false positive) for suckit rootkit in 14.04.

I checked the suckit source, and it gives:
sk2rc2$ strings ./src/sk | grep HOME
HOME=%s

So it means if we include = into the check, we will correctly detect it.

On line 1000 of chkrootkit it says:

   ### Suckit
   if [ -f ${ROOTDIR}sbin/init ]; then
      if [ "${QUIET}" != "t" ];then printn "Searching for Suckit rootkit... "; fi
      if [ ${SYSTEM} != "HP-UX" ] && ( ${strings} ${ROOTDIR}sbin/init | ${egrep} HOME || \
              cat ${ROOTDIR}/proc/1/maps | ${egrep} "init." ) >/dev/null 2>&1
        then
        echo "Warning: ${ROOTDIR}sbin/init INFECTED"

-----------
I sugest changing line 1003 from:
      if [ ${SYSTEM} != "HP-UX" ] && ( ${strings} ${ROOTDIR}sbin/init | ${egrep} HOME || \
to:
      if [ ${SYSTEM} != "HP-UX" ] && ( ${strings} ${ROOTDIR}sbin/init | ${egrep} 'HOME=' || \

and line 541 should also be changed from:
    expertmode_output="${strings} ${ROOTDIR}sbin/init | ${egrep HOME"
to
    expertmode_output="${strings} ${ROOTDIR}sbin/init | ${egrep 'HOME='"

[Sander (sander-p)]

heres a patch for it

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Chkroot suckit false positive fix" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[rpkrawczyk (rpkrawczyk)]

After an upgrade from 12.04 to 14.04 I got a scared with the message "suckit rootkit detected", too. rkhunter does not find anything. Here is the MD5SUM of my /sbin/init

c9b343f85e6804e2d7ee70b810b1a15a /sbin/init

which is the same as found in /var/lib/dpkg/info/upstart.md5sums.

[Adam Funk (a-funk)]

Just upgraded two machines to 14.04; one of them is still getting this.

I wonder why there is no option on Ubuntu's "and put your money where your mouth is" page for "fix known bugs instead of fiddling with the GUI".

[NiVeK (nivek1776)]

I also get this notice on 14.04 and Linux Mint 17(based on 14.04)

chkroothit -n
Searching for Suckit rootkit... Warning: /sbin/init INFECTED

[msth67 (msth67)]

Same here on Lubuntu 14.04 : on a new install chkrootkit reports Warning: /sbin/init INFECTED but then there's no evidence of this with repeated passes of unhide and rkhunter.
Apparently,also running chkrootkit -x and chkrootkit -x does not report the infection,as far as I can see.

[msth67 (msth67)]

Following comment #30,I've also verified the md5sum of my /sbin/init with the original package on http://packages.ubuntu.com/ and they do match.

[Madden (mrsexy)]

Confirmed still exists even in Linux Mint. No idea why Ubuntu has this problem. Maybe it's not a false positive? Who really knows.

[Madden (mrsexy)]

Alright did some checking for myself, I just went ahead and did the sha256sum checks on my own as well as hardlink check.

I've made a tutorial to check yourself
--------------------------
Testing with Sha256sum/md5sum
First we want to make a sha256sum or md5sum of the init in our system. To do this open terminal and...
# cd /sbin
# sha256sum init
You will get a long code, paste it into a text editor.
Next..
if you are using "trusty"
Go here: http://packages.ubuntu.com/trusty/upstart
if not go here
http://packages.ubuntu.com/search?keywords=upstart&searchon=names&suite=all&section=all
under "package upstart" find yours

Once on the package page...(Upstart)
go down to the bottom and click the download link for your architecture
once downloaded, right click on the .deb file and click extract here.

Now in the newly extracted folder we downloaded open it then open sbin folder, then in terminal type "sha256sum " and drag n drop init file there into terminal.

You will get yet another long code.

Go back into the text editor and paste that code below your previous one.
Do they match? Good! They don't? Make sure you downloaded the correct upstart. If you still do the hardlink below and it fails, then maybe a reinstall is needed.

Testing with hardlink
In terminal type
# cd /sbin
# ls -l init
Does it show 1? Good.
Now do this..
# ln /sbin/init /sbin/init2
# ls -l init
Does it STILL show 1?
It's infected if it still shows 1..
Do this afterwards to remove the file we just made(cleanup)
# rm init2
--------------
Good luck!

[Thomas Leavitt (u-tho4as-f)]

Current version of chkrootkit is 0.50, released on June 4th, 2014. Maybe we could get that version packaged up and backported?

[Rigved Rakshit (rigved)]

+1 to backporting chkrootkit 0.50.

[Thomas Mayer (thomas303)]

Fedora fixed it in FC21 with chkrootkit-0.50-4.fc2. https://bugzilla.redhat.com/show_bug.cgi?id=636231#c1

[Serge Hallyn (serge-hallyn)]

Looking at the patch applied in F21, it doesn't seem like Fedora actually fixed it. They simply check whether /sbin/init is a link to systemd, and ignore the report if so.

[Launchpad Janitor (janitor)]

This bug was fixed in the package chkrootkit - 0.50-3ubuntu1

---------------
chkrootkit (0.50-3ubuntu1) vivid; urgency=low

  * Merge from Debian unstable. (LP: #454566) Remaining changes:
    - debian/patches/fix-stack-smash.patch:
      + Fix segfault when running chkrootkit. (Closes: #767403)
 -- Artur Rona <email address hidden> Tue, 24 Mar 2015 00:52:06 +0100

[Philip Court (pccourt)]

Some comments on this as it looks like even the latest chkrootkit code (i.e. the one that is checking for 'HOME=') is still producing false positives on my machine which is running Ubuntu 15.04:

$ lsb_release -rdc
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid

I've confirmed it is a false positive using info here: https://forums.gentoo.org/viewtopic-t-326062-highlight-suckit.html, specifically by doing the following two tests:

1) The SucKIT rootkit allows an attacker to hide malicious files by giving them a particular ending. The current attacker is hiding code that ends in xrk or mem. To test for the presence of the rootkit, create a file whose name ends in xrk or mem, then execute an "ls -l". If the files you just created are not shown in the output of ls, it means that the rootkit is hiding them, ie. your system is compromised and needs to be rebuilt.

2) Change directories to /sbin and execute an "ls -l init" -- the link count should be 1. Create a hard link to init using ln, and then execute the "ls -l init" again. If the link count is still 1, the SK rootkit is installed.

Reading through this list of comments, the only relevant one I can see with respect to deactivating the false positive for my case is what serge-hallyn wrote (on 2014-12-16) re the Fedora "fix" (i.e. "They simply check whether /sbin/init is a link to systemd, and ignore the report if so.")

Not sure why a link to systemd should be a reason to ignore the report, but it would deactivate the false positive in my case...

FYI, I got my chkrootkit source from here: https://anonscm.debian.org/gitweb/?p=collab-maint/chkrootkit.git;a=snapshot;h=76f4907eb20be2af36cc87d16c25b6df27092d1c;sf=tgz

[Philip Court (pccourt)]

FYI, just to be explicit, here is the patch which has been applied in Fedora (I would suggest the same should be done here unless someone has a better idea):

diff -ru chkrootkit-0.50-orig/chkrootkit chkrootkit-0.50/chkrootkit
--- chkrootkit-0.50-orig/chkrootkit 2014-05-21 12:28:56.000000000 +0100
+++ chkrootkit-0.50/chkrootkit 2014-10-03 16:06:48.000000000 +0100
@@ -989,7 +989,14 @@
       if [ ${SYSTEM} != "HP-UX" ] && ( ${strings} ${ROOTDIR}sbin/init | ${egrep} 'HOME=' || \
        cat ${ROOTDIR}/proc/1/maps | ${egrep} "init." ) >/dev/null 2>&1
         then
- echo "Warning: ${ROOTDIR}sbin/init INFECTED"
+ #echo "Warning: ${ROOTDIR}sbin/init INFECTED"
+ # ignore false positive (bugzilla #636231)
+ readlink -f ${ROOTDIR}sbin/init|${egrep} -q /systemd$
+ if [ $? -eq 0 ]; then
+ if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
+ else
+ echo "Warning: ${ROOTDIR}sbin/init INFECTED"
+ fi
       else
          if [ -d ${ROOTDIR}/dev/.golf ]; then
             echo "Warning: Suspect directory ${ROOTDIR}dev/.golf"