Is the part of the filesystem which handles links in kernel space or user space?
That would make a great deal of difference as this rootkit tool evolves. At the
moment it appears it is "contagious", meaning Linux installs can become
infected. Since the files that are infected are shared system library files it
suggests at least one route into root level privileges to make the install.
After that you have a root level user who does not appear in conventional checks
on /etc/passwd and directory listings. There is nothing that says this tool
cannot evolve more self-protection capabilities and still remain hiding in user
space, where it would normally not be expected to hang out. This would get
around some of the new secure BIOS protections that exist. It can keep the
original files around and let checksum utilities read it instead of the modified
files.
I figure with all malware the best thing to do is not catch it, use "safe
computing" with condoms like SELinux enabled and screwed down even tighter than
RHEL out of the box. I'm mostly musing about how it could be made more likely
for "the usual tools" to discover the hacking. (And as noted I am bemused
because this resembles several pieces of old Amiga malware.)
{^_^} Joanne
On 2016-09-07 19:03, Steven J. Yellin wrote:
Are rpm and the check sum tools statically linked? If not, hiding copies of
them might not help if libraries have been compromised. But busybox is
statically linked, and it looks like it can be easily used to replace most
commands used to check security without going to the trouble of pulling files
from it. For example, 'ln -s busybox md5sum' allows use of busybox's md5sum and
'ln -s busybox vi' allows use of its vi. See
https://busybox.net/FAQ.html#getting_started .
Steven Yellin
On Wed, 7 Sep 2016, [email protected] wrote:
Jdow,
Why are you looking at thatÿÿ for root kit prevention? It's a very old fashion
approach, I would use the RPM's verify command or one of the many filesystem
check sum tools available for that instead. Either one can tell you if ÿÿany
critical binaries or libraries have been compromised very easily and there are
even tools built around them to do it on a network wide level. Further more if
you really want to make your systems resistant to root kits, readonly mount of
/ and /usrÿÿ is still your best bet, even Red Hat products like RHEV use that
method on appliances.
Original Message
From: jdow
Sent: Wednesday, September 7, 2016 19:09
To: [email protected]
Subject: Re: Re: Regarding latest Linux level 3 rootkits
Thanks Vladimir,
I suppose I could pull the necessary files from busybox as a means of keeping a
more generic Linux system in security trim. This might be a useful tool set to
suggest upstream. A statically linked less would allow a quick check for the
hidden user. A statically linked chkrootkit would find the bad file size for the
affected glib libraries.
{^_^} Joanne
On 2016-09-07 03:36, Vladimir Mosgalin wrote:
Hi jdow!
ÿÿ
On 2016.09.06 at 23:15:04 -0700, jdow wrote next:
Is there any source for a VI, VIM, or even EMACS that has all libraries
compiled into it statically? That would make monitoring for the rootkit much
easier. The same could be said for utilities such as chkrootkit. With
compiled in static libraries these level three (user space) rootkits can't
edit the results you get, as easily. (Any file system components in user
space would also have to be statically linked.)
Busybox would work. It's usually build statically (either that, or it's
easy to make that kind of build) and includes vi clone. Very poor man's
vi, just like other busybox utilities, but nevertheless. Current version
supports some neat stuff like autoindent and undo.
