LinuxQuestions.org - True Suckit infection NOT false positive in chkrootkit

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - True Suckit infection NOT false positive in chkrootkit (https://www.linuxquestions.org/questions/linux-security-4/true-suckit-infection-not-false-positive-in-chkrootkit-4175472841/)

tbh, I thought anything but, only delt with the all but the mbr, sorry, my bad! (I'll look it up later, unless you hav a link)

Quite right about the reply and spec.

Intrigued by unSpawn's comment that chkrootkit was old, I tried it on my Fedora Rawhide distribution (because that's what I am on right now), and, sure enough, I was told the /sbin/init was infected by suckIT.

On Fedora systems, and several other recent distributions, /sbin/init is just a symbolic link to /lib/systemd/systemd.

The "test" for a SuckIT infection of /sbin/init in the chkrootkit script is:

Code:

  ### 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"

      else

        if [ -d ${ROOTDIR}/dev/.golf ]; then

            echo "Warning: Suspect directory ${ROOTDIR}dev/.golf"

        else

            if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi

        fi

      fi

  fi

and (since systemd generates several scripts) we have:

Code:

$ strings /sbin/init | grep HOME

HOME=%s

XDG_CONFIG_HOME

XDG_DATA_HOME

So that test, on any system using systemd with init symlinked to it, will report a SuckIT infection of init.

<edit>
See my comment #21, below, about the basis of the suckit exploit.
</edit>

Quote:

Originally Posted by PTrenholme (Post 5015157)

So that test, on any system using systemd with init symlinked to it, will report a SuckIT infection of init.

Thanks for clearing that up! I'll use your explanation as reference. Plus it kind of confirms RKH made the right choice back then not to grep for a single string...

Unspawn

Thanks for the reply. I believe this machine was infected when I unwittingly moved infected files from Win7 partition to linux one. Hence the re-emergence. I don't think it was a new infection.

I ran chkrootkit using Kali DVD as it was on the Kali DVD but unfortunately rkhunter was not. I wanted to see if changes happened when I booted linux partition or when I went on the internet from a fresh install. rkhunter reported nothing of interest when I later installed it. I did not make things very clear I'm afraid in my original post. When looked at from a live DVD files like pagefile.sys hyperfil.sys in Win7 would become executable when an infection was present. I may be a bit hypervigilant about Suckit.

I'm sorry I can't provide evidence, but it was happenstance, so just speculation. I don't want to try to reinfect this laptop! One thing I did differently this time round was encrypt the whole hard drive not just the home directory, after a fresh zeroing and reinstall. I did this TWICE. The encryption x 2 may have gotten rid of a Suckit encrypted binary. Some of the changes I find when an infection is present may just be peculiar to me eg: caps inversion, change from non-exe to .exe files in Windows, as the person I suspect is a programmer and contributes to Xubuntu.

Sorry for inconveniencing people, I just was trying to understand what had happened. But on this machine now it is all speculative. I'll try to run the tests requiring a reboot, but this machine is only working because of the overheating trick.

Noway2. This was on a basic reinstall, no wireshark or snort installed. Unsure about TCP dump.

Hey GlennsPref, another "Aussie", I also am living in Brisbane.

This is an ongoing saga as Unspawn knows. I could kick myself several times over this. I believe I unwillingly infected this beast from infected data on Win7. When I was using Win7 it was 'jailed' but when data copied to a linux partition => evil happens. Now I don't think it is infected as zeroing and more importantly encryption several times appears to have exorcised it.

I posted in an effort to find out if anything new had happened, such as a newer kernel or kernel patch that got rid of it. Just speculating at this stage, but after reading the above article, I think the encryption done at least twice got rid of the Suckit encrypted binary from where ever it was lurking on the hard drive. I can't provide evidence of infection on this machine as it appears to have been accidentally exorcised!

So hopefully now all this is behind me! Thanks again for the input everyone.

Quote:

Originally Posted by mazinoz (Post 5015229)

Sorry for inconveniencing people, I just was trying to understand what had happened. But on this machine now it is all speculative.

I suggest you print the last 3 or 4 threads and keep them with your computer. Next time you think something is amiss first notify us, post output of whatever is asked for and wait for a reply from somebody who has intimate knowledge of things. Lessons learned (or so I'd hope) and case closed.

Still intrigued by the suckit rootkit, I looked at the description of the exploit in Phack Magazine. The exploit relies on writing to /dev/kmem as "root" and, as far as I can see, the 3.11.0 kernel (as compiled by the Fedora team) does not have that block device. So, even if the infection by was "real," I'm not sure that it would be able to do anything.

I'm not intrigued enough to find a live suckit to analyze, but I wonder if any real infection has occurred since /dev/kmem was removed from the default /dev list.

Oh, I also wonder about the O.P.'s assertion that his infection was real with a vector from a Win 7 system, making *.exe files executable on his Linux system.:scratch: AFAIK, the only way to run a Windows executable file is by using wine or qemu. Clearly a raw Windows executable (or script, for that matter) is extremely unlikely to execute on a Linux system, and, if by chance, it did run, it would be even less likely to run correctly.

Quote:

Originally Posted by PTrenholme (Post 5015332)

(..) as far as I can see, the 3.11.0 kernel (as compiled by the Fedora team) does not have that block device. So, even if the infection by was "real," I'm not sure that it would be able to do anything.

Red Hat compiled kernels w/o /dev/kmem since 2004 / 2005 and the kernel devs /dev/kmem was phased out somewhere around 2008 / 2009. Not being able to write to /dev/kmem closed one avenue but did not make unwanted memory ops impossible.

Quote:

Originally Posted by PTrenholme (Post 5015332)

(..) I wonder if any real infection has occurred (..)

In the Linux Security forum we often tell members we work with facts and not fiction. Unfortunately that means a failure to share evidence only leads to speculation...

PTrnholme
I did not say that windows files were the linux rootkit, just a symptom of activity by this particular hacker. The rootkit was present on linux only installs. I nevertried to run them from linux, as I hadenough problems already! pagefil.sys wasmade executable. Sorry for any confusion.

Quote:

Originally Posted by mazinoz (Post 5012212)

Since posting I've found out using www.grc.com Optus in Oz no longer do reverse DNS. I suspect this makes it harder for hacker to brute force my computer. But I really don't know.

Nothing to do with the thread but thanks for posting the hint of GRC, you switch light on.
I'm under MITM attacks 24/7

Financial mafia is scared of a little David I safe the system but they are still able to cause emergency shutdown overheating CPU.

Btw. Stay far away from stock market they are already crashed.