Security Digest Volume 1 Issue 29 subject(s): CERT Internet Security Advisory Re: programs owned by bin Re: Security tools Re: Security tools Re: Security programs holes via terminal emulators ------------------------------------------------------------------------ Date: Wed, 16 Aug 89 11:45:34 EDT From: Kenneth R. van Wyk Subject: CERT Internet Security Advisory [ I put this digest out early because of this message - neil ] Many computers connected to the Internet have recently experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "telnet" programs illicitly replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs. (As a first step, frequent telnet users should change their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators can do to detect whether the security on their machines has been compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators should do the following: o Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail". In general, we suggest that site administrators be attentive to configuration management issues. These include the following: o Test authenticity of critical programs - Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords should be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on-line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes. o Privileged programs - Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) can be exploited to gain unrestricted access to systems. System administrators should watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access. o Monitor system logs - System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. o Terminal servers - Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts. o Passwords - Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets. System administrators should make sure that all accounts are password protected and encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. o Anonymous file transfer - Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol - which requires no username/password authentication) should always be configured to run as a non-privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, should not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure. o Apply fixes - Many of the old "holes" in UNIX have been closed. Check with your vendor and install all of the latest fixes. If system administrators do discover any unauthorized system activity, they are urged to contact the Computer Emergency Response Team (CERT). ------------------------------------------------------------------------ Date: Tue, 15 Aug 89 10:21:40 EDT From: uunet!ateng.ateng.com!chip (Chip Salzenberg) Subject: Re: programs owned by bin Seth Robertson: > The file is *not* truncated and the contents of the wall message put at > the contents of the file. Instead, the file remains as it is, except that > the file is overwritten with some wall stuff and the mangled contents of > your message. > [...] > You can imagine what would happen to a executable. I would really > have my doubts that the program would run, no matter how tricky you > got... Denial of service is still a real problem here. But perhaps you forget that shell scripts are executable as well. Here's a way to use the hole: Pick a program executed by root from a crontab; extra credit if the command line includes "2>/dev/null". Make a copy of that program. Use wall to overwrite it with a standard "cp /bin/sh /usr/hacker/sushi; chmod u+s /usr/hacker/sushi; exit" Trojan Horse. Wait until cron executes the Trojan Horse. A few "No such command" messages later, J. Random Hacker is root. ------------------------------------------------------------------------ Date: Tue, 15 Aug 89 10:32:39 EDT From: uunet!devon.lns.pa.us!paul (Paul Sutcliffe Jr.) Subject: Re: Security tools In Security Digest Volume 1 Issue 28, sechreset@uther.CS.ORST.EDU wrote: +--------- | I am looking for a few programs that will help me tighten up security | a little bit. I have heard about some of these programs, but I have not | been able to find them in any of the anonymous FTP sites that I have | looked at. If you have any of the following programs or know where I can | get them, Please let me know. | | Here is a list of programs that I would like to find: | | [...] | A getty that restricts logins only to those that are on an access list | [...] +--------- Personally, I think that checking usernames against an `access list' should be login's job, not getty's. A `freely redistributable' login clone authored by John F. Haugh II could be modified to include this feature. John's package also includes passwd(1) and su(1), among others. I've Cc'd John in case he wants to comment. Now, if someone (including John) could convince me that this feature belongs in getty, I've written (and am currently beta-testing) a SYSV getty clone that I will release (via UseNet's comp.sources.misc) when it's complete. Discussion? ------------------------------------------------------------------------ Date: Tue Aug 15 20:18:48 1989 From: uunet!cs.utexas.edu!rpp386.Cactus.ORG!jfh (John F. Haugh II) Subject: Re: Security tools > In Security Digest Volume 1 Issue 28, sechreset@uther.CS.ORST.EDU wrote: > +--------- > | [...] > | A getty that restricts logins only to those that are on an access list > | [...] > +--------- > > Personally, I think that checking usernames against an `access list' > should be login's job, not getty's. Quite correct. getty hasn't authenticated the user yet, so getty is incapable of determining if the user is authorized to perform any operation. A possible scenario is login: okay_user Password: login incorrect login: not_okay_user Password: Welcome to okay_user's private port! $ So much for that idea ... Port restrictions are in the present version of my shadow login, as are time-of-day restrictions as well [ I think. ] ------------------------------------------------------------------------ Date: Wed, 16 Aug 89 09:53:21 EDT From: uunet!teleng!gorpong (Gordon C. Galligher) Subject: Re: Security programs In Volume 1 # 28 you ask for submissions of certain security programs which exist out there to include in the automatic archives. I don't have a program which checks security, but I do have a program which enforces certain levels of security and monitoring facilities It is written entirely in C, it has a README, Makefile, manual page, etc. There is a catch, it needs to be setuid in order to work. It only stays setuid while it checks the restricted log files and then immediately does a setgid/setuid to the specified user. A quick synopsis is, you create an "allow" file with a list of the monitored/restricted programs and who is allowed to access them. In that file is the directory to go to, and the command to execute as a special user. The applications are then linked (via ln(1)) to the main program and that name becomes the monitored application in the allow file and in the password file. For example, I want to allow the use of the mount/umount commands for non-root users, so I use the builtin program to create/modify the "allow" file for mount. I then have to modify the password file to add the mount user and umount user. I give them unbreakable passwords (ie: *) with the user-id of root. I then link in the 'mount' program with the main program and everytime I run mount (which appears earlier in my path than /usr/etc) I am actually running the monitored/restricted mount and not the /usr/etc/mount. A better example is how we are using it at Telxon. We have a number of groups working on our products, and each of these groups is actually a user on the system. Prior to my employment the users just cd'd to the special user and started modifying information. The special user had write priviledges for its group. This is a potential security problem so they decided to use the 'su' command to handle things. Well, this was just about as bad because the passwords were written down by terminals and such so they could remember. Now all they do is type 'opsys' and they are immediately logged as going into opsys, they are placed in the opsys home directory, they become the opsys user, get all of the groups that opsys gets (only in Berkeley, System V only has one group at a time), and execute a /bin/csh. It is effectively a short-circuited 'su' program. Granted, with this manner if their terminals are left exposed then anyone can go into the opsys user, but the users take better care of their own passwords than they did with the special user passwords. I apologize for all this verbosity, but if I only give part of the facts then it looks more like a security HOLE than a security feature. I have asked quite a few people to try to break it, without success. I can send you the manual page and you can see if it is worth-while in the archives, or by what you've read, you can decide that it is worthless. Let me know if you want anything else and I'll be happy to oblige. [ Please send the whole thing to zardoz!neil and I will put it in the archives (which should be accessable real soon now, I promise) - neil ] ------------------------------------------------------------------------ Date: Wed, 16 Aug 89 11:05:27 MDT From: elroy!ames!ncar.UCAR.EDU!boulder!cadnetix.COM!rusty (Rusty Carruth) Subject: holes via terminal emulators In article <0004.8908071130.AA17865@ge.sei.cmu.edu> kelly@uts.amdahl.com writes: >The trick of defining a command sequence to create sushi on a unix system would >compromise root integrity... most comm software that is capable of either >emulating programmable terminal sequences or ansi.sys and programs that implement >those sequences are capable of accepting a command line into a buffer or window >with the view attribute set to non-visible and then retransmitting that command >to the host unix system all under remote control.... I could hardly call that >harmless... furthermore most users including a surprising number of systems >administration types are unaware that their terminal or programmable termulator/ >file transfer package can be tricked in this fashion..> >p.s. sushi --> SuperUser SHell Interactive. the trick above is known as a >boomerang also!! I thought perhaps this should be something we were reminded of here on the security-mailing list. Sure, its not an alert or anything like that, but given the comment above about 'a surprising number of systems admin types' being unaware of this problem, it seemed to me like a good thing to remind ourselves of. (I got this article from the comp.virus newsgroup) ------------------------------------------------------------------------ End of Security Digest Volume 1 Issue 29 **********************