CyberSoft White Papers
The Sun Observer, Volume 10 No.3 March 1996
Notice: Copyright December 18, 1995 by Peter V. Radatti, All rights reserved.
Since security is always a hot topic with Unix users the next few articles will deal with getting started with Unix security issues. One of the biggest bang- for-the-buck security tools available, at any cost, is the COPS software package. COPS is copyright by Dan Farmer but he provides it free to anyone who wants to use it. Copies are available on the Internet and other sources. If you can't find a copy then send me an email and I will send you a copy by return email. The problem with COPS is that it is intimidating to people who are just getting started and those are the people who most often need to use it. This article will attempt to overcome this road block by demonstrate how to compile, execute and understand some of the output from COPS. The article is not intended to be a replacement for the manual which is always provided on-line with the software however once you have read this article the manual will not be so imposing.
COPS is always distributed in source code. Never accept compiled versions of the program since they may contain viruses or Trojan horses. The source code itself may be infected and you should always get your source code from a known site such as the CERT or CyberSoft. CyberSoft receives it's copies of COPS directly from Dan Farmer and provides a certificate of traceability back to the author. Once you have the source code look it over to see if there is anything strange about it. If you have a copy of the VFind virus scanner for Unix then scan the source code and the executables once they have been created. The combination of getting the source from a known site, manually reviewing the code and scanning it with a virus scanner is about the best that can be done to insure that the copy you received was not tampered with.
Once you have the package on your disk and unpack it into a directory the first step is to compile it. Since most System Administrators belong to the "Anything Goes School Of System Administration" and don't believe in reading the manual this may be an ideal demonstration. Make sure you read the "makefile" prior to attempting to compile in order to set any options that may be necessary. Start by entering the COPS directory and looking at the files there. This should appear as:
egate% cd cops_104+
egate% ls
MANIFEST* bug.chk.svr4* extensions/
passwd.chk*
README.1 bug_cmp* extra_src/
patchlevel.h*
README.2.pl carp/ ftp.chk* perl/
README.2.sh checkacct/ gen_fix
platform*
README.3 chk_strings* group.chk*
quick_start*
README.FIRST cops*
init_kuang* rc.chk*
XTRA_CREDIT* cops_filter is_able.chk*
reconfig*
bug.chk* cover_letter* is_able.lst* res_diff*
bug.chk.aix* crc.chk* kuang* root.chk*
bug.chk.apollo* crc_list* kuang.pl.shar* src/
bug.chk.dec* cron.chk* makefile*
suid.chk*
bug.chk.next* dev.chk* misc.chk* suid.stop*
bug.chk.sgi* disclaimer* pass.words* yp_pass.chk*
bug.chk.sun* docs/ pass_diff.chk*
Notice the file named "makefile". This file contains the instructions to the "make" utility which will do all of the work of compiling for us. When ever you see a makefile you have a good chance of compiling without worry. At the command prompt enter the command "make" and watch the messages that appear. If there are any error message, note them but allow the program to continue. If the "make" continues to the end without aborting then the program should run.
egate% make
/bin/cc -O -o home.chk src/home.chk.c
/bin/cc -O -o user.chk src/user.chk.c
/bin/cc -O -Dcrypt=fcrypt -DFCRYPT -o pass.chk src/pass.c \
src/crack-fcrypt.c src/crack-lib.c
src/pass.c:
src/crack-fcrypt.c:
src/conf.h: 100: FCRYPT redefined
src/crack-lib.c:
src/conf.h: 100: FCRYPT redefined
Linking:
/bin/cc -O -DWRITABLE -o is_writable src/is_something.c
/bin/cc -O -o crc src/crc.c
/bin/cc -O -o crc_check src/crc_check.c
/bin/cc -O -o addto src/addto.c
/bin/cc -O -o clearfiles src/clearfiles.c
/bin/cc -O -o filewriters src/filewriters.c
/bin/cc -O -o members src/members.c
/bin/cc -O -o tilde src/tilde.c
/bin/cc -O -o is_able src/is_able.c
/bin/chmod u+x chk_strings root.chk dev.chk cron.chk is_able.
chk cops group.chk rc.chk passwd.chk ftp.chk crc.chk misc.chk
suid.chk kuang init_kuang reconfig res_diff yp_pass.chk bug.chk
bug.chk.aix bug.chk.apollo bug.chk.dec bug.chk.next bug.chk.sgi
bug.chk.sun bug.chk.svr4 bug_cmp platform
If the compile did not go well then try executing the command "./reconfig" and try again. Next it is necessary to configure COPS. Using the editor of your choice, (it should be "vi" if you have been reading these articles) edit the file "cops". Look for the "SECURE=" lines which you will have to edit.
######################
# Change these lines!
######################
SECURE=/usr/foo/bar
SECURE_USERS="foo@bar.edu"
######################
% vi cops
Edit the "SECURE=/usr/foo/bar" line to the location of where the COPS files are located. Since I always intend to be in the COPS directory when I execute it I make this the current working directory, aka "./". The "SECURE_USERS="foo@bar.edu" is going to be you. Do not use my user id!
###################### # Change these lines! ######################
SECURE=./ SECURE_USERS="radatti@cyber.com" ######################
Once you have completed these edits it is time to try running the program. I like using the "-v" and the "-m E-mail address" options. The email address is the address that the report will be sent to. Prior to executing the program it is necessary to read the files "README.FIRST" and "quick_start". They are short, easy to read and informative. Here is an example of my executing COPS and looking at the process status table to make user that is running. Finally, you don't need "root" access to run COPS but you may get a better look at your system if you execute it from the "root" account.
egate% ps
PID TT STAT TIME COMMAND
14033 p0 IW 0:03 -csh (csh)
14937 p0 S 0:15 script
14938 p0 S 0:22 script
14939 p1 IW 0:03 -h -i (csh)
16269 p1 S 0:11 script
16270 p1 S 0:14 script
16271 p2 IW 0:04 -h -i (csh)
18972 p2 S 0:02 script
18973 p2 S 0:03 script
18974 p3 S 0:01 -h -i (csh)
19631 p3 S 0:00 /bin/sh cops -v -m radatti@cyber.com
19640 p3 R 0:00 ps
19654 p3 R 0:00 /bin/test ! -s kuang
% cops -v -m radatti@cyber.com &
[1] 19631
At this point it's time to have lunch or go do something else while COPS chugs away for the next few hours to several hours. Once COPS has finished you need to examine the output for problems. Here is the output from the example run. I edited out stuff that was too repetitive so this is not the exact report but will do as an example. My example was run on an old, faithful and favorite Sun 3/50 system executing SunOS 4.1.1. The report was returned to me in email so the report has an email header. It then identifies itself as a "SECURITY REPORT" and then shows the date, time and system that it was run on.
From radatti Wed Nov 29 21:09:35 1995
Return-Path:
Received: by cyber.com (4.1/SMI-4.1)
id AA23087; Wed, 29 Nov 95 21:09:33 EST
Date: Wed, 29 Nov 95 21:09:33 EST
From: radatti (Pete Radatti)
Message-Id: <9511300209.aa23087@cyber.com>
Apparently-To: radatti@cyber.com
Status: R
ATTENTION:
Security Report for Wed Nov 29 21:09:30 EST 1995
from host egate
The "root.chk" tests found a problem on the system.
The "/usr/etc" directory should be owned by the "root"
user and it is not. This is a serious problem and can be an indicator of a hacker
in the system. The problem can be solved using the "chown" command.
The "+" sign in the "/etc/hosts.equiv" shows that the
NIS, (formally yellow pages) is referenced on this system. Since it is very easy
to take over a system that is referencing NIS you need to make a policy decision
as to correct this problem or not. Finally, the CWD, "." is in the path
for root. This is a very bad idea since it the way many hackers get the "root"
user to execute Trojanized commands that allow them to enter a back door on the system.
Always remove "dot" and "dot-dot" from the "path"
of the "root" user.
**** root.chk ****
Warning! Root does not own the following file(s): /usr/etc
Warning! A "+" entry in /etc/hosts.equiv!
Warning! "." (or current directory) is in roots path!
Next we found that a number of directories are world writable. Some of these directories may be world writable by design and you will have to determine for yourself if it needs correcting. If you ever see anything like "/etc" in this list then you need to start worrying because this is an indication of big problems.
**** dev.chk ****
**** is_able.chk ****
Warning! /usr/spool/mail is _World_ writable!
Warning! /etc/aliases.dir is _World_ writable!
Warning! /etc/aliases.pag is _World_ writable!
Warning! /etc/motd is _World_ writable!
Warning! /etc/mtab is _World_ writable!
Warning! /etc/remote is _World_ writable!
Warning! /etc/rmtab is _World_ writable!
Warning! /etc/sm is _World_ writable!
Warning! /etc/sm.bak is _World_ writable!
Warning! /etc/state is _World_ writable!
Warning! /etc/syslog.pid is _World_ writable!
Warning! /etc/tmp is _World_ writable!
Warning! /etc/utmp is _World_ writable!
Next we found that the file "/etc/motd" is world writable. This problem was easy to correct using the "chmod" command. There were also a number of home directories that were world writable. In my case these are dummy accounts used as place holders. The "/tmp" directory is suppose to be world writable and is not normally used as a home directory. This is not a problem since these accounts were created as disabled.
Next COPS checks the password file to see if there are any problems. There were a few problems found. There is no password set for the user ids "sync". Since this is a privileged account someone may attempt to replace the "/bin/sync" program with a shell program then login using this user id. The hacker would then have full access to the system. COPS also found the that the "sysdiag" and "sundiag" are superuser accounts but are not the "root" account. This is not a problem since these accounts need to be superuser and are disabled someone logging in as them. Finally, there is a warning that the user id "cypher-research" is more than 8 characters long.
**** passwd.chk ****
Warning! Password file, line 11, no password:
sync::1:1::/:/bin/sync
Warning! Password file, line 12, user sysdiag has uid = 0 and is not root
sysdiag:*:0:1:Old System
Diagnostic:/usr/diag/sysdiag:/usr/diag/sysdiag/sysdiag
Warning! Password file, line 13, user sundiag has uid = 0 and is not root
sundiag:*:0:1:System
Diagnostic:/usr/diag/sundiag:/usr/diag/sundiag/sundiag
Warning! Password file, line 18, uid cypher-research > 8 chars
cypher-research:*:103:10:Email Place Holder:/net-2/vfind:/bin/csh
**** user.chk ****
**** misc.chk ****
The next few problems reported are very serious. The version of the "uuencode" command installed on this system creates setuid files. That means that someone can email themselves a copy of "/bin/sh" from a system they have full control of to an account on their system and after "uuencode" restores the file to it's original format they only need to execute it to have full access to that user's account on your system. No user id on the system is secure as long as this problem exists.
Next COPS reports that there are no restrictions on ftp use on the system because the "/etc/ftpusers" file does not exist. Since this is a semi-closed system that does not support "SLIP" or "PPP" it is not a major concern here. The last problem shown in here are with the passwords to the user ids "sync" and "joes". The "sync" account does not have a password and the "joes" account has a easy to guess password. If COPS could guess the password then so could a hacker.
Warning! /usr/bin/uudecode creates setuid files!
**** ftp.chk ****
Warning! /etc/ftpusers should exist!
**** pass.chk ****
Warning! Password Problem: null passwd: sync shell: /bin/sync
Warning! Password Problem: Guessed: joes shell: /bin/csh
The last set of problems show that important system components have known security holes. These kind of problem are a bit more difficult to correct and sometimes require a patch from the system vendor.
**** kuang **** **** bug.chk ****
Warning! /usr/ucb/rdist could have a hole/bug! (CA-91:20)
Warning! /sys/sun3/OBJ/cons.o could have a hole/bug! (CA-90:12)
Warning! /usr/lib/lpd could have a hole/bug! (CA-91:10a)
Warning! /bin/mail could have a hole/bug! (CA-91:01a)
Warning! /usr/tc/in.telnetd could have a hole/bug! (CA-91:02a)
Warning! /usr/etc/rpc.mountd could have a hole/bug! (CA-91:09)
While this has only been a cursory overview of the COPS system I hope that it has inspired you to acquire a copy for your system and to run it on a regularly scheduled basis. It will be well worth the effort.
Pete Radatti is the founder and CEO of CyberSoft, Inc. CyberSoft manufactures, VFind the an antivirus software product that executes under Unix and simultaneously scans for Unix, MS-DOS, Macintosh and Amiga destructive software. You can reach Pete at radatti@cyber.com. Thanks for all the nice letters!
Back
