Re: Honeynet Project Security Advisory 2004-001: Sebek

[Edward Balas <ebalas () iu edu>]

On Fri, 23 Jan 2004, John Washington wrote:

> On Jan 22 at  2:02 pm, Edward Balas handed me the following bytes:
> > Solutions:
> > ==========
> >
> >
> > In the immediate term, a revised sbk_install.sh script has been
> > added to the sebek-linux-2.1.4 code.  This installer first changes
> > the name of the kernel module, then it then modifies the module
> > loading process to reduce the number of symbols that are left
> > floating in memory.   This short term fix will cause sebek_rape to
> > fail , however one should always follow best practices.
> >
> >       - "-y" flag has been added to the insmod command, this prevents
> >              the definition of ksymoops symbols for Sebek, which
> >              with then cause sebek_rape to fail.
> >
> >       -  a few code changes have been added to make it a little
> >          bit harder extract the config.
> >
> > This patched version is available at:
> >
> >       http://www.honeynet.org/tools/sebek
> >       16708ad30e2caf8431735439fcb60fd5  sebek-linux-2.1.5.tgz
> >
> > In the short term, a new version of the Linux client will be
> > available, that will make it more difficult to detect and extract
> > the configuration from memory.
>
> Wouldn't it also make sense to do something along the lines of using known 
> (non-conflicting) module names (determined at setup for the honeypot) 
> that would appear innocous on the honeypot?  Obviously this can be 
> applied to other things that are common.

The 2.1.5 client changes the name of the module to a random value or 
it can be sent in the config section of the sbk_install script to 
something that is desired, this is based on a new variable called
MODULE_NAME.  I leave it up to operator to select a known but non
conflicting name for now.

Related to this, the names of the parameters passed during the insmod
are now randomly selected at build time.


 
> As a sidenote, the reason I would choose (random) valid names is to lower the 
> probability of just looing for a string that doesn't fit/isn't known.

Yeah grepping though /proc/kcore can be quite effective.



Edward