bill@ssbn.WLK.COM (Bill Kennedy) (11/01/88)
First many thanks to the folks who responded to my questions and second, apologies for this taking so long to get posted. It's rather lengthy but (in my opinion) worth reading every word. I have edited slightly but have annotated where I did. ----------------------------------------------------------------- >From: spaf@cs.purdue.edu (Gene Spafford) Spaf posted but it's worth a repeat. Here's a very rough list of things to check: 1) make sure / /bin /usr /usr/bin /etc /usr/spool and any other bin directories are all mode 755 or less (ie, 555, 751, etc). 2) Allow NO accounts without passwords, including uucp. 3) Don't have any accounts other than root with uid 0 4) Make sure no files in any bin or /etc are writeable by anyone other than user root (or bin, if you have things set up that way -- if you do, don't have bin's entry in /etc/passwd with a runnable shell or password). 5) crontab, mem, kmem, uucp/L.sys should not be readable by world. Crontab should probably be mode 600. The rest should be something like 440. Programs that read kmem to display status should be setGid to some group (named, kmem, for instance). 6) On many systems, "at" is a security hole. If no one uses it, disable it. 7) Don't run anything out of crontab as root unless you absolutely must. For instance, to run the nightly news scripts, use "su" in the crontab file to run the scripts as user news. E.g., 40 1 0 0 0 su news </usr/lib/news/nightly 8) Keep a list of all setuid/setgid files on your system (use "find", for instance). Keep the list off-line. Recheck it periodically and see if any files have changed size or modification time (or had those bits added or deleted). 9) If your system logs bad login attempts to the console, or bad attempts to change passwords, then be sure to audit your logs -- frequently! 10) On BSD systems, don't have any setuid/setgid shell scripts -- unless you know that the security hole with them has been fixed on your system. 11) Don't have the "." directory in the PATH variable for root or for any privileged user. 12) Don't have any special versions of "su" around that don't require a password. 13) If you're running in an NFS environment, don't have any workstations located where untrusted individuals can reboot them. None of these is hard and fast "must do's", but if you don't understand why I recommend them, you probably shouldn't avoid them. I know how to use all but 8 & 9 to break into systems, and I am certainly not the only one. There are other considerations, but they are more specific and might give clues to someone wanting to know how to break into a system, so I won't go into detail here. -- Gene Spafford ----------------------------------------------------------------- >From: peo@pinocchio.Encore.COM (Paul Orman) Summary: NCSC a good place to start. Reply-To: peo@multimax.UUCP (Paul Orman) bill@carpet.WLK.COM (Bill Kennedy) writes: > [ I deleted what I wrote ] I certainly am not one of the "more seasoned System Administrators" but I do know a good place to start with system security is the: National Computer Security Center 9800 Savage Rd. Fort Meade, MD 20755-6000 301-688-8742 Call and ask for the "RAINBOW" package. This is slightly overkill since the NCSC normally sends this package out to hardware and software vendors wishing to have their products security "rated" by US Gov. standards and tons of the material deal with the security ratings, however it does have much information that can be applied directly to a UN*X based system. Other interesting reading on security issues would be "UNIX REVIEW" volume 6 number 2. Of special interest is the article "A loss of Innocence" by Patrick Wood. The information supplied in these sources should be more than enough to put together as secure a system as one desired (within present day limitations - of course). ............................................................................... Paul Orman - encore!peo | I don't know enough to speak for Sys Admin peo@multimax.ARPA | myself, let alone my employer. ENCORE Computer Corporation | ----------------------------------------------------------------- >From: pmech@oucsace.cs.OHIOU.EDU (Paul J. Mech) Summary: Specific place to look In article spaf@cs.purdue.edu (Gene Spafford) writes: > > 2) Allow NO accounts without passwords, including uucp. > One place to watch out for is that many systems come with a hardware-vendor maintainence uid, often with root permissions. I have broken into (in each case at the request of the system's owner) three separate systems (a VAX, a Tower, and an Isotron/OSI) with this approach, and if not granted root privileges immediately, gained root access within 5 min. This is a massive hole that frequently has not been clearly documented. Paul J. Mech ----------------------------------------------------------------- >From: rfarris@serene.CTS.COM (Rick Farris) Summary: How *do* you protect the root crontab? In article <167@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: >One of my neighbor sites was recently vandalized by an electronic >intruder. >On my system, for example, I did not have my root crontab restricted >enough and that's how the intruder got root privileges. >Bill Kennedy Internet: bill@ssbn.WLK.COM Darn! That's clever. I'll bet they did [ I omitted the technique ] eh? Awesome. How does one deal with this? I'd also like to pick up some more security tips. I would like to allow more shell accounts on my system, but I'm worried about security. I understand the concern for security, is there a mailing list or something where we could discuss these issues? Rick Farris rfarris@serene.cts.com voice (619) 259-6793 POB M KCBIW public access 259-7757 Del Mar CA 92014 ...!uunet!serene!rfarris serene.uucp 259-3704 ----------------------------------------------------------------- [I don't think that Dennis is volunteering to help any and everyone who calls and I have not had a complete enough problem description to take him up on the offer. I'm including his email note to report that there *are* seasoned people out there willing to help us. I have omitted contact information other than his email address. ] Feel free to call about unix security. I will do what I can. Dennis F. O'Brien Manager, Corporate Computer Security AT&T Bell Laboratories att!whutt!dob ----------------------------------------------------------------- >From terminus!nyssa Tue Oct 4 11:34:54 1988 remote from att Subject: Another simple security measure No problem. I forgot to mention something else: Check your uucp Permissions file; make sure that only /usr/spool/uucppublic is readable and writable for incoming uucp's. Also make sure that the only files you allow uuxqt to execute are rmail and rnews. Nasty unpleasantness can occur that way! James ----------------------------------------------------------------- Date: Mon, 3 Oct 88 06:18 CDT From: uunet!sialis.mn.org!rjg (Robert J. Granvin) You're going to hate it. People have written entire novels on Unix system security, and they all end up with the conclusion that it can never be completely done, unless (paraphrased quote from an ATT paper) "You remove all modems, lines and terminals from the computer and place it into armed guarded lead lined bunker with reinforced steel walls and doors." I'm not sure what I can do other than try to direct you to a good bookstore that carries a lot of Unix tech stuff and ATT manuals and start going through the indexes. There are lots of papers out there on security. For example, ATT has a two volume set of books out called "UNIX System: Reading and Applications" which is basically a collection of technical papers written by lots of people you'll recognize that just cover a whole multitude of topics, some of which is general security. One such paper covers what is good to implement, but also covers how some types of security actually can _help_ the intruder. I'll have to locate the books, but I believe the articles themselves are copyable, provided they're done in their entirety and aren't altered. If so, would you like me to photocopy and mail you what I have? (These dual volume also goes in to show you have "bad" crypt is, by telling you how to break it. Then shows how to improve it dramatically with a simple fix, and then shows you how to break THAT... Amusing... :-) There are supposedly books out there dedicated to just Unix level security as well, but I haven't looked very seriously for it... On the other hand, we've been internally working on general security for a long time... It's actually a never ending problem... The easiest thing to start with is make sure you keep an eye on logs, utilize group restrictions, even group and dialup passwords. Elminate _everything_ that uses SUID unless it absolutely positively has to have it, and if your shell allows SUID scripts, trash them. They end up being the worst. The hardest part of security is user-education... They're your weakest link... They leave terminals on, unattended, write down passwords, etc. Any open door anywhere is a problem... Add in ethernet, direct links, modems, etc etc etc. and you get a real fun time. You may also want to consider the options (if your system has it, or you replace the login program) to install a secure front end that allows root access only via console. While a serious possibility of inconvenience, it also could save you. I also had a script around, but trashed it in a booboo (easy enough to make again... It's about time I do anyways... I got another 1.6GB to go through)-: that searches the file system for anything "dangerous"... Such as SUID programs with unreasonable permissions (such as write permissions where it's not needed). You certainly don't want to do this search by hand, but rather just go through a list with a highlighter... I don't know if any of this helps... If I can provide you with anything, let me know. I'm certainly no expert... My system shows that :-), but we're devoted to beefing up our own security, and it's already taken a good chunk o' time... -Bob ----------------------------------------------------------------- From: Alan Strassberg <oetl1!alan> In article <167@carpet.WLK.COM> you write: > [ omitting what I wrote ] Well, I'm hardly a 'wizard' but here's some things I keep an eye out for: any program running SUID root is suspect. For example -rwsr-xr-x 1 root bin 194235 Sep 30 23:49 /usr/local/bin/kermit ^ Unless properly handled, one can shell escape from kermit and end up with an EUID of 0 (root). The root permissions are necessary to handle the /dev files. Solution (if you have source) Look for any fork/exec's to a shell escape and do: (BSD style) #ifdef SETUGID setegid(getgid()); /* Override 4.3BSD csh */ seteuid(getuid()); /* security checks */ #endif /* SETUGID */ For Sys V use setgid/setuid (and #define SETUGID). Similarly, shell escapes can gain system access if you're trying to hold someone out with 'rsh'. Simply invoke vi and :!csh could spawn a non-restricted shell. Hope this helps alan -- Alan Strassberg UUCP: ..!{pyramid,leadsv}!oetl!alan work (408) 425-6126 alan@oetl (alan@leadsv) ----------------------------------------------------------------- From: prc.unisys.com!ahr (Allan Rabenau) >................. I welcome all the email I got, I'm preparing a summary >for the net. The summary, like what I've read here so far, will contain >no technique, just preventative medicine. I agree, and if you cannot post to the net, would you please Email me your summation? We run two VAX700's, 55 Sun's, 6 Xerox LISP machines, 5 TI Explorers, 3 Symbolics, and heaven knows what else, all on a main ethernet connected to the VAX which is the main datacomm server (ARPANet, uucp etc.). There are multiple dial-ins on most machines, and almost all of the researchers here have home terminals. We run 24 hours a day, seven days a week. We already have had a call from our friendly FBI, saying "Your machine has been broken into", which scared the hell out of us. Our SA is relatively inexperienced, but an eager learner, and I sure would appreciate any hints that can be supplied. Thanks. ----------------------------------------------------------------- I am pleased and encouraged that this subject is getting some attention and I am very grateful to those more savvy than I for sharing the savvy. I'm also pleased that the security mailing lists are starting up again. With the increased availability of UNIX on more and smaller systems it's a problem we just can't avoid. I'll add a small epilogue. Some jerk has figured out that there is no password on the nuucp login at ssbn. He drops into uucico who eventually kicks him out, but that's still closer than I'd like. As soon as I can get each of my (legitimate) uucp neighbors on-stream with the new logins and passwords he won't even get that far. I'm more angry than concerned but I'm concerned enough to inconvenience every site that ssbn talks to... That's partially a complaint but it's also a worry. Is it possible to break out of uucico or to do anything within uucico other than uucp events? I don't think so, but I don't know. -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM
guy@auspex.UUCP (Guy Harris) (11/02/88)
>6) On many systems, "at" is a security hole. If no one uses it, >disable it. And beware if your system 1) supports "at" and 2) permits a user to give files away. Try submitting an "at" job; if the set-UID bit isn't set on the "at" job file, disable "at" even if somebody *does* use it. (I suspect few systems have this hole, though; it doesn't exist in the "at" that comes with S5R2 or later - I'd expect it only on systems that support giving files away, S5-style, but that have the V7/BSD "at".) >8) Keep a list of all setuid/setgid files on your system (use >"find", for instance). Keep the list off-line. Recheck it >periodically and see if any files have changed size or modification >time (or had those bits added or deleted). Also note that "ncheck", on many systems that have it, has a "-s" flag that lists special files (i.e., devices) and set-UID files; you might want to run this to make sure nobody's created any "back door"s to "/dev/mem", or their own set-UID programs. >10) On BSD systems, don't have any setuid/setgid shell scripts -- >unless you know that the security hole with them has been fixed >on your system. Umm, if you know of a fix for all the security holes, let us know; there are some that are fixed by various changes in 4.3BSD (as long as you put the right flag in the "#! /bin/sh" or "#! /bin/csh" line), but there's another one that's not so easy to fix - the only reliable fix that I've heard of requires an OS feature not present in most UNIX versions. Note also that even if this security hole *is* fixed, it's probably hard to write shell scripts that don't have other holes. For one thing, if you don't set IFS to "<space><tab><nl>" (the default value) first thing in the script if it's a Bourne shell script (yes, you can do this, even if IFS has been tampered with), and then set PATH or "path" right after that, the script will probably be easy to break. (Some versions of the Bourne shell may not import IFS, which closes that hole.) I'm sure there are other similar tricks that I don't even know about....