linux security - May 1998 - Re: Re: Re: Bind Overrun Bug and Linux (fwd)

> > systems which no longer seem to have this. This file contained an
archive of
> > the trojan''s that were inserted into the compromised system -
does anybody know
> > what is in these trojans?
> 
> Check the Linux RootKit ... (LRK)..
> 
> Typically LRK to use config-files.. (and typically LRK-users to place
> files in /dev.. find /dev -type f | grep -v MAKEDEV.. examine results)
> 
> ps
> ls
> top
> netstat
> ifconfig
> linsniff
> login
Finding a joe blow hacker is quite the trivial process, most of them leave
the default configuration files as they were named in the rootkit.

There are many set of trojanned source code trees out there, but the most
prevailent seems to be Linux RootKit (LRK).  This kit included lots of
trojanned binary source, but is sloppily written.

This is all LRK actually contains, from it''s readme:
chfn: local backdoor
chsh: local backdoor
inetd: remote backdoor
login: remote backdoor
ls/du: hide files
ifconfig: hide sniffing
netstat: hide connections
ps/top: hide processes
passwd: localhost backdoor
rshd: remote backdoor
syslogd: hide log strings
tcpd: avoid denials
It also includes linsniff, and a few other log cleaner programs.

Furthermore;  there are more eleet rootkits out there that include a
number of kernel modules that can hide virtually anything.


 For example, LRK config defaults:
	/dev/ttyp*
These files are quite noticable, as *no* files in /dev/ should be of type
f (regular file) except MAKEDEV.  They should be of only type: c/b/s.  A
simple ''find /dev -type f'' will report all of the regular file
types.

Doing a strings /bin/ps will should you the file that they have assigned
PS to take its hideable strings from.

Also, you may want to look at some code that looks through the wtmp/utmp
files and looks for null entries, most wtmp cleaners NULL out the entry,
rather than writing a whole new wtmp.

I would not be so sure as to rely on what they have backdoored locally, as
most people would want to place many remote backdoors. If there is no
remote backdoors, then what use is there to put a local backdoor in?  

I would think the most common remote backdoor pairs would be something
like: rshd/tcpd/inetd/login and local: passwd/ping/chfn.  I witness many
people using *all* of the backdoors provided with these rootkits, just to
get found in 1 hour.  

There are many preventitive measures that could be taken to possibly
avoid these situations.  
For example: 
	-take checksums and make a script that compaires them nightly.  It
is also a good idea to grab a clean binary, and a master checksum list of
a WRITE protected media source, most commonly a floppy disk.  
	-keep clean system binaries, all of the netkit, and majority of
suid root installed binaries.
	-make some sort of script that monitors the kernel and reports
if it is forced into promiscous mode.
	-know WHO is on your system, and measure out the pro''s and
con''s
in giving out shell accounts
	-keep updated on what bugs have been made public, along with
applying the necessary patches for them
	-compile your kernel to not support on-demand loadable modules
	-do nightly diff''s between crucial system files, eg: /etc/passwd

There are many other measures to be taken, and many software packages out
there to help.  But it all boils down to the whole fact that if you are
security concious, rootsh3ll hackers will not be able to comprimise your
network integrity as they only use publically available exploits.  And if
the person that is hacking you does not use rootsh3ll warez, expect to
never get rid of him without rm -rf /''ing your whole system.  

On a side note, LRK has much quantity, but lacks quality.  Any hacker
with skill realizes that you cannot have gay little /dev/ttyp* plain text
configuration files laying around.

Don''t be scared of ''configure rootkit ; make install''
kiddies, these are
the people like ''The Analyzer'' that get caught up on becoming
well known
in the hacker community, but have no real skills.

Be scared of the people that you do not see on your system, or find
evidence of them being their, but you just know they are.


Regards, Shaun.

On Sat, 23 May 1998, Shaun wrote:
> 	-make some sort of script that monitors the kernel and reports
> if it is forced into promiscous mode.
Actually, on other lists, people have posted saying they''ve hacked the
kernel to make the kernel panic when an ethernet device goes into
promiscuous mode.  Kind of like the James Bond theft-proof lotus, but it
will definitely set off the alarms if you''re hacked and they start up a
sniffer that puts eth0 in promiscuous mode.
> 	-know WHO is on your system, and measure out the pro''s and
con''s
> in giving out shell accounts
As an ISP, we used to give shell to all clients...but since most clients
signing up today don''t know what telnet is, we no longer give them
shell
access unless they ask for it.  Many times, an intruder will get in after
somehow sniffing a clients password from another network or social
engineering.  If the account they compromise doesn''t have shell, it
will
at least slow them down if not seriously limit the damage they can do.
> 	-compile your kernel to not support on-demand loadable modules
Hmm...I could try reading the source...but isn''t this a job for
securelevel?  Does the kernel currently support, via securelevel,
prevention of module loading?  It would be nice if you could load modules,
then bump up securelevel, and no longer be able to.  Some things can''t
be
linked into the kernel.

[mod: Securelevel is not properly enforced in 2.0.33. The word
securelevel doesn''t occur anywhere in the 2.1.102 kernel. -- REW]
> network integrity as they only use publically available exploits.  And if
> the person that is hacking you does not use rootsh3ll warez, expect to
> never get rid of him without rm -rf /''ing your whole system.  
If you''re lucky and have a non-hacked backup, you can restore to
alternate
disks, and then compare file by file.


------------------------------------------------------------------
 Jon Lewis <jlewis@fdt.net>  |  Spammers will be winnuked or 
 Network Administrator       |  drawn and quartered...whichever
 Florida Digital Turnpike    |  is more convenient.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

> kernel to make the kernel panic when an ethernet device goes into
> promiscuous mode.  Kind of like the James Bond theft-proof lotus, but it
> will definitely set off the alarms if you''re hacked and they start
up a
> sniffer that puts eth0 in promiscuous mode.
This is a good idea, but what happens if the machine is being put into
promiscuous mode for other reasons than to sniff.  I run raw tcp/udp
loggers that require it, so it would not work that good.
> As an ISP, we used to give shell to all clients...but since most clients
> signing up today don''t know what telnet is, we no longer give them
shell
> access unless they ask for it.  Many times, an intruder will get in after
> somehow sniffing a clients password from another network or social
> engineering.  If the account they compromise doesn''t have shell,
it will
> at least slow them down if not seriously limit the damage they can do.
I think a policy of NO shell access is a wise step to take.
It takes away many risks, and many man hours of having to actually watch
over the system.
> Hmm...I could try reading the source...but isn''t this a job for
> securelevel?  Does the kernel currently support, via securelevel,
> prevention of module loading?  It would be nice if you could load modules,
> then bump up securelevel, and no longer be able to.  Some things
can''t be
> linked into the kernel.
> 
> [mod: Securelevel is not properly enforced in 2.0.33. The word
> securelevel doesn''t occur anywhere in the 2.1.102 kernel. -- REW]
I thought securelevel was not properly enforced in any development or
stable kernel.  I know there have been patches put out, Phrack included
one in it''s most recent issue.  Also, didn''t Solar Designer
include one in
his secure-linux set?

It would be nice if linux just had a working securelevel system, it is
pointless using chattr to change flags on system files, as anyone with
root can just change them back.  This demeans the whole idea of having to
boot into single user mode (which on most 4.4bsd based unixes, requires
you to have to be at the console) to change these flags.

Backup, and be safe.

PS, would someone with knowledge of *bsd securelevel systems please post
something regarding this topic.

Regads.

Shaun <shaun@lexicom.ab.ca> writes:
> This is a good idea, but what happens if the machine is being put into
> promiscuous mode for other reasons than to sniff.  I run raw tcp/udp
> loggers that require it, so it would not work that good.
The feature would presumably be optional and intended for folks who
wouldn''t be making any legitimate use of promiscuous mode.
> I think a policy of NO shell access is a wise step to take.
> It takes away many risks, and many man hours of having to actually watch
> over the system.
Indeed; that''s why I created a dedicated SLiRP account on one machine.
> I thought securelevel was not properly enforced in any development or
> stable kernel.  I know there have been patches put out, Phrack included
> one in it''s most recent issue.  Also, didn''t Solar
Designer include one in
> his secure-linux set?
Linux is going to have POSIX.6^H1f(?) capabilities, not a scalar
securelevel.  I don''t know how far the linux-privs folks have gotten,
but I''m pretty sure they integrated enough of a skeleton into 2.1.x to
replace all the [f]suser() calls.

-- 
Aaron M. Ucko <amu@mit.edu> (finger amu@monk.mit.edu) [Stark raving sane]

Shaun (shaun@lexicom.ab.ca) wrote:
>  For example, LRK config defaults:
> 	/dev/ttyp*
> These files are quite noticable, as *no* files in /dev/ should be of type
> f (regular file) except MAKEDEV.  They should be of only type: c/b/s.  A
> simple ''find /dev -type f'' will report all of the regular
file types.
On the other hand, don''t presume that your attacker is totally inept
and will therefore stay with the LRK defaults; I have seen a case
where the config files were changed to /usr/lib/lib[pqrs].o for
example.

I''m sure that even lame r00tsh3l1 crackers are capable of thinking of
decent hiding places :-)

On Sun, 24 May 1998, Shaun wrote:
> I thought securelevel was not properly enforced in any development or
> stable kernel.  I know there have been patches put out, Phrack included
> one in it''s most recent issue.  Also, didn''t Solar
Designer include one in
> his secure-linux set?
Are there security concious admins not using Solar''s secure-linux?  It
would be really nice if we could get this into the stock kernel...but I
suspect we''d be hit with the "no new features" argument for
2.0.x.
Merging his 2.0.33 patch into 2.0.34pre15 took some work as many of the
bugfix parts had gotten fixed in the kernel and patch rejected them.
> It would be nice if linux just had a working securelevel system, it is
> pointless using chattr to change flags on system files, as anyone with
> root can just change them back.  This demeans the whole idea of having to
If they know how :).  Many hackers don''t know jack.  They just have
rootkit and a bag-o-sploits to try.

BTW...drifting back to the original topic....as of bind 8.1.2, it''s
really
easy to run bind as !root.  I''m running it on a few systems now as user
named.
 
------------------------------------------------------------------
 Jon Lewis <jlewis@fdt.net>  |  Spammers will be winnuked or 
 Network Administrator       |  drawn and quartered...whichever
 Florida Digital Turnpike    |  is more convenient.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

On Sun, May 24, 1998 at 12:11:15PM -0600, Shaun wrote:
> > kernel to make the kernel panic when an ethernet device goes into
> > promiscuous mode.  Kind of like the James Bond theft-proof lotus, but
it
> > will definitely set off the alarms if you''re hacked and they
start up a
> > sniffer that puts eth0 in promiscuous mode.
> 
> This is a good idea, but what happens if the machine is being put into
> promiscuous mode for other reasons than to sniff.  I run raw tcp/udp
> loggers that require it, so it would not work that good.
> 
This is exactly what makes the new 2.1.x capabilities much more useful
than BSD securelevel. You can remove the CAP_NET_ADMIN capability from
all processes except for your logger. This makes is easier to
implement a "least privilege" policy.
> > As an ISP, we used to give shell to all clients...but since most
clients
> > signing up today don''t know what telnet is, we no longer give
them shell
> > access unless they ask for it.  Many times, an intruder will get in
after
> > somehow sniffing a clients password from another network or social
> > engineering.  If the account they compromise doesn''t have
shell, it will
> > at least slow them down if not seriously limit the damage they can do.
> 
> I think a policy of NO shell access is a wise step to take.
> It takes away many risks, and many man hours of having to actually watch
> over the system.
> 
> > Hmm...I could try reading the source...but isn''t this a job
for
> > securelevel?  Does the kernel currently support, via securelevel,
> > prevention of module loading?  It would be nice if you could load
modules,
> > then bump up securelevel, and no longer be able to.  Some things
can''t be
> > linked into the kernel.
This is possible in 2.1. Remove the CAP_NET_MODULE capability from all
processes. The capset system call will do it in a single atomic
operation - emulating *BSD securelevel if you want.

However, the capability needed to remove other capabilities
(CAP_SETPCAP) isn''t enabled by default in 2.1 to make sure we
didn''t
introduce new security issues. This means that you have to do some
changes to your system to be able to use this functionality.

First of all, you need a patched init. Init is the only process who
has the CAP_SETPCAP capability and by default, processes started by
init will not inherit CAP_SETPCAP. You can either patch init to "bind"
a security level to runlevel, or you can let selected subprocesses
started by init inherit CAP_SETPCAP and work as "security daemon".
> > 
> > [mod: Securelevel is not properly enforced in 2.0.33. The word
> > securelevel doesn''t occur anywhere in the 2.1.102 kernel. --
REW]
> 
> I thought securelevel was not properly enforced in any development or
> stable kernel.  I know there have been patches put out, Phrack included
> one in it''s most recent issue.  Also, didn''t Solar
Designer include one in
> his secure-linux set?
> 
I think there are some patches in the 2.0.34pre kernels. Also, we have
a lot of securelevel patches in our GNSL distribution.

In GNSL, we have a securelevel ranging from 0 to 6999. root is allowed
to increase securelevel from say 2000-2999 when in runlevel 2. Init is
the only one allowed to bump securelevel over a 1000-limit. The
securelevel can only increased, even by init. The bootup sequence
starts in runlevel 2 and ends in runlevel 5, disabling kernel features
on the way.

More info at http://www.guardian.no/gnsl/

> PS, would someone with knowledge of *bsd securelevel systems please
> post something regarding this topic.
capabilities leaves securelevel-systems like OpenBSD in the dust ;-)

astor

-- 
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/

> >  For example, LRK config defaults:
> > 	/dev/ttyp*
> > These files are quite noticable, as *no* files in /dev/ should be of
type
> > f (regular file) except MAKEDEV.  They should be of only type: c/b/s. 
A
> > simple ''find /dev -type f'' will report all of the
regular file types.
> 
> On the other hand, don''t presume that your attacker is totally
inept
> and will therefore stay with the LRK defaults; I have seen a case
> where the config files were changed to /usr/lib/lib[pqrs].o for
> example.
I was writing under the assumption that the person you are dealing with is
a mere rootshell kid.  Hiding a file is easy, there are many places to put
it without being noticed.  But it seams most hackers enjoy putting things
in the default place, maybe they are too stupid or lazy?

I like to keep a recursive ls -lR on hand, and diff that nightly too with
a master copy.  These little things are good prevention tools. 

If your hacker is not totally inept, then I think it is fair to say
that you have more of a problem than just LRK.

On a side note, many people rely on firewalls too much.  This gives them a
false sense of security.  I still believe that you must incorporate both
local and remote security of machines to have them truly(partially?)
secure.  It''s a given fact that most machines behind the firewall are
open
to connect to each other without any intervention.  If the person you are
dealing with is crafty, he will attack the weakest link on the network,
and that is where most bigger organizations fall, i.e. .edu sites.

Personally, I like to also secure the box locally, removing the unused
suid binaries, shutting services down, sticking to an SSH only policy.
All these little things help.

Oh well, Regards. :)