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
This archive was generated by hypermail 2b30 : Fri Feb 28 2003 - 08:29:01 PST