Linux Debian support

Author

chkrootkit

ArameFarpado

2006-09-17, 1:13 am

Hi... got debian sid here.

i got this warning from chkrootkit

Warning: Possible Showtee Rootkit installed
/usr/lib/security
/usr/lib/security/classpath.security

i've look into this classpath.security and it is just a text file like a
conf file.

rkhunter does not detect any thread or weakness.

This is a false positive warning, right ?

regards
ArameFarpado

Moe Trin

2006-09-17, 7:15 pm

On Sun, 17 Sep 2006, in the Usenet newsgroup alt.os.linux.debian, in article
<450ca5fc$0$75032$14726298@news.sunsite.dk>, ArameFarpado wrote:

>i got this warning from chkrootkit
>
>Warning: Possible Showtee Rootkit installed

According to http://www.chkrootkit.org/, the latest version of this windoze
wannabe tool is

chkrootkit 0.46a is now available! (Release Date: Fri Oct 28 2005) This
version includes:

and this warning comes out of the chkrootkit script (WATCH THE LINE WRAP HERE):

-----------------------------
### Showtee
if [ "${QUIET}" != "t" ];then printn "Searching for Showtee... "; fi
if [ -d ${ROOTDIR}usr/lib/.egcs ] || [ -f ${ROOTDIR}usr/lib/libfl.so ] || \
[ -d ${ROOTDIR}usr/lib/.kinetic ] || [ -d ${ROOTDIR}usr/lib/.wormie ] || \
[ -f ${ROOTDIR}usr/lib/liblog.o ] || [ -f ${ROOTDIR}usr/include/addr.h ]
|| \
[ -f ${ROOTDIR}usr/include/cron.h ] || [ -f ${ROOTDIR}usr/include/file.h
] || \
[ -f ${ROOTDIR}usr/include/proc.h ] || [ -f
${ROOTDIR}usr/include/syslogs.h ] || \
[ -f ${ROOTDIR}usr/include/chk.h ]; then
echo "Warning: Possible Showtee Rootkit installed"
else
if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
fi
-----------------------------

so if one of those file or directory names (unless you used the -r option,
"${ROOTDIR}" is '/'), exists, chkrootkit thinks you are infected with this or
that worm or rootkit or what-ever. The real question is, what are you doing
with your system? Is it reasonable that you could have "gotten infected", or
did one of those files/directories appear for some other reason?

Personally, I find these kinds of rootkit detectors virtually useless. If
the root kit author wants to evade detection, changing a filename is all
that is needed. The similar rkunter suffers the same problem. There is
a third one "Zeppoo" (http://www.zeppoo.net) which is relatively new
(zeppoo-0.0.3d.tar.gz is dated June 18, 2006), and so far I haven't seen
any useful feedback. It claims to detect rootkits on the i386 architecture
under Linux by using /dev/kmem and /dev/memm but only works on 2.6.x kernels.
It looks _very_ beta at best.

>This is a false positive warning, right ?

Hard to say - doing a google search on 'Showtee' seems to uncover very
little useful information.

Old guy

ArameFarpado

2006-09-17, 7:15 pm

Moe Trin wrote:

> According to http://www.chkrootkit.org/, the latest version of this
> windoze wannabe tool is
>
> chkrootkit 0.46a is now available! (Release Date: Fri Oct 28 2005) This
> version includes:
Correct, this is the chkrootkit version at the time on Sid.

> and this warning comes out of the chkrootkit script (WATCH THE LINE WRAP
> HERE):
>
> -----------------------------
> ### Showtee
> if [ "${QUIET}" != "t" ];then printn "Searching for Showtee... "; fi
> if [ -d ${ROOTDIR}usr/lib/.egcs ] || [ -f ${ROOTDIR}usr/lib/libfl.so ]
> || \
> [ -d ${ROOTDIR}usr/lib/.kinetic ] || [ -d ${ROOTDIR}usr/lib/.wormie
> [ ] || \ -f ${ROOTDIR}usr/lib/liblog.o ] || [ -f
> [ ${ROOTDIR}usr/include/addr.h ]
> || \
> [ -f ${ROOTDIR}usr/include/cron.h ] || [ -f
> [ ${ROOTDIR}usr/include/file.h
> ] || \
> [ -f ${ROOTDIR}usr/include/proc.h ] || [ -f
> ${ROOTDIR}usr/include/syslogs.h ] || \
> [ -f ${ROOTDIR}usr/include/chk.h ]; then
> echo "Warning: Possible Showtee Rootkit installed"
> else
> if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
> fi
only /usr/lib/libfl.so is in my system

> so if one of those file or directory names (unless you used the -r option,
> "${ROOTDIR}" is '/'), exists, chkrootkit thinks you are infected with this
> or
> that worm or rootkit or what-ever.
I'm not really good reading this C scripts, so any one of these files will
trigger the alarm right?

/usr/lib/libfl.so is installed by the "flex" package and it is debian
genuine

> The real question is, what are you
> doing with your system? Is it reasonable that you could have "gotten
> infected", or did one of those files/directories appear for some other
> reason?
No, don't think so... i'm firewalled, only have client configurations for
internet... have a few servers running but only for home network (nfs,
bind, nat), iptables is blocking these protocols for internet...

> Personally, I find these kinds of rootkit detectors virtually useless. If
> the root kit author wants to evade detection, changing a filename is all
> that is needed. The similar rkunter suffers the same problem. There is
> a third one "Zeppoo" (http://www.zeppoo.net) which is relatively new
> (zeppoo-0.0.3d.tar.gz is dated June 18, 2006), and so far I haven't seen
> any useful feedback. It claims to detect rootkits on the i386 architecture
> under Linux by using /dev/kmem and /dev/memm but only works on 2.6.x
> kernels. It looks _very_ beta at best.
yeap, if it just teste if a filename is there and don't test its contents,
then the scanning is more them probably to give false positives

>
> Hard to say - doing a google search on 'Showtee' seems to uncover very
> little useful information.
Yeah, i've been doing some searching too, and can't find anything really
conclusive... i've been doing some checkings and i'm quite sure this is
another chkrootkit false alarm ;)

Anyway, there is very little information about "how do rootkits get
installed", seems to me that they don't "spread" and must be installed
almost by hand in each system, maybe in pre-infected packages... do you
share my opinion?

Thanks
ArameFarpado

Moe Trin

2006-09-19, 1:18 am

On Mon, 18 Sep 2006, in the Usenet newsgroup alt.os.linux.debian, in article
<450de1b5$0$75034$14726298@news.sunsite.dk>, ArameFarpado wrote:

>Moe Trin wrote:

[vbcol=seagreen]
>I'm not really good reading this C scripts

-----
#! /bin/sh
# -*- Shell-script -*-
# $Id: chkrootkit, v 0.46 2005/10/26
CHKROOTKIT_VERSION='0.46'
# Authors: Nelson Murilo <nelson@pangeia.com.br> (main author) and
# Klaus Steding-Jessen <jessen@cert.br>
-----

actually, it's a Bourne shell script, and you may want to send a mail to
those guys giving then yet another 'heads up' about a false alarm.

>so any one of these files will trigger the alarm right?

Yes - see the "Bash-Prog-Intro-HOWTO" (last revised in July 2000) and/or
The Grendel's outstanding "Advanced Bash Scripting Guide" from the Linux
Documentation Project (http://tldp.org/guides.html). Briefly, the script is
looking for the existence of the name - not the contents. Try

[compton ~]$ help [
[: [ arg... ]
This is a synonym for the "test" shell builtin, excepting that the
last argument must be literally `]', to match the `[' which invoked
the test.
[compton ~]$

and then try 'help test'. The twin pipes ("||") is a logical OR, so it
tests for the existence of a directory named /usr/lib/.egcs - if that isn't
found, look for the file /usr/lib/libfl.so, and so on.

[vbcol=seagreen]
>No, don't think so... i'm firewalled, only have client configurations for
>internet... have a few servers running but only for home network (nfs,
>bind, nat), iptables is blocking these protocols for internet...

The other test is that you are not running internet applications like
Java enabled web browsers as root.

>yeap, if it just teste if a filename is there and don't test its contents,
>then the scanning is more them probably to give false positives

That's it. The other problem is that some of the testing is unbelievably
out of date. It's still looking for the 'Ramen' worm (which targeted
an out-of-box Red Hat 6.2 from 2000, and the 'Adore' worm that targeted
Red Hat 7.0, also from 2000). I don't know of anyone still running those
ancient distributions.

>Yeah, i've been doing some searching too, and can't find anything really
>conclusive... i've been doing some checkings and i'm quite sure this is
>another chkrootkit false alarm ;)

Another concept I don't like is that the "tool" uses grep (normally egrep)
searching for text strings - such as

if `${egrep} -i adore < /proc/ksyms >/dev/null 2>&1`; then
echo "Warning: Adore LKM installed"
fi

so if those five characters are anywhere in /proc/ksyms, including in the
word "Labradorean"...

>Anyway, there is very little information about "how do rootkits get
>installed", seems to me that they don't "spread" and must be installed
>almost by hand in each system, maybe in pre-infected packages...

Even that is difficult. In November 2004, someone tried sending errata
information to install a fake update appeared to contain malicious code.
The false domain was registered on a Sunday in Melbourne, but warnings
were being published in Usenet (as well as several on-line magazines) on
Saturday (actually, the same day due to time zones) in North America.
(Details: google for "Subject: Blackhats Target RH/Fedora" in the group
comp.os.linux.misc, around 25 October 2004.) There was a similar attempt
to sneak some mal-ware into one of the debian.org servers last year or so,
but I don't have the cite handy. It too was detected within hours at the
outside.

Don't get me wrong - rootkits do get installed through many possible venues.
Above, I mention the 'adore' and 'Ramen' worms. These were attacking some
vulnerabilities in distribution packages that had been patched as much as
seven months before the worms appeared. And Linux isn't alone in this. From
CERT Summary CS-98.06 (Jun 1998):

3. Root Compromises

We continue to receive daily reports of sites that have suffered a
root compromise. Many of these compromises can be traced to systems
that are unpatched or misconfigured, which the intruders exploit
using well-known vulnerabilities for which CERT advisories have
been published.

We encourage you to check for signs of compromise. The following
documents can help you review your systems:

Can you detect the dissatisfaction in the author's mind? "We've warned
you about this, and _still_ you were caught unprotected."

One thing that is seen more often now is the result of people grabbing
tarballs from a dubious source and installing them - even though the same
(or similar) application is available on your distribution CDs if only
one would look there. Packages supplied by your distribution are much
less likely to be a problem, because a lot more creditable eyes are looking
at the package. It's also less likely to have dependency problems.

Old guy

ArameFarpado

2006-09-21, 7:14 pm

Moe Trin wrote:

> Yes - see the "Bash-Prog-Intro-HOWTO" (last revised in July 2000) and/or
> The Grendel's outstanding "Advanced Bash Scripting Guide" from the Linux
> Documentation Project (http://tldp.org/guides.html). Briefly, the script
> is
> looking for the existence of the name - not the contents. Try
>
> [compton ~]$ help [
> [: [ arg... ]
> This is a synonym for the "test" shell builtin, excepting that the
> last argument must be literally `]', to match the `[' which invoked
> the test.
> [compton ~]$
>
> and then try 'help test'. The twin pipes ("||") is a logical OR, so it
> tests for the existence of a directory named /usr/lib/.egcs - if that
> isn't found, look for the file /usr/lib/libfl.so, and so on.
Ok, since i can only program in Basic ;)
i can now understand the "||"

> The other test is that you are not running internet applications like
> Java enabled web browsers as root.
Nope... here root only runs the package manager and configuration tools...
root doesn't know how to use "user" programs, his a kind of a "dumb" root

> That's it. The other problem is that some of the testing is unbelievably
> out of date. It's still looking for the 'Ramen' worm (which targeted
> an out-of-box Red Hat 6.2 from 2000, and the 'Adore' worm that targeted
> Red Hat 7.0, also from 2000). I don't know of anyone still running those
> ancient distributions.
And i also have clamav installed, i believe clamav that even
detects "phishing bank" mails would detect a unix rootkit in my system...
I told clamav to scan my "/" (the entire system with 320Gb total hard
drives), it toke more than 24 hours to do it and found nothing...

>
> Another concept I don't like is that the "tool" uses grep (normally egrep)
> searching for text strings - such as
>
> if `${egrep} -i adore < /proc/ksyms >/dev/null 2>&1`; then
> echo "Warning: Adore LKM installed"
> fi
>
> so if those five characters are anywhere in /proc/ksyms, including in the
> word "Labradorean"...
Should't a rootkit have at least one binary file? why these tools don't scan
binaries instead ?

> Even that is difficult. In November 2004, someone tried sending errata
> information to install a fake update appeared to contain malicious code.
> The false domain was registered on a Sunday in Melbourne, but warnings
> were being published in Usenet (as well as several on-line magazines) on
> Saturday (actually, the same day due to time zones) in North America.
> (Details: google for "Subject: Blackhats Target RH/Fedora" in the group
> comp.os.linux.misc, around 25 October 2004.) There was a similar attempt
> to sneak some mal-ware into one of the debian.org servers last year or so,
> but I don't have the cite handy. It too was detected within hours at the
> outside.
Ok, so it appears that we must install the rootkit hidden inside a
package... that's what i allways tought about it... this way, or
deliberately installed by somebody localy or remotely.

When i talk "spread", i was talking about the way win virus and worms
spread: one computer infectes other computers on a LAN, infects several
files, sends himself to another computers by mail, etc...
I have the idea that linux rootkits never spread like that, because i don't
see how they would do such thing.

> Don't get me wrong - rootkits do get installed through many possible
> venues. Above, I mention the 'adore' and 'Ramen' worms. These were
> attacking some vulnerabilities in distribution packages that had been
> patched as much as seven months before the worms appeared. And Linux isn't
> alone in this. From CERT Summary CS-98.06 (Jun 1998):
>
> 3. Root Compromises
>
> We continue to receive daily reports of sites that have suffered a
> root compromise. Many of these compromises can be traced to systems
> that are unpatched or misconfigured, which the intruders exploit
> using well-known vulnerabilities for which CERT advisories have
> been published.
>
> We encourage you to check for signs of compromise. The following
> documents can help you review your systems:
>
> Can you detect the dissatisfaction in the author's mind? "We've warned
> you about this, and _still_ you were caught unprotected."
>
> One thing that is seen more often now is the result of people grabbing
> tarballs from a dubious source and installing them
The better way to catch a rootkit

> - even though the same
> (or similar) application is available on your distribution CDs if only
> one would look there. Packages supplied by your distribution are much
> less likely to be a problem, because a lot more creditable eyes are
> looking at the package. It's also less likely to have dependency problems.
Right, i have more that 19000 packages available in synaptic...
only Opera was downloaded from extra source, the opera website.

Best regards
ArameFarpado

Moe Trin

2006-09-23, 1:16 am

On Thu, 21 Sep 2006, in the Usenet newsgroup alt.os.linux.debian, in article
<45130d18$0$75039$14726298@news.sunsite.dk>, ArameFarpado wrote:

>Moe Trin wrote:

[vbcol=seagreen]
>Ok, since i can only program in Basic ;)

I vaguely remember that - I think the last time I used Basic was in 1991.

>i can now understand the "||"

A very good way to learn about shell programming, and at the same time
learn more about the way your system operates, is to read through the
boot scripts. The whole world starts at /etc/inittab (and you do need the
man page to translate what it's trying to do), but this calls a bunch of
reasonably well written scripts that you can learn a lot from.

[vbcol=seagreen]
>Nope... here root only runs the package manager and configuration tools...
>root doesn't know how to use "user" programs, his a kind of a "dumb" root

That's good - this is one of the protective mechanisms in *nix. Root is the
only one who can (with some exceptions) do "anything" to the system. If you
are not root, even if someone manages to crack _your_ account, "you" can't
screw up the system, because you don't have the needed permissions. They
might be able to trash your account (an old student trick was to create a
script named "mroe", or "ls-l" and have that remove all files that the
victim has access to, usually the victim's home directory - very funny, no?),
but they can't (easily) get to the system.

>And i also have clamav installed, i believe clamav that even
>detects "phishing bank" mails

Mail filtering is a separate task for me. I no longer publish my real
address, so I don't see that much spam/plishing/trash. Being an old
fashioned *nix user, I receive my mail using the old Berkeley 'mail'
program, which can only display the mail as text. My correspondents
know I don't use MIME or HTML mail (I don't need to see the color of
the crayon they used to create the message), and that eliminates
nearly all exploits. I also know that my banks are not going to be asking
me to verify details, and I don't have an account with the National Bank
Of Nigeria... or Paypal - so telling me that they will lock those accounts
isn't going to bother me.

>would detect a unix rootkit in my system...

I've never used ClamAV, so I can't say. I monitor these systems with tripwire.

>I told clamav to scan my "/" (the entire system with 320Gb total hard
>drives), it toke more than 24 hours to do it and found nothing...

The advantage of tripwire - it knows what should be there and what it looks
like, so the testing is much faster. I also have a cron job that looks at
the system directories, and notifies me of any file changes in the past 72
hours, and in the past month. Another looks at the individual's home file
system and reports changes since the last login or 7 days, which ever is the
shorter period.

>Should't a rootkit have at least one binary file? why these tools don't scan
>binaries instead ?

"That depends". The mal-ware could have been downloaded, run, and while
running, the file removed (which removes the directory entry, and if
nothing is holding the file open, deletes the file as well - see the
difference between the 'du' and 'df' commands). Thus, there could be
something in the process table (unless the kernel has been altered to
hide it), and at first glance, nothing else.

>Ok, so it appears that we must install the rootkit hidden inside a
>package... that's what i allways tought about it... this way, or
>deliberately installed by somebody localy or remotely.

As a simple statement, that's fairly close to correct. However

>When i talk "spread", i was talking about the way win virus and worms
>spread: one computer infectes other computers on a LAN, infects several
>files, sends himself to another computers by mail, etc...
>I have the idea that linux rootkits never spread like that, because i don't
>see how they would do such thing.

It's been done - it's generally called a remote root exploit. (You're
making me dig into my file cabinet.) The "Ramen" worm would try to
connect to an FTP server, and see if it was 'wu-ftpd-2.6.0-3' which was
what the greeting banner read on an 'out-of-box' Red Hat 6.2, If this
was the case, it would run an exploit against the server that gave root
access to the system. It then loaded a kit and started looking for other
victims to infect locally. The worm was exploiting a problem that had
been fixed six months earlier, but a lot of people weren't keeping their
systems up to date. There were at least two or three similar worms that
exploited the same fault as I recall, but at least one was targeting
unpatched Slackware boxes.

[vbcol=seagreen]
>The better way to catch a rootkit

Exactly - that's why experienced users are cautioning people to stick with
the stuff that comes with the distributions. Still some people won't listen,
maybe because they have to have "the newest" version - I suppose their
neighbors laugh at them if they are driving a car more than four months old.

>Right, i have more that 19000 packages available in synaptic...
>only Opera was downloaded from extra source, the opera website.

If you feel that the 20 browsers that are available don't do what Opera can
do for you - by all means, get it from the source. But remember that you
have to maintain it now, and monitor the source for security updates. That
is something that people seem to forget.

Old guy