Re: Non registering shell

[Rory Savage <rsavage () nandomedia com>]

Brian,

   Now that you mention it, I think it was a backdoor (a special
rootshell).  Can any provide URLs to example backdoors?


-Rory

On Thu, 2003-02-27 at 14:45, Brian Hatch wrote:
> > 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