Vulnerability Development mailing list archives

Alternative to historyfile logging.


From: jen () ETTNET SE (Joel Eriksson)
Date: Mon, 17 Apr 2000 12:07:34 +0200


Historyfiles aren't trustworthy, as we all know. Processaccounting and
logging on the systemcall level is one way to remedy that, but it's not
as "fancy" as having every commandline logged, including typos and all.

Utilities such as "ttysnoop" and "script" are more useful in this area.
For those who doesn't already know what these utilities does, ttysnoop
is used to interactively snoop on logged in users tty's, I don't think
it has been updated for quite a while now though and has had security-
holes in the past. "script" spawns a shell and logs everything written
to the terminal (fd's 1 and 2, stdout and stderr) to a file, not useful
for stealth logging as is but can be easily modified.

There is another utility that could be used for this purpose though, and
that provides both the features of "ttysnoop" and "script" in one package.
That utility is "screen", mostly known for letting lusers have their
IRC-sessions and such running while logged off, and then being able to
resume them as if never even having logged out.

To interactively snoop on a users sessions, use "screen -x". To log
everything echoed to the terminal, use "logfile <path>" in the
screenrc file.

But how could this be done in a stealthy fashion? Well, first of all,
programs such as ps, top and the like should probably be patched to
hide the screen-processes, obviously. Another thing that needs to be
taken care of is that $TERM is set to "screen" since screen has it's
own vt100-like terminal emulation (I think it should be fully vt100
compatible, but I'm not sure). This could for example be done by
copying the "screen" termcap-settings over other commonly used terminal
emulations, depending on how paranoid you are or how clever your users
are. If they connect to other computers from your server there may
be problems when the terminalemulation doesn't match...

We won't get away without a little bit of patching though (I think, if
someone comes up with a clever way to use screen out-of-the-package in
a stealthy fashion, please let us know), the user will for instance
see "[screen is terminating]" when he/she logs out as default. The
sockets used by screen will be in /tmp/S-<username> and needs to be
hidden somehow, "STY" and "TERMCAP" will be added to the environment,
"w" and others will show ":ttyXX:S.n" and "tty" will show that another
tty than usual is used. Last but not least, the specialcharacters used
by screen must be disabled.

How much patching you'll actually do finally comes down to how clever
you think your users are, the best way would be to patch the kernel
to log at the tty/pty-level (processaccounting only gives you everything
executed, not what is actually done). For those with clueless users,
just replace the shells with a shellscript containing something like:

---
#!/bin/sh

export SCREENRC=/path/to/screenrc

exec screen
---

Where the screenrc file would have stuff like:

---
startup_message off                     # Don't show startupmessage
shell           -<name-of-shell>        # Shell to use (- for loginshell)
---

I just realized that logging can not be enabled from the screenrc-file
though (since a window has not been created yet when screenrc is read),
so I guess a little patching has to be done anyway.

Note that I haven't claimed it to be perfect though, systemcall logging
would in theory be the best, but parsing those logs would not be that fun
and it would take a whole lot of diskspace, flooding the logs to fill the
harddrive would make for an easy DoS... The good thing would be that you
would catch the ones that uploads programs or scripts, executes them and
then deletes them, since they could do stuff that are never shown on the
tty (which is the only thing logged).

If anyone has the time and interest to make a stealthy "screen", let me
know. It would be a really useful tool for me and all the other BOFH's
out there. :-) I know there are modified "script" versions that are
rather stealthy, but I kind of like the idea of being able to snoop
in realtime _and_ log to files. And "screen" already runs on almost
every Unix anyway.. A nice feature to add except for the stealthy
stuff would be to log what is not echo'ed to the terminal also,
otherwise "stty -echo" would be enough to not having any commandlines
logged.

--
Joel Eriksson



Current thread: