Re: Non registering shell

[Brian Hatch <vuln-dev () ifokr org>]

> I have a question I hope somebody will be able to answer.  I am looking
> for code to build a UNIX shell which is immune to system process listing
> and or logged by the syslog facility, is this possible?  I used to work
> for a government contractor , and met a UNIX systems programmer who
> wrote a shell which made his work invisible.  Can anyone share info on
> this?

You mean you want to be able to run commands from a 'magic' shell
and have those commands invisible from ps, top, lsof, etc?

No, this is not possible.  The kernel keeps track of all running
processes.  (If it didn't, it wouldn't be able to give them access
to system calls, CPU, etc.)  The kernel is where process reporting
programs such as ps, top, lsof, and friends get their information
from.  You cannot have a shell that 'outfoxes' the kernel.

You can modify the kernel to not report processes if you

        * have a loadable kernel module that intercepts process
          listing accesses and hides certain processes from the list
        * modfify the process reporting structure, such as the
          /proc filesystem, to hide these processes

Now someone could determine that a process did exist by using 'kill'
and noting when a non-existant process id returned a 'permission denied'
instead of 'no such process' depending on how the kernel was modified.

One other method could be that you write a shell that modifies the
argv[0] of each child.  So instead of calling
        
        "/bin/cat" "cat" "arg1" "arg2" "arg3" ...

you call

        "/bin/cat" "sh" "arg1" "arg2" "arg3" ...

to make cat think it's name is 'sh', and the process list will show
'sh' as well.[1]  You'll still have an entry in ps (and the arguments
may indicate something is wierd if you saw "sh / -name foo -exec
something {} ;" in ps output, since that's clearly 'find' syntax)
but it won't be immediately obvious if a user just does a ps for
process name, not args.

However this will cause problems for any program that actually checks
argv[0] - for example gzip, gunzip, and zcat are usually the same file
(hardlinks) and it uses argv[0] to determine how it should behave.

The other solution would be to backdoor all your process reporting tools
and hope no one brings along a pristine copy.

So your options are:

        * modify kernel                 very effective

        * modify ps/top/etc             somewhat effective

        * new shell that fudges         pretty lame and will break
          argv[0] of children           some functionality


Now if you were talking about more mundane things like not leaving
a .history file around, that's trivial.  Reset the appropriate
env variables (HISTFILE and/or HISTSAVE for example) and they won't
log.  To be 'immune' from syslog, use programs that don't send syslogs,
or you could LD_PRELOAD a library that defined openlog, syslog, and
closelog to null functions.



[1] Depending on your OS, you may still be able to learn the real
    process name.  In Linux, for example, /proc/PID/exe will be
    a symlink to the real /bin/cat executable.  /proc/PID/stat*
    will point out other helpful info too.


--
Brian Hatch                  Why do "fat chance"
   Systems and                and "slim chance"
   Security Engineer          mean the same thing?
www.hackinglinuxexposed.com

Every message PGP signed

Attachment: _bin
Description: