Re: Regarding latest Linux level 3 rootkits

[Paul Robert Marino]

This thread raises some interesting point but I've seen a few
misconceptions in it too

first let me clear up the misconceptions.
1) busy box is meant to make the footprint on an appliance or live
"CD" type distro smaller it is not for security. Rootkits that replace
busy box have been seen in the wild on appliances in the past, so its
not necessarily a good answer to prevent rootkits.
2) you really don't need root to be writable in production on any
system as long as you've laid out your logical volume or partitions
correctly and just add a few simple operational procedures when you
update or modify configuration files. As far as updates go you can
still do it by remounting (mount -O remount) the filesystem as read
write first,run your updates, then remount again as read only. I've
been doing this on secure systems for over 20 years and its quite
effective in preventing about 40% of root kits from infecting a
system. In fact in the cloud you should make your instances as
stateless and read only as possible. you do this by only doing updates
on the VM you use to create your image and not the production VM's
instead you should just replace them when you are ready to update this
works well with thing like AWS autoscaling and other similar
solutions. in reality on most systems only /var, /tmp (preferably
tmpfs), and maybe /home need to be writable in production.
3) SELinux secures system processed but not user executed commands for
that you need apparmor which is not implemented in RHEL yet.

now some suggestions
A simple solution for file integrity checking is AIDE
https://sourceforge.net/projects/aide/ there has been an RPM included
in all versions of RHEL and Fedora since the first versions.
If you want a better more enhanced rootkit protection look at Samhain
http://la-samhna.de/samhain/ here is a SANS article from a couple of
years ago which can walk you through the install
https://www.sans.org/reading-room/whitepapers/detection/samhain-host-based-intrusion-detection-file-integrity-monitoring-34567
If you want to get really into it look at OSEC but be warned I've
found OSEC has issues with the cloud specifically when autoscaling is
involved because its very difficult to remove retired instances .

In the cloud I have found simpler solutions like using AIDE work well
because you don't need to register and unregister instances, also you
can precreate the database on the VM you use to create the image so no
post launch scripts need to be added to cloudinit.
That said I haven't tried it yet in the cloud yet but I think Samhain
may have some potential in the cloud but the implementation of it for
the cloud would need a lot more forethought then a standard install.

On a side note effecting the load order of libraries is not a new
method for rootkits, and many of them have been know to install
themselves in users home directories and modifying the users profile
and or bashrc.
Also i know it hasnt been updated in a long time but if you want to
know more about securing a Linux box I highly suggest you take a look
at what Bastille Linux does  http://bastille-linux.sourceforge.net/
even though its out of date (looking for config file in the wrong
place or expecting an old syntax) a lot of the base concepts of what
it did are correct and very good to do if you want to secure a system.

On Thu, Sep 8, 2016 at 6:44 AM, Vladimir Mosgalin
 wrote:
> Hi Steven J. Yellin!
>
>  On 2016.09.07 at 19:03:32 -0700, Steven J. Yellin wrote next:
>
>> 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 .
>
> Statically linked rpm won't help you at all. This malware in question
> doesn't modify any system files or libraries, it installs new (non
> system-managed) library and creates extra config file for linker, it has
> random name and is treated as non system-managed as well. This library
> preloads itself for any non-statically linked binary and replaces libc
> functions.
>
> rpm has absolutely nothing to do with non-system files, you can do as
> many verify passes as you want, using statically linked rpm binary if
> you prefer, and it won't show you that anything is wrong.
>
> --
>
> Vladimir

Re: Regarding latest Linux level 3 rootkits

[Vladimir Mosgalin]

Hi Steven J. Yellin!

 On 2016.09.07 at 19:03:32 -0700, Steven J. Yellin wrote next:

> 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 .

Statically linked rpm won't help you at all. This malware in question
doesn't modify any system files or libraries, it installs new (non
system-managed) library and creates extra config file for linker, it has
random name and is treated as non system-managed as well. This library
preloads itself for any non-statically linked binary and replaces libc
functions.

rpm has absolutely nothing to do with non-system files, you can do as
many verify passes as you want, using statically linked rpm binary if
you prefer, and it won't show you that anything is wrong.

-- 

Vladimir

Re: Regarding latest Linux level 3 rootkits

[Vladimir Mosgalin]

Hi jdow!

 On 2016.09.07 at 19:18:32 -0700, jdow wrote next:

> 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

In kernel (except for soft links, for them it's partially in user space,
kind of, application can check where it's linked to and is free to
ignore such link; if it doesn't do that, then still in kernel)

> 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.)

Well this is one of the reasons why modern approaches such as atomic
host (http://www.projectatomic.io/ - there is corresponding RHEL version
as well) have appeared. With these technologies, host system updates
completely in a single step from one state to another, and all your
applications run in docker containers, it's impossible for such
infection to spread from one into another, so only a single application
would be affected. And - if you write your dockerfiles properly - all
the system files in every container are immune to changes and additions,
ie you can change it if you got privileges, but when you restart
container for that application, all the changes would be reset.

That said, since not many use this technology yet, I suspect that
malware that explicitly targets its users might appear in the future, if
it is to become popular. Obviously it looks secure and everything, but
such major redesigns usually present some oversight which might be
exploited once people discover it. Which is possible in the future, at
least in theory. Still, it looks very secure against conventional
malware and root kits and everything.

-- 

Vladimir

Re: Regarding latest Linux level 3 rootkits

[jdow]

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, prmari...@gmail.com 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: scientific-linux-users@fnal.gov
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.

Re: Regarding latest Linux level 3 rootkits

[Steven J. Yellin]

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, prmari...@gmail.com 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: scientific-linux-users@fnal.gov
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.

Re: Re: Regarding latest Linux level 3 rootkits

[jdow]

Very simple.

This rootkit works in user space by coopting glib. The new versions tell the 
user what the rootkit wants it to use. It creates a new user. This user has an 
exception to the /etc/passwd etc rewrites on the way to the application from the 
disk. The files involved do not show up in file requests.


Since the rootkit is in user space files that are statically linked with all the 
user space libraries will be unaffected. Note that rpm is not such a file. So it 
gets told what the modified glibc tells it. How can it detect the rootkit with 
that happening?


I simply mentioned chkrootkit as an example of a tool that would not be able to 
do its job properly unless it was statically linked. I was not advocating it. I 
just want to see if there is a real way around this infection.


The readonly mount option is not suitable in the face of updates. And SELinux, 
if it is full on, should prevent this problem. However, I have yet to get a 
fully configured machine that does not throw SELinux problems. Fully configured 
in this context means local DNS service, local DHCP service for dozens of 
devices, ntp service, samba running with user directories available, 
spamassassin running, very restricted smtp, and little else. By the time I get 
through Samba, DNS, and DHCP I am getting occasional SELinux problems with 
rather spurious seeming troubleshooting reports. It appears, at the moment, 7.2 
may be a little nicer in this regard than 6.8 and 6.8 is nicer than earlier 
versions of 6.


One thing that kills me on this "new" rootkit is that I first ran across it in 
the late 80s on Commodore Amigas. And it is STILL not completely addressed, or 
so it appears.


{o.o}   Joanne


On 2016-09-07 18:22, prmari...@gmail.com 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: scientific-linux-users@fnal.gov
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.

Re: Regarding latest Linux level 3 rootkits

[prmarino1]

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: scientific-linux-users@fnal.gov
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.
>

Re: Re: Regarding latest Linux level 3 rootkits

[jdow]

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.

Re: Regarding latest Linux level 3 rootkits

[Vladimir Mosgalin]

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.

-- 

Vladimir

Regarding latest Linux level 3 rootkits

[jdow]

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.)


{^_^}   Joanne