Subject: v21i025: System ecurity analysis tool, Part03/05 Newsgroups: comp.sources.unix Approved: rsalz@uunet.UU.NET X-Checksum-Snefru: 710f82a3 6669115e 5420b587 fcebd8f4 Submitted-by: Dan Farmer Posting-number: Volume 21, Issue 25 Archive-name: cops/part03 # This is a shell archive. # Remove everything above and including the cut line. # Then run the rest of the file through sh. #----cut here-----cut here-----cut here-----cut here----# #!/bin/sh mkdir cops 2>/dev/null mkdir cops/docs 2>/dev/null mkdir cops/src 2>/dev/null mkdir cops/extensions 2>/dev/null # shar: Shell Archiver # Run the following text with /bin/sh to create: # cops/rc.chk # cops/reconfig # cops/root.chk # cops/stop.sample # cops/suid.chk # cops/docs/COPS.report # cops/docs/KUANG.README # cops/docs/SUID.README # This archive created: Tue Jan 30 23:26:56 1990 # By: dan (Purdue University) echo shar: extracting cops/rc.chk '(1822 characters)' cat << \SHAR_EOF > cops/rc.chk #!/bin/sh # # Usage: rc.chk # # This checks pathnames and files inside the shell script files /etc/rc* # for writability. # # Mechanism: The commands inside the files /etc/rc* are executed when # the machine is booted. This shell script greps for commands/paths that # are of these forms: # # /path/command # or whatever # or # PATH=:/bin:/usr/bin:. # or whatever # or # MYVAR=`/path/command` # or whatever # # It then takes each potential problem-string and uses the program # "is_writable" to determine if it is world writable. All results are # echoed to standard output. # AWK=/bin/awk LS=/bin/ls TEST=/bin/test EGREP=/usr/bin/egrep ECHO=/bin/echo SORT=/usr/bin/sort # CHANGE THIS LINE OR PUT IN FILE NAMES IF/AS NEEDED! # (for example: init_files="/etc/rc /etc/rc.local") # init_files=`$LS /etc/rc*` # # This should get all paths in /etc/rc* files; at least two types here. # First type starts with a "/", the second is either in the form : # # PATH=:/bin:/usr/bin:. # or whatever # or # MYVAR=`/bin/echo "hello"` # or whatever # # # Notice also I strip out any references to /tmp, /usr/tmp, # /dev/*ty's, and /dev/null. first_pass=`$AWK '{for (i=1;i<=NF;i++) if ((index($i,"/")) && ((first=substr($i,1,1)!=">"))&& first!="#" && first!="$" && (last=substr($i,length($i),1))!="\"") print $i}' $init_files | $EGREP -v "/dev/.*ty|/tmp|/usr/tmp|/dev/null" | $SORT -u` all_files=`$ECHO $first_pass| $SORT | $UNIQ` # First, get the ones starting with "/": # # DANGER! DANGER! DANGER Will Robinson! Awk runs out of room ("bails # out") if too many files are here.... all_files=`$ECHO $first_pass|$AWK 'BEGIN{RS=FS}{if(substr($0,1,1)=="/")print $0}'` for i in $all_files do if ./is_writable $i then $ECHO "Warning! File $i (in /etc/rc*) is _World_ writable!" fi done # end of script SHAR_EOF echo shar: extracting cops/reconfig '(4535 characters)' cat << \SHAR_EOF > cops/reconfig #! /bin/sh # # Usage: reconfig # # This replaces the program paths (e.g. /bin/awk) in COPS with an # alternate path that is found in the file "file.paths". # All programs are renamed "name.old", and the new version replaces # the original name. It then uses sed to replace all occurances of # the target strings. # Basically, the program looks through all directories listed in # $all_dirs for the list of programs in $all_commands and when it finds # them, puts them in a sed source file. It then goes to all of the # shell files COPS uses ($shell_scripts) and replaces all occurances of # the variables found with the new value. It goes through some # contortions trying to look for test (it has to find test without # using test), and does some other not so smart things, but it seems # to get the job done. # shell is always here, isn't it? SH=/bin/sh # need these later TEST= AWK= SED= STRINGS= YPCAT= # Potential directories to find commands: all_dirs='/bin /usr/bin /usr/ucb /usr/local/bin' # First things first; are test and echo built-in shell commands? # Theory. If test is executed correctly and not found in the path # I set, then they should be built into the shell, right? PATH=/bin:/usr/bin for dir in $all_dirs do if test -f $dir/test then TEST=$dir/test break fi done # if not set, then set to default if test -z "$TEST" then TEST=test fi for dir in $all_dirs do if $TEST -f $dir/echo then ECHO=$dir/echo break fi done # if not set, then set to default if $TEST -z "$ECHO" then ECHO=echo fi # The sed filter file location=./file.paths # Target shell scripts in question: shell_scripts="makefile chk_strings cops dev.chk dir.chk file.chk cron.chk group.chk passwd.chk rc.chk root.chk suid.chk kuang init_kuang" # Target commands in question, sans those checked above: all_commands='cc nroff mkdir awk sed sh cat chmod comm mv date egrep cp expr find grep ls mail rm sort uniq' rest_of_them=' echo test' # make sure everything is here: for i in $shell_scripts do if $TEST ! -s $i then $ECHO ERROR -- Shell script $i not found! exit fi done # This finds the paths to any program used in COPS, then prints out # a sed filter to the file "file.paths" that is used by this shell # script to change all occurances of that command in the COPS system. # # For example, if sed is in /usr/bin, it will create a line that looks # like this: # # s.AWK=*$.AWK=/usr/bin/sed. # # This corresponds to the sed command substitute ("." is used as a # delineator instead of "/" because the strings will be containing # "/"'s) /usr/bin/sed in place of whatever was to the right of the # equal sign. This works because all commands are accessed by the # variable "$XYZ", where "XYZ" corresponds to the lowercase command # "xyz". And, of course, all command variables are set at the top # of each command file. # # First we need awk and sed if this shell script will work.... for dir in $all_dirs do if $TEST -f $dir/awk ; then AWK=$dir/awk fi if $TEST -f $dir/sed ; then SED=$dir/sed fi done if $TEST -z "$AWK" ; then $ECHO "Cannot find awk; awk is needed to run this shell script" exit 1 fi if $TEST -z "$SED" ; then $ECHO "Cannot find sed; sed is needed to run this shell script" exit 1 fi # zero out the file, then put in the real locations... $ECHO > $location for command in $all_commands do found=false for dir in $all_dirs do # if find the command in one of the directories, print string if $TEST -f $dir/$command then # this converts to upper case upper=`$ECHO $command | $AWK 'BEGIN{upper="ABCDEFGHIJKLMNOPQRSTUVWXYZ";lower="abcdefghijklmnopqrstuvwxyz";} \ {out = ""; for(i=1;i <= length($1);i++) { if((cpos = index(lower,c = substr($1,i,1))) > 0) c = substr(upper,cpos,1); \ out = out c; \ } printf("%s",out)}'` $ECHO "s-^$upper=.*\$-$upper=$dir/$command-" >> $location found=true break fi done if $TEST "$found" = "false" then $ECHO ERROR! $command not found! Change or delete command! exit fi done $ECHO "s-^ECHO=.*\$-ECHO=$ECHO-" >> $location $ECHO "s-^TEST=.*\$-TEST=$TEST-" >> $location # almost forgot -- we need chmod, mv too: for dir in $all_dirs do if $TEST -f $dir/mv ; then MV=$dir/mv fi if $TEST -f $dir/chmod ; then CHMOD=$dir/chmod fi done for i in $shell_scripts do $ECHO "Changing paths in $i..." $SED -f $location $i > $i.new $MV $i $i.old $MV $i.new $i # finally, make sure everything is back to executable status $CHMOD 700 $i done SHAR_EOF echo shar: extracting cops/root.chk '(3194 characters)' cat << \SHAR_EOF > cops/root.chk #!/bin/sh # # Usage: root.chk # # This shell script checks pathnames inside root's startup files for # writability, improper umask settings (world writable), non-root # entries in /.rhosts, and to ensure that root is in /etc/ftpusers. # Also check for a single "+" in /etc/hosts.equiv (world is trusted). # Startup files are /.login /.cshrc /.profile # # Mechanism: These files contain paths and filenames that are stripped # out using "grep". These strings are then processed by the "is_writable" # program to see if they are world writable. Strings of the form: # # path=(/bin /usr/bin .) # and # PATH=/bin:/usr/bin:.: # # are checked (using grep) to ensure that "." is not in the path. All # results are echoed to standard output. # For umask stuff, simply grep for umask in startup files, and check # umask value. For /etc/ftpuser, simple grep to check if root is in # the file. For /etc/hosts.equiv, just check to see if "+" is alone # on a line by awking it. # # AWK=/bin/awk SED=/bin/sed TEST=/bin/test ECHO=/bin/echo GREP=/bin/grep SORT=/usr/bin/sort EXPR=/bin/expr csh=/.cshrc sh=/.profile rhosts=/.rhosts big_files="/.login /.cshrc /.profile" ftp=/etc/ftpusers equiv=/etc/hosts.equiv # parse into separate paths: for i in $big_files do if $TEST -s $i then ./chk_strings $i # check for umask stuff (thanks to Bruce Spence): if umsk=`$GREP umask $i ` 2>/dev/null then mask=`$ECHO $umsk|$AWK '{if($2!=""){if(length($2)==1) print "00"$2; \ else if (length($2)==2) print "0"$2; \ else print $2} else print "000"}'` # perm=`$EXPR substr $mask 3 1` perm=`$ECHO $mask | $SED 's/[0-9][0-9]//'` if $TEST "$perm" -lt 2 -o "$perm" = 4 then if $TEST "$umsk" then $ECHO "Warning! Root's umask set to $umsk in $i" fi fi fi fi done # check to see if root is in ftpusers file if $TEST -s $ftp then if test ! `$GREP "root" $ftp` then $ECHO Warning! $ftp exists and root is not in it fi fi # check for a "+" in hosts.equiv. Bad. Bad dog. if $TEST -f $equiv ; then $AWK '{if (NF==1 && $1=="+") printf("Warning! A \"+\" entry in %s!\n", "'$equiv'")}' $equiv fi # check for non-root entries in /.rhosts #$AWK '{if ((NF==1&&!($1=="localhost" || $1=="root"))||(NR!=1&&$2!="root")) printf("Warning! Non root entry in %s! %s\n", $rhosts, $0)}' $rhosts # echo checking paths... { # # Get the root paths from $csh. if $TEST -f $csh; then $GREP path $csh | $AWK '{split($0,p1,"="); \ for (i=1;i<=NF;i++) { \ if (substr($i,1,1)=="/") { \ if (substr($i,length($i),1)!=")"){ print $i} \ else {print substr($i,1,length($i)-1)} \ } \ else if ($i ~ /^path/) {split($i,p2,"(");if (substr(p2[2],1,1)=="/") { \ print p2[2]}}} \ }' fi # # Get the root paths from $sh. if $TEST -f $sh; then $GREP PATH $sh | $SED 's/\(PATH=.*\);.*/\1/' | $AWK -F= '{split($2,temp,":"); \ for (i in temp) \ if (temp[i] == "") print "."; \ else print temp[i]}' fi } | $SORT -u | while read i do # check to see if "." is in path if $TEST "." = "$i" then $ECHO "Warning! \".\" is in roots path!" fi if ./is_writable $i then $ECHO "Warning! Directory $i is _World_ writable!" fi done # end of script SHAR_EOF echo shar: extracting cops/stop.sample '(644 characters)' cat << \SHAR_EOF > cops/stop.sample -rwsr-xr-x 1 root bin 10240 Jun 13 13:13 /bin/chgrp -rwsr-xr-x 1 root bin 12288 Jun 13 13:13 /bin/df -rws--s--- 1 root term 22528 Aug 13 13:13 /bin/login -rws------ 1 root bin 21504 Jun 13 13:13 /bin/login.old -rwsr-xr-x 1 root bin 22528 Jun 13 13:13 /bin/mail -rwsr-xr-x 1 root bin 14336 Jun 13 13:13 /bin/passwd -rwxr-sr-x 1 root MEM 22528 Jun 13 13:13 /bin/ps -rwsr-xr-x 1 root bin 16384 Jun 13 13:13 /bin/su -rwxr-sr-x 1 root MEM 14336 Jun 13 13:13 /etc/dmesg -rwsr-x--- 1 root operator 29696 Jun 13 13:13 /etc/dump SHAR_EOF echo shar: extracting cops/suid.chk '(2063 characters)' cat << \SHAR_EOF > cops/suid.chk #!/bin/sh # # Shell script intended to be run periodically by cron in order # to spot changes in files with the suid or sgid bits set. # # suid.chk 840919 Prentiss Riddle # # This changes into the $SECURE directory first, then # uses find(1) to search the directories in $SEARCH for all # files with the 4000 or 2000 permission bits set. $STOP is a file # containing "ls -lga" output for known setuid or setgid programs. # Any additions or changes to this list represent potential security # problems, so they are reported to the users named in $INFORM. # # Modified 8/15/89, Dan Farmer: # Just changed the program/doc names and some of the temp # files to make it fit in with the rest of the programs.... # # CHANGE THIS LINE! INFORM="foo@bar.edu" # TEST=/bin/test ECHO=/bin/echo SH=/bin/sh LS=/bin/ls CAT=/bin/cat MAIL=/bin/mail CHMOD=/bin/chmod SORT=/usr/bin/sort COMM=/usr/bin/comm FIND=/usr/bin/find RM=/bin/rm SECURE=. SEARCH=. STOP=./stop.sample TEMPOLD=./fsold$$ TEMPCUR=./fscur$$ TEMPNEW=./fsnew$$ TEMPGON=./fsgon$$ TEMPM=./fsm$$ umask 077 OLDCWD=`pwd` if $TEST ! -d "$SECURE" then $ECHO "Error -- Security directory $SECURE doesn't exist" exit 1 fi $CHMOD 700 $SECURE cd $SECURE # find the setuid programs and sort $FIND $SEARCH \( -perm -4000 -o -perm -2000 \) -exec $LS -lga {} \; | \ $SORT > $TEMPCUR # compare with the sorted stop list $SORT <$STOP >$TEMPOLD $COMM -13 $TEMPOLD $TEMPCUR | $SORT +8 >$TEMPNEW $COMM -23 $TEMPOLD $TEMPCUR | $SORT +8 >$TEMPGON # report changes if $TEST -s $TEMPNEW -o -s $TEMPGON; then HOSTNAME=`$SH -c "/bin/uname -n || /usr/bin/uuname -l || /bin/hostname" 2>&-` $ECHO '' >>$TEMPM if $TEST -s $TEMPNEW; then $ECHO 'These files are newly setuid/setgid:' >>$TEMPM $ECHO '' >>$TEMPM $CAT $TEMPNEW >>$TEMPM $ECHO '' >>$TEMPM fi if $TEST -s $TEMPGON; then $ECHO 'These files are no longer setuid/setgid:' >>$TEMPM $ECHO '' >>$TEMPM $CAT $TEMPGON >>$TEMPM fi $MAIL $INFORM <$TEMPM $RM -f $TEMPM fi $RM -f $TEMPOLD $TEMPCUR $TEMPNEW $TEMPGON # end it all.... exit 0 SHAR_EOF echo shar: extracting cops/docs/COPS.report '(33839 characters)' cat << \SHAR_EOF > cops/docs/COPS.report .ps 12 .vs 12 .PH ```` .pn .nr W 78 .ce 2 \fBCOPS and Robbers UN*X System Security\fP .sp .sp .PP In the last few years, computer security has received a great deal more attention than it has in the past. Computerized break-ins and criminal activity, once merely the product of the imagination of science fiction writers, has became a fairly common occurence in both commercial and academic circles. In this paper, I will go over the problems that face any multiuser computing system, then discuss how these problems apply to UNIX\** .FS Although originally designed and developed by Ken Thompson and Dennis Ritchie of AT&T, UNIX has grown far beyond its' original design and now numerous companies market their own \*Qflavor\*U of UNIX. When I use the term UNIX in this paper, I don't mean merely AT&T's version, but instead I mean the majority of the most popular varieties, made by developers at Berkely, Sun, and a host of other manufacturers. I believe UNIX is still a trademark of Bell Laboratories. .FE specifically, and finally present in detail a suite of programs that were developed in an attempt to address some of the main problems that could be solved via software. UNIX, although considered to be a fairly secure operating system ([Wood 88], [Duff 89], etc), has the advantage of having many published works ([Grampp and Morris 84], [Bishop 83], etc) on the problems that a computing site can have with security, and in addition, on how a UNIX system administrator might make his/her system more secure by monitoring various aspects of his/her UNIX site. This, combined with UNIX's popularity, make it an ideal target for a software security system to operate on. .PP In this report I am not going to discuss specific ways of breaking into a given UNIX machine (for a more detailed description on how to compromise UNIX security, see either [Baldwin88], [Bishop83], [Wood & Kochran 86], or [Grampp & Morris 84]) -- instead, I will concentrate on how to improve and strengthen the potentially good security of a generic UNIX system by means of a software toolkit that examines the weaker areas of UNIX that are either traditionally ignored (due to the time constraints or ignorance of the system administrators) or are simply reoccurring problems that need to be watched over. In addition, this report is not meant for UNIX neophytes -- although a great deal of proficiency is not needed to read this report and use the programs described herein, a familiarity with basic UNIX features -- the file system and file permission modes for example -- and commands such as .ul awk, grep, sed as well as a working knowledge of shell and C programming are necessary to understand the internal workings of the security system described in this paper. .PP Although there is no reasonable way that all security problems can be solved (at least not with a software solution) on any arbitrary UNIX system, administrators and system programs can be assisted by a software security tool. The Computer Oracle Password and Security system (COPS) that will be described in this paper is just such a device. The COPS system is a collection of programs and shell scripts that attempt to address as many of these problems as possible in an efficient, portable, and above all in a reliable and safe way. The main goal of COPS is one of prevention; it tries to anticipate and eliminate security problems by making sure people don't get a chance to compromise security in the first place. Alerting the administrators of a potential intruder or that a virus has infected the system is beyond the scope of the present system, although with work with such capabilities could be added ([Bauer and Koblentz 88] and [Duff 89].) .PP To understand the reason COPS might check any specific problem, a look at computer security problems in general is in order. The problems listed below are not meant to be inclusive, but they are indicative of the myriad types of dilemmas a typical computer multiuser system might encounter: .PP 1) Administrators, system programmers, and computer operators. The very people that (should) worry the most about security are sometimes the ones that are the least concerned. Carelessness is one of the main culprits; a mistake by a user might cause little or no problem, but when someone with no restrictions (or almost none) on their computer activity makes a mistake, a security hole can result. \*QI can trust my users\*U is a fine statement to make -- but can you trust your users' friends? How about the users of computers that are networked to yours? New software, systems, or procedures can facilitate extra problems; a computing staff is often ill or completely non-trained on new techniques and software. Too often \*QRTFM\*U is the only training that they will ever receive. Programs that are created for in-house use are often ill-documented and not debugged thoroughly, and when users other than the author start to use/abuse the program, problems can result. Especially misunderstood, even by experienced UNIX system programmers, is the SUID program or, worse yet, the SUID shell script ([Bishop 83].) When a user says that his/her password was forgotten (or any other account/security related problem), what checks are made to verify that the person is really the owner of that account? Are users that are security problems kept track of, so that repeated abuses of the system will result in punitive action? Does your site even have a security policy? And of course, the last straw is that most system administrators simply have too much other work to do than to constantly check the system for potential security flaws -- let alone to double-check that any work done by other system programmers has been done correctly. These are the actions that often get left unsaid and undone. .PP A UNIX environment has no special defenses against this kind of \*Qattack\*U. Fortunately, a number of these potential problems (unless catastrophic in scope) are not only correctable, but are easy to detect with a software toolkit such as COPS. Even the most careful UNIX guru will periodically make a mistake; COPS has been designed to aid in her/his never ending battle against the forces of darkness. .PP 2) Physical security. This is perhaps the most frustrating of all possible problems because it effects all computer systems and is often the hardest to safeguard against. Even if the software is secure, even if the system administrators are alert to potential problems, what happens if a user walks up to the root console and starts typing? Does the night janitorial staff let anyone into the machine room without proper identification? Who has access to the key that opens up the computing center? Are terminals that are logged on left unguarded or unlocked? Are passwords written on or near a users terminal or desk? No software in the world can help against human nature or carelessness. Reiterating to your staff and users that terminals should not be left alone or unguarded and that passwords (especially root) should not be typed in front of unfriendly (and in this case, _everyone_ is your enemy) eyes would be a good start. A simple analogy: since you would never give the keys to the company car away, why on earth would you give away the keys to your computer, which is certainly worth a hell of a lot more time and money (although it may not get as good mileage on the interstate.) Common sense goes a long ways to help prevent this kind of risk. .PP 3) Authentication. What is authentication? All modern computing systems that have capabilities for multiple users have a means of identifying who is using the computer at any given time. A common means of identification is by using a password; and since the inception of this idea, poor passwords have been a perennial problem. People have a tendency to use their own name, or their social security number, or some other common word, name, or phrase for a password. The problem then arises when an unauthorized user wants to access clandestine information, he/she simply tries one of these simple passwords until a successful match is found. .PP Other problems with authentication? What computer hosts are \*Qtrusted\*U and allow users to log in from other machines without any further authentication? Are incorrect login attempts kept and/or monitored so as to allow administrators to keep track of any unusual activity? What about \*QTrojan horses\*U -- programs that can steal passwords and the privileges that a user owns -- is there a program or a administrative method that detects a potential 'horse? .PP Fortunately UNIX systems again have some fairly good tools to aid in this fight. Although finding simple passwords is indeed a trivial task, forcing the users on a system to use passwords that are harder to guess is also trivial, by either modifying the mechanism that gets/gives the password to the user, and/or by having the system administrators run a simple password detector periodically, and notifying users if their password is deemed too obvious. The .ul crypt command, although proven to be insecure for a knowledgeable and resourceful attacker ([Reed and Weinberger 84], [Baldwin 86]), does offer an added shield against most unauthorized users. Logs can be kept of incorrect login attempts, but as with most security measures, to be effective someone (usually the site administrator) must take the time to examine the evidence. .PP 4) Bugs/Features. Massive software designs (such as an operating system) are usually the result of a team or of teams of developers working together. It only takes one programmer to make a mistake, and it will almost always happen. \*QBack doors\*U that allow unauthorized entrances are sometimes purposefully coded in -- for debugging, maintenance, or other reasons. And there are always unexpected side effects when thousands of people using the system start doing strange (stupid?) things. The best kind of defense against this is to report the problems to the developer as they are discovered, and if possible, to also report a way to fix the problem. Unfortunately, in many cases the source code is needed to make a bug fix, and especially in non-academic areas, this is simply not available due to the prohibitive costs involved. Combining this with the reluctance of a (usually) commercial developer to admit any problems with their product, and the end result is a security hole that will not be mended unless some kind of financial loss or gain is at stake -- for the developer of the product, not yours! .PP 5) Ignorance. Users who don't know or care can be a problem as well. Even if someone doesn't care about their own security, they can unwittingly compromise the entire system -- especially if they are a user with high privileges. Administrators and system operators are not immune to this either, but hopefully are better informed, or at least have access to a means of combating this dysfunction. It may also be due to apathy, an unwillingness to learn a new system, a lack of time to explore all of the features of a large system, or simply not enough computer savvy to learn more about a very complex system, and no one willing to teach it to the user. This problem is much like illiteracy; it is a never-ending battle that will never go completely away. And while a software toolkit such as COPS can help combat this problem by calling attention to neglected or misunderstood critical areas, by far and away the best weapon against this is education. An educated user will simply not make as many mistakes; and while it may seem impractical to teach _all_ users about (even) the fundamentals of computer security, think of all the time and resources wasted tracking down the mistakes that keep recurring time and time again. .PP 6) Unauthorized permissions or privileges. Are users given _too much_ freedom? Do new computer accounts have any default security at all, or are the new users expected to know what to do to protect their programs, data, and other files. System files, programs, and data are sometimes shipped with minimal or no protection when gotten straight from the manufacturer; someone at the installation site must have enough knowledge to \*Qtune\*U the system to be effective and safe. Password, memory, and log files especially should all be carefully monitored, but unfortunately an experienced user can often still find out any information they want with perseverance and a little luck. This is where a system such as COPS can really shine. After a new system is configured, some basic flaws can be uncovered with just a small amount of effort. New system problems that somehow slip through the cracks of the site installers can be caught and modified before any serious problems result. The key here is to prevent your system users from getting a denial of computer service that they need and deserve. Service could mean anything from CPU time, response time, file space, or any other commodity that a computer has to offer. .PP 7) Crackers/Hackers/Evil twin brothers. Not much is needed on this subject, save to say that they are often not the main problem. Professional evil-users are a rarity; often harmful acts are done by users who \*Qjust wanted to see what would happen\*U or had no idea of the ramifications of their acts. Someone who is truly experienced is very difficult to stop, and is certainly outside the realm of any software security tool as discussed in this paper. Fortunately, most evil-doers are fairly inexperienced and ignorant, and when they make a mistake, a watchful administrator can deal with a problem before it gets out of hand. Sometimes they can even reveal security problems that were previously undiscovered. COPS can help here mostly by reducing an attacker's options; the less holes to exploit, the better. .PP The COPS system attempts to help protect as many of the above items as possible for a generic UNIX system. In the proper UNIX spirit, instead of having a large program that attempts to solve every possible problem, it is composed of several small programs that each check one or more potential UNIX security holes. The COPS system uses a variety of these problems to see if there are any cracks in a given UNIX security wall. These methods correspond to some of the problems discussed above; specifically to administrators, system programmers, and computer operators; authentication; ignorance; unauthorized permissions or privileges; and finally crackers/hackers/evil twin brothers (numbers 1,3,5, and 6.) It is very difficult, almost a practical impossibility to give software assistance to problems in physical security, and finally bugs or features that are present in a given UNIX system are possible to detect, but are not covered in this system (yet). The design of most of the the programs were at least described if not outlined from the following sources: .sp Aho, Kernighan, and Weinberger 88 .sp Baldwin 87 .sp Fiedler and Hunter 86 .sp Grampp and Morris 84 .sp Wood and Kochran 86 .sp .PP Of course with all of the problems listed below, looking at the actual source code of the program is very instructive -- each numbered section lists the corresponding program that is used to perform the check: .PP 1) COPS Checks \*Qvital\*U system directories to see if they are world-writable. Directories listed as critical are in a configuration file and are initially: .sp / /etc /usr .sp /bin /Mail /usr/spool .sp /usr/adm /usr/etc /usr/lib .sp /usr/bin /usr/etc /usr/spool/mail .sp /usr/spool/uucp /usr/spool/at .PP The method COPS uses to detect problems -- read through a configuration file (dir.chklst) containing all of the potential danger spots, and then simply comparing each directory modes with a bit mask to see if it is world writable. The program that performs this task is .ul dir.chk .PP 2) Check \*Qvital\*U system files to see if they are world-writable. Files listed as critical are in a configuration file (file.chklst) and are initially: .sp /.* .sp /etc/* .sp /bin/* .sp /usr/etc/yp* .sp /usr/lib/crontab /usr/lib/aliases /usr/lib/sendmail .sp .sp The wildcards are used like in UNIX, so these would include (some of the more important files): .sp /.login /.profile /.cshrc /.crontab /.rhost .sp /etc/passwd /etc/group /etc/inittab /etc/rc .sp /etc/rc.local /etc/rc.boot /etc/hosts.equiv /etc/profile .sp /etc/syslog.conf /etc/export .sp As well as the executable command files (among others): .sp .ul sh, csh, and .ul ls. .sp .PP Method -- again read through a configuration file listing all of the files to be checked, comparing each in turn with a write mask. The program that performs this task is .ul file.chk .PP 3) Check \*Qvital\*U system files to see if they are world-readable, plus check for a NFS file system with no restriction. These critical files are: .sp /dev/kmem /dev/mem .sp All file systems found in /etc/fstab .sp Plus a small number of user selectable files -- initially set to include /.netrc, /usr/adm/sulog, and /etc/btmp. .sp Method -- checking each in turn against a read mask for their read status. The file system names are read from /etc/fstab, the selectable files are kept in a variable. The program that performs this task is .ul dev.chk .PP 4) Check all files in system for SUID status, notifying the COPS user of any changes in SUID status. .sp Method -- Use the "find" command on the root directory (this must be done by root to avoid missing any files unreadable but still dangerous.) The previous run will create a file that can be checked against the current run to keep track of changes in SUID status and any new SUID files. The program that performs this task is .ul suid.chk and was written by Prentiss Riddle. .PP 5) Check the /etc/passwd file (and the yellow pages password database, if applicable) for null passwords, improper # of fields, non-unique user-id's, non-numeric group id's, blank lines, and non-alphanumeric user-id's. .sp Method -- Read through password file, flag any differences with normal password file, as documented in \*Qman 5 passwd\*U. Fortunately, the syntax of the password file is relatively simple and rigid. The program that performs this task is .ul passwd.chk .sp .PP 6) Check the /etc/group file (and the yellow pages database, if applicable) for groups with passwords, improper # of fields, duplicate users in groups, blank lines, and non-unique group-id's. .sp Method -- Read through group file, flag any differences with normal group file as documented in \*Qman 5 group\*U. Again, the syntax of this file is fairly simple. The program that performs this task is .ul group.chk .PP 7) Check passwords of users on system. .sp Method -- using the stock \*Qcrypt\*U command, compare the encrypted password found in the /etc/passwd file against the following (encrypted) guesses: .sp The login id (uid), information in the gecos field, and all single letter passwords. .sp The program that performs this task is .ul pass.chk and was written by Craig Leres and was modified by Seth Alford, Roger Southwick, Steve Dum, and Rick Lindsley. .PP 8) Check the root path, umask, and if root is in /etc/ftpuser. .sp Method -- look inside the /.profile and /.cshrc files to ensure that all of the directories listed are not world writable, that \*Q.\*U isn't anywhere in the path, and that the umask is not set to create world writable files. The program that performs this task is .ul root.chk .PP 9) Examine the commands in /etc/rc* to ensure that none of the files or paths used are world-writable. .sp Method -- grep through the files and examine any strings that start with \*Q/\*U for writability. The program that performs this task is .ul rc.chk .PP 10) Examine the commands in /usr/lib/crontab to ensure that none of the files or paths used are world-writable. .sp Method -- grep through the crontab file and examine any strings after field five (first five are not files, but how crontab is to be run) that start with \*Q/\*U for writability. The program that performs this task is .ul cron.chk 11) Check all of the user home directories to ensure they are not world writable. .sp Method -- get all of the home directories using the system call .ul getpwent() and then for every home directory found, check the write permissions of of the home directory against a bit mask. The program that performs this task is .ul home.chk and it was written by John Owens. .PP 12) Check important user files in user's home directories to ensure they are not world writable. The files checked (all in the individual users' home directory, all with the prefix \*Q.\*U): .sp rhost profile login cshrc kshrc tcshr crhost .sp netrc forward dbxinit distfile exrc emacsrc .sp Method -- using the same system call as #10, determine user home directory. Then simply check all of the above files against a bit mask. The program that performs this task is .ul user.chk .PP 13) Given a goal to compromise, such as user root, and a list of user and group id's that can be used in an attempt to achieve the goal, this security tool will search through the system until it verifies that the goal is compromisible or not. The program that performs this tricky task is part of the .ul U-Kuang (rhymes with \*Qtwang\*U) system. Robert Baldwin was kind enough to allow me to include this security checker (a fine security machine in it's own right) within this distribution. For more information on this fascinating security checker, see kuang.man.ms and [Baldwin 87]. I have rewritten it in Bourne shell (it was in C-Shell) for further portability. .PP None of programs listed above certain cover all of the possible areas that can harm a system, but if run together they can aid an overworked administrator to locate some of the potential trouble spots. The COPS system is not meant to be a panacea against all UNIX security woes, but an administrator who examines the security toolbox programs and this research paper might reduce the danger of their UNIX system being compromised -- and that's all any security tool can ever hope to do. The COPS system could never replace a vigilant administration staffed with knowledgeable people, but hopefully, as administrators look into the package, more comprehensive programs will come into being, covering more of the problems that will continue as the latest versions of UNIX continue to grow. .PP Design Notes: .PP The programs that are described here were designed to address the problems discussed above, but still be usable on as many UNIX \*Qflavors\*U as possible. Speed was sacrificed for simplicity/portability; hopefully the tools here will either be replaced or modified, as by no means are they the final word or solution to _any_ of these problems; indeed, it is my hope that after other programmers/administrators see this report, they will create newer, better, and more general tools that can be re-distributed periodically. None of the programs need to be run by root to be effective, with the exception of the SUID checker (to ensure that all files are checked.) Some of the tools were written by myself, the others were written by other programmers on the network and (with their permission) presented here. All of the programs in this report are in the public domain, with the exception of Robert Baldwin's U-Kuang system; they all exist solely to be used and modified to fit your needs. If they are re-distributed, please keep them in their original form unless it is clearly stated that they were modified. Any improvements (that might not be too hard :-), suggestions, or other security programs that you would like to see get further distribution can be sent to: .PP df@medusa.cs.purdue.edu .PP (That's me) .PP or .PP spaf@uther.cs.purdue.edu .PP (Dr. Eugene Spafford) .PP Note that the COPS system is still in an infancy stage -- although it has been tested on a variety of computers at Purdue, it has not undergone any serious trials. .PP Enhancements I envision include: .sp i) Improved speed and portability without sacrificing functionality (pretty obvious, I guess....) .sp ii) A level of severity assigned to each warning; anything that could compromise root instantly (root having no password, for example) might have a level 0 priority, while simply having a user with a writable home directory might only be level 3. This way the system could be run at a certain threshold level, or simply have the set of warnings prioritized for a less sophisticated administrator. .sp iii) Better handling of SUID programs. The current program needs more work to be done on it to be run effectively by most people; many will not be willing to put the time needed to go through the list of SUID files by hand to decide if they are needed or not. Perhaps also an alarm would sound if a shell script is SUID; doubly so if root owned. .sp iv) A CRC checker that would check a file system (possibly just the most important programs (such as this :-)) and report if any of the executable files were changed -- possibly signalling a viral infection. .sp v) The eradication of any design flaws or coding errors that are in the COPS system. .PP The main purpose of creating the COPS system was twofold; the first was to foster an understanding of the security problems common to most UNIX systems, and the second was to try to create and apply software tools that, when run, will inform system administrators of potential problems present in their system. No attempt is made by the tools to correct any problems because a potential security problem at one site may be standard policy/practice at another. An emphasis on furthering education and knowledge about UNIX in general is the key to good security practices, not following blindly what an unintelligent tool might say. .PP Some of the advantages to using a system such as COPS are: .sp i) Nearly Continuous monitoring of traditional problem areas. .sp ii) A new system can be checked before being put into production. .sp iii) New or inexperienced administrators can not only stop some of their problems in security they may have, but can also raise their consciousness about the potential for security dilemmas. .PP And a couple of disadvantages: .sp i) An administrator could get a false sense of security from running these programs. Caveat emptor (ok, they are free, but still beware.) .sp ii) A specific path to the elimination of the problem is not presented. This could also be construed as an advantage, when considering the third point. .sp iii) Badguys can get these tools. You know -- the guys with black hats. What happens when they get a copy of this package? With any sensitive subject like security, knowledge is zealously guarded. People are afraid that absolute knowledge corrupts -- who knows, they may be right. But I staunchly stand by the tree of knowledge. Let the bad guys taste the fruit, and they may see the light, so to speak. In addition, the system does not say how to exploit the hole, just that it exists. .PP .ul Results of Running COPS: .PP Not surprisingly, the results when COPS was run varied significantly depending on what system and site it was run on. Here at Purdue, it was run on a Sequent Symmetry running DYNIX 3.0.12, on a pair of Suns (a 3/280 and 3/50) running UNIX 4.2 release 3.4, a VAX 11/780 running 4.3 BSD UNIX, a VAX 8600 running Ultrix 2.2, and finally a NeXT machine running their 0.9 O/S version of UNIX. The results of the COPS system showed a reasonable amount of security concern on all of the machines; the faculty only machines showed the weakest security, followed by the machines used by the graduate students, and finally the undergraduate machines had the strongest security (our administrators _know_ that you can't trust those (us?) young folks.) Whether this was showing that Purdue has a good administration, or that the UNIX vendors have a fairly good grasp on potential security problems, or if it was merely showcasing the shortcomings of this system wasn't clear to me from the results. .PP The security results probably will vary significantly from machine to machine -- this is not a fault of UNIX; merely having the same machine and software does not mean that two sites will not have completely different security concerns. In addition, different vendors and administrators have significantly varying opinions on how a machine should be set up. There is no fundamental reason why any system cannot pass all or nearly all of these tests, but what is standard policy at one sites may be an unthinkable risk at another, depending upon the nature of the work being done, the information stored on the computer, and the users of the system. .PP When I first started researching this report, I thought it would be a fairly easy task. Go to a few computing sites, read some theoretical papers, gather all the programs everyone had written, and write a brief summary paper. But what I found was an tremendous lack of communication and concerted effort towards the subject of security. AT&T had written a couple of programs ([Kaplilow and Cherepov 88], as had Hewlett Packard ([Spence 89]), but they were proprietary. I heard rumors that the government was either working on or had such a security system, but they certainly weren't going to give it to me. The one book devoted to UNIX security ([Kochran and Wood 86]) was good, but the programs that they presented were not expansive enough for what I had in mind, plus the fact that they had written their programs mostly based on System V. And while most system administrators I talked to had written at least a shell script or two that performed a minor security task (SUID programs seemed the most popular), no one seemed to exchange ideas or any their problems with other sites -- possibly afraid that the admission of a weakness in their site might be an invitation to disaster. There is an excellent security discussion group on the network ([Various Authors 84-]), from which I received some excellent ideas for this project, but it is very restrictive to whom it allows to participate. I hope that with the release of this security system it will not only help stamp out problems with UNIX security, but would encourage people to exchange ideas, programs, problems and solutions to the computer community at large. Dan Farmer September 29, 1989 .PP .ul Acknowledgements: I would like to thank Eugene Spafford for his invaluable help in the researching, planning, and development of this project. Without the writings and programs created by Robert Morris, Matt Bishop, and other capable UNIX programmers, this project could never have gotten off the ground. Thanks also go to Brian Kernighan, Dennis Ritchie, Donald Knuth, and Ken Thompson, for such inspirational computer work. And of course without Peg, none of this would have come into being. Thanks again to all of you. .bp .ce .ul BIBLIOGRAPHY .sp _, UNIX Programmers Manual, 4.2 Berkeley Software Distribution, Computer Science Division, Department of Electrical Engineering and Computer Science University of California, Berkeley, CA, August 1983. .sp _, DYNIX(R) V3.0.12 System Manuals, Sequent Computer Systems, Inc., 1984. .sp Aho, Alfred V., Brian W. Kernighan, and Peter J. Weinberger, The AWK Programming Language, Addison-Wesley Publishing Company, 1988. .sp Authors, Various, UNIX Security Mailing List/Security Digest, December 1984 -. .sp Baldwin, Robert W., Crypt Breakers Workbench, Usenet, October 1986. .sp Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987. .sp Bauer, David S. and Michael E. Koblentz, NIDX - A Real-Time Intrusion Detection Expert System, Proceedings of the Summer 1988 USENIX Conference, Summer, 1988. .sp Bishop, Matt, Security Problems with the UNIX Operating System, Department of Computer Sciences, Purdue University, January 31, 1983. .sp Bishop, Matt, How to Write a Setuid Program, April 18, 1985. .sp Denning, Dorothy, Cryptography and Data Security, Addison-Wesley Publishing Company, Inc, 1983. .sp Duff, Tom, Viral Attacks On UNIX System Security, Proceedings of the Winter 1988 USENIX Conference, Winter, 1988. .sp Fiedler, David and Bruce Hunter, UNIX System Administration, Hayden Book Company, 1986. .sp Grampp, F. T. and R. H. Morris, "UNIX Operating System Security," AT&T Bell Laboratories Technical Journal, October 1984. .sp Kaplilow, Sharon A. and Mikhail Cherepov, "Quest -- A Security Auditing Tool," AT&T Bell Laboratories Technical Journal, AT&T Bell Laboratories Technical Journal, May/June 1988. .sp Morris, Robert and Ken Thompson, "Password Security : A Case History," Communications of the ACM, November 1979. .sp Reed, Brian, "Reflections on Some Recent Widespread Computer Break-ins," Communications of the ACM, vol. Vol 30, No. 2, February 1987. .sp Reed, J.A. and P.J. Weinberger, File Security and the UNIX System Crypt Command, Vol 63, No. 8, AT&T Bell Laboratories Technical Journal, October 1984. .sp Smith, Kirk, Tales of the Damned, UNIX Review, February 1988. .sp Spafford, Eugene H., The Internet Worm Program: An Analysis, Purdue Technical Report CSD-TR-823, Nov 28, 1988. .sp Spafford, Eugene H., 1989. Private Communications .sp Bruce Spence, spy: A UNIX File System Security Monitor, Workshop Proceedings of the Large Installation Systems Administration III, September, 1988. .sp Stoll, Clifford, Stalking the Wily Hacker, Volume 31, Number 5, Communications of the ACM, May 1988. .sp Thompson, Ken, Reflections on Trusting Trust, Volume 27, Number 8, Communications of the ACM, August 1984. .sp Wood, Patrick and Stephen Kochran, UNIX System Security, Hayden Books, 1986. .sp Wood, Patrick, A Loss of Innocence, UNIX Review, February 1988. SHAR_EOF echo shar: extracting cops/docs/KUANG.README '(886 characters)' cat << \SHAR_EOF > cops/docs/KUANG.README The U-Kuang system is currently setup in a minimum configuration; e.g. it assumes only that world modes/permissions are to be used. To fully use the system, if the password checkers and the home-directory checker come back with any positive results (i.e. with an account that can be broken), modify the init_kuang file to reflect this. To use this system to it's full capabilities, be sure to read the manual, kuang.man.ms. This directory contains the various programs and shell scripts that make up the Kuang security checking system. The file, kuang.man.1, documents the system in the style of a UNIX manual page. The file, kuang.mss, is a draft of a paper on this system. To run the system: 0. Execute 'make' to build the programs. 1. Read kuang.man.1 2. Modify the file, init_kuang, to set the initial set of privileges. 3. Execute "sh kuang" (or run the COPS system.) SHAR_EOF echo shar: extracting cops/docs/SUID.README '(501 characters)' cat << \SHAR_EOF > cops/docs/SUID.README Findsuid is a little utility we dreamt up to watch for potential Trojan horse programs by keeping an eye on our suid and sgid files and telling us when they change unexpectedly. We run it using the following line in crontab: 40 3 * * * /etc/findsuid/findsuid >/etc/findsuid/fserror 2>&1 Included here is the findsuid shell script, a man page, a makefile, and a sample "stop" file. --- Prentiss Riddle ("Aprendiz de todo, maestro de nada.") --- {ihnp4,harvard,seismo,gatech,ctvax}!ut-sally!riddle SHAR_EOF # End of shell archive exit 0