AW: AW: [suse-security] SuSE security reputation, etc..
Someone might install some scripts to USER account and for example copy all input/output to a file, including su passwords.
Good idea. But how should he manage to get this script started ? And even if the script IS started and running, I should see it when doing a ps, shouldn't I ? And I always do ps axf before doing any su-like thing. Any other holes ? --- Stephan
On Sat, 5 Aug 2000, OKDesign oHG Security Webmaster wrote:
Someone might install some scripts to USER account and for example copy all input/output to a file, including su passwords.
Good idea. But how should he manage to get this script started ? And even if the script IS started and running, I should see it when doing a ps, shouldn't I ? And I always do ps axf before doing any su-like thing.
Any other holes ?
You can not rely on any operations after someone compromises your account. A script could be run in your .login or any other .rc file. The attaker might even compile a new binary for some of your commands (for example su or ps ) to snoop your passwords and place it to your path before the real one. Of course he can only put it in some directory that user has privileges to write, but still it is possible to make your users environment hostile. Checking prosesses would then only show 'normal' things after all he might even have changed your bash (or another shell you use to some hacked binary) and the .login script might run that malicious shell for you before you get to type in even the first command. This shell could be carefully crafted to hide its existence in every aspect, as it could process input and output of commands like ps and su anyway it sees fit. -Pete
--- Stephan
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Hello Stephan, I recently had to clean up after a break-in (which is what inspired me to join this list). Some comments to add to Pete's followup: On Sat, 5 Aug 2000, OKDesign oHG Security Webmaster wrote:
Someone might install some scripts to USER account and for example copy all input/output to a file, including su passwords.
Good idea. But how should he manage to get this script started ?
As Pete said, consider any environment that has been broken into (even just one of your users) hostile until completely proven otherwise. Closely inspect *all* of those user files, *especially* the dot-files. Sometimes, the only thing changed in the login profile command (i.e. .bashrc or .bash_profile) is the "PATH=" statement, to add a new directory to the beginning of the list. I've actually seen a new directory of "...", designed be overlooked with the usual "." and ".." at the top. I've also heard mention of ".^H" or ".<rubout>" but am not sure how a person either creates or uses such a directory. Also, *heavily* scrutinize /tmp! This is ESPECIALLY imperative if anyone hasn't responded to the recent SuSE advisory regarding aaabase (where a few users, such as "nobody" have /tmp as their home directory). In this case, look for "/tmp/.bashrc". Often, the best approach, when a user account has been compromised, is to back it (and /tmp) up to a secure location, re-initialize it and /tmp, and then give the user their data files, one at a time, after carefully examining them. Hope this helps. Best regards, Ken Parker P.S. When the "Script Kiddies" gained root on my system, they linked /root/.bash_history to /dev/null. That was the last straw, when I was examining my system, inspiring me to yank the ethernet cord out of the back of the computer. (They entered through a year-old Sendmail vulnerability).
I've actually seen a new directory of "...", designed be overlooked with the usual "." and ".." at the top. I've also heard mention of ".^H" or ".<rubout>" but am not sure how a person either creates or uses such a directory. Also, *heavily* scrutinize /tmp! This is ESPECIALLY imperative if anyone hasn't responded to the recent SuSE advisory regarding aaabase (where a few users, such as "nobody" have /tmp as their home directory). In this case, look for "/tmp/.bashrc".
Another reason to put /tmp on it's own filesystem. When you want to really super purge it you can format the puppy, or to be super paranoid run something like wipe on the partition.
Often, the best approach, when a user account has been compromised, is to back it (and /tmp) up to a secure location, re-initialize it and /tmp, and then give the user their data files, one at a time, after carefully examining them.
Any user writeable area too, mailspool, etc. find / -perm +0002 -print
Hope this helps.
Best regards,
Ken Parker
Comment on sendmail: USE POSTFIX! =) -Kurt
The usual thing that you do is to log in as the user, and install a trojaned copy of ssh in the user's path (usually .profile or .bashrc etc) then if/when the user every uses that shell to ssh somewhere else, bingo you have their password to that system. It's a basic "follow in".... Cheers Nix Quoting OKDesign oHG Security Webmaster <security@okdesign.de>:
Someone might install some scripts to USER account and for example copy all input/output to a file, including su passwords.
Good idea. But how should he manage to get this script started ? And even if the script IS started and running, I should see it when doing a ps, shouldn't I ? And I always do ps axf before doing any su-like thing.
Any other holes ?
--- Stephan
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
participants (5)
-
devel＠master.kparker.org -
Kurt Seifried -
nix＠cotse.com -
OKDesign oHG Security Webmaster -
Petri Sirkkala.