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:
- Re: History Files, (continued)
- Re: History Files Seth R Arnold (Apr 15)
- Re: History Files Omachonu Ogali (Apr 15)
- Re: History Files Corwin J. Grey (Apr 15)
- Re: History Files Corwin J. Grey (Apr 15)
- Re: History Files Omachonu Ogali (Apr 15)
- Re: History Files Corwin J. Grey (Apr 15)
- Re: History Files Gert-Jan Hagenaars (Apr 16)
- Re: History Files Bluefish (Apr 17)
- Re: History Files Omachonu Ogali (Apr 15)
- Re: History Files Michael Jennings (Apr 15)
- Re: History Files Mark Rafn (Apr 16)
- Alternative to historyfile logging. Joel Eriksson (Apr 17)
- Re: History Files Joel Eriksson (Apr 17)
- Re: History Files spiff (Apr 18)
- Re: History Files Corwin J. Grey (Apr 16)
- Re: History Files Michael Jennings (Apr 16)
- Cooments on the dvwssr.dll vulnerability threads Iván Arce (Apr 17)
- Re: History Files Senior Systems Administrator - Kris W. (Apr 16)
- quick dirty and most of all-easy process accounting via lkm Security Team (Apr 16)
- Re: History Files George Dodd (Apr 18)
- Re: History Files Perly (Apr 19)