💾 Archived View for spam.works › mirrors › textfiles › hacking › cops-rl captured on 2023-11-14 at 09:49:32.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
* R e n e g a d e L e g i o n *
RL C.O.P.S. File
by
Brian Oblivion
Technical Report #7
May 1991
The Night Elite BBS (RL HeadQuarters) : (617) oOo-oOOo
The Electric Eye ][ (RL Support Site) : (313) 776-8928
Mind Of 'a Lunatic (RL Support Site) : (714) 693-0957
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Well, due to the increasing popularity of this package of utilities, I
feel that everyone should be aware of it, watch for it, and avoid it.
Looking at the file one will say, by Jove! how easy it would be to modify
this program to report to me all the flaws of a system. And so it should
be done. At any rate, absorb the information.
The package, which will be henceforth be referred to as COPS
(Computer Oracle and Password System), can be broken down into three
key parts. The first is the actual set of programs that attempt
to automate security checks that are often performed manually (or
perhaps with self written short shell scripts or programs) by a systems
administrator. The second part is the documentation, which details
how to set up, operate, and to interpret any results given by the
programs. Finally, COPS is an evolving beast. It includes a list
of possible extensions that might appear in future releases, as well
as pointers to other works in UNIX security that could not be included
at this time, due to space or other restrictions.
This document contains six sections:
1) What is COPS?
2) What COPS is _not_
3) How to Configure COPS
4) Running COPS for the 1st Time
5) Continued Use and Installing COPS
6) Disclaimer and End Notes
1) What is COPS?
-----------------
COPS is a collection of about a dozen (actually, a few more, but
a dozen is such a good sounding number) programs that each attempt
to tackle a different problem area of UNIX security. Here is what it
currently checks:
o file, directory, and device permissions/modes.
o poor passwords.
o content, format, and security of password and group files.
o the programs and files run in /etc/rc* and cron(tab) files.
o finds SUID files, and checks for their writeability and if they are
shell scripts.
o runs a crc check against important binaries or key files, and reports
any changes therein.
o writability of users home directories and startup files (.profile,
.cshrc, etc.)
o anonymous ftp setup.
o unrestricted tftp, decode alias in sendmail, SUID uudecode problems.
o miscellaneous root checks -- current directory in the search path,
a "+" in /etc/host.equiv, unrestricted NFS mounts, ensures root is
in /etc/ftpusers, etc.
o includes the Kuang expert system, that takes a set of rules and tries
to determine if your system can be compromised (for a more complete list
of all of the checks, look at the file "release.notes" or "cops.report";
for more on Kuang, look at at "kuang.man".)
All of the programs merely warn the user of a potential problem --
COPS DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL PROBLEMS
IT FINDS! COPS either mails or creates a file (user selectable) of any
of the problems it finds while running on your system. And because COPS
does not correct potential hazards it finds, it does _not_ have to be
run by a privileged account (i.e. root or whomever.) The only security
check that should be run by root to get maximum results is the SUID checker;
although it can be run as an unprivileged user, to find all the SUID files
in a system, it should be run as root (in addition, if key binaries are
not world readable, only executable, the CRC checking program ("crc.chk")
needs to be run as a privileged user to read the file in question to get
the result.) In addition, COPS cannot used to probe a host remotely; all
the tests and checks made require a shell that is on the site being tested.
The programs are mostly written in Bourne shell (using awk, sed, grep,
etc. as well) for (hopefully) maximum portability. A few are written
in C for speed (most notably the Kuang expert system and for implementing
fast user home directory searching), but the entire system should run on
most BSD and System V machines with a minimum of tweaking.
2) What COPS is _not_
----------------------
COPS merely provides a method of checking for common procedural errors.
It is not meant to be used as a replacement for common sense or user/
operator/administrative alertness! Think of it as an aid, a first line
of defense -- not as an impenetrable shield against security woes. An
experienced wrong-doer could easily circumnavigate _any_ protection that
COPS can give. However, COPS _can_ aid a system in protecting its users
from (their own?) ignorance, carelessness, and the occasional malcontent
user.
Once again, COPS does not correct any errors found. There are several
reasons for this; first and foremost, computer security is a slippery
beast. What is a major breach in security at one site may be a standard
policy of openness at another site. Additionally, in order to correct all
problems it finds, it would have to be run as a privileged user; and I'm
not going to go into the myriad problems of running SUID shell scripts
(See the bibliography at the end of the technical report "cops.report"
for pointer to a good paper on this subject by Matt Bishop.)
At this time, COPS does not attempt to detect bugs or features (such
as the infamous ftpd, fingerd, etc) that may cause security problems. Although
this may change in future versions, the current line of reasoning to avoid
general publication of programs such as these is that all the problems that
COPS detects can be repaired on any system it runs on. However, many bugs
can be readily repaired only be having source code (and possibly a good
vendor to repair it), and many sites would have serious troubles if they
suddenly discovered unrepairable problems that could compromise their
livelihood. It is possible that a more controlled release may come out
in the future to address such problems (but don't mail to me about getting
them -- unless you want to help write them! :-))
3) How to Configure COPS
-------------------------
System V users, other Non-BSD systems, or sites with commands in
strange places -- you may have to run a shell script called "reconfig"
to change the pathnames of the executable programs called when using
COPS. If your system does not use the paths listed in the shell
scripts, try running "reconfig". This will reconfigure the pathnames
used by COPS to your system; COPS should run fine then, if it
can find all of the commands (reconfig should tell you if it
cannot.) If trouble persists, you will have to change the paths
to your executable files (awk, sed, etc) by hand. A drag, I know.
This all may change without notice, anyway :-)
With all the varieties of unix, there are a few types that may need
extra help to run the system. I've got README files for Apollo and Xenix
in the distribution -- see the files "README.apollo", and "README.xenix",
respectively -- if you have any troubles, drop me a line, and I'll
see what I can do about working out a patch with you. Some problems
might arise with some SYSV machines (heck, to any machine :-)), due to
weird files and names for stuff. What can I say? Portability is a
problem. You can comment out line 39 and 38 in "misc.chk", if you use
/etc/servers instead of /etc/inetd.conf.
4) Running COPS for the 1st Time
---------------------------------
Since most of COPS was written and tested mostly on just a few machines
(at least compared to the total number out there!), you may have significant
differences that were not anticipated -- unfortunately, or fortunately,
UNIX is not quite standardized yet. However, I haven't run into a UNIX
yet that I haven't been able to get it running on, with just a small amount
of change, so feel free to mail to me for help.
COPS is run by simply typing "cops". "cops" is a Bourne shell script
that runs each of the programs, accumulates the output, and then either
mails or stores any results in a file. "suid.chk" (and possibly "crc.chk")
is the only package that is meant to be run separately, simply because it
can take a long time to run, and possibly because it needs a privileged
account to run it; look at "suid.man" for more information. By all means,
however, do not ignore the SUID checker! Run it at least once a week, if
possible, more (daily?); intruders into a system often leave SUID files
to gain privileges later. "crc.chk" should also be run; it can either
be run as a standalone program (preferred), or as part of the COPS package;
read the file "CRC.README", and the man page for more information.
To run COPS for the first time, I suggest doing the following:
-- Look at the disclaimer, file "disclaimer". Don't sue me.
Actually, this holds for all the times you use COPS (1/4 :-))
-- Type "make" and "make docs" to create the formatted manual pages,
to compile the C programs, and to make the shell programs executable.
A couple of potential (hopefully minor problems) might occur, probably
only for SysV based machines; one, if you don't have the "-ms" package
for nroff (i.e. you, get an error message after typing "make" about
it), just remove the "-ms" flag; e.g., change line 7 of the
"docs/makefile" file, from:
ROFFLAGS = -ms
to
ROFFLAGS =
The second potential problem might be with the password checking
program; if it fails to compile, try uncommenting out line 20 in
"makefile" -- e.g., enable the "BRAINDEADFLAGS = -lcrypt" flag.
If this doesn't work... well, you can either work it out, or e-mail me.
-- Read the technical report to understand what COPS is doing and
what is going on -- "cops.report". This gives a look at the
philosophies, design notes, and finally a general outlay of the
COPS system and UNIX security. This can be forsaken, for those
who just want to get to the results/see some action (people like
me.)
-- Next, change lines 51 and 52 in the "cops" shell file; this is
what they were:
SECURE=/usr/foo/bar
SECURE_USERS="foo@bar.edu"
SECURE should be the same directory as the directory that contains
the cops programs, and SECURE_USERS should be your own login id, or
to whomever you designate as the recipient of the output (your enemy?)
-- Set "MMAIL=NO" in the "cops" shell file (line 25). This will prevent
a large mail file from choking the mailer. All of the output will be
put into a file called "year_month_day" (obviously, that's like:
"1991_Dec_31", not actually the words, "year_month_day" :-)), and
should be automatically placed by COPS in a directory that has the
same name as the host it was run on (e.g., your own hostname.)
-- Look at the directory and file configuration file, "is_able.lst"
This contains critical files that COPS checks for group and world
writability and readability. Add or delete whatever files/directories
you wish; if a file doesn't exist, COPS will effectively ignore it.
(If you don't know or are uncertain what files/directories are
important, what is given there is a good set to start with on most
systems.)
-- If you allow anonymous ftp access to your system, add a "-a" flag
to "ftp.chk" on line 104 of "cops". Right now, it is set up so
that key files and directories are expected to be owned by root;
however, it has provisions for two owners, $primary and $secondary --
some may wish to change the second to "ftp", or some other user.
Read the man page for ftp.chk, or look at "ftp.chk" for further notes.
-- You may wish to comment out the password checker (line 109 in the
"cops" shell file). Although this is not necessary, it will speed
up the package if you wish for immediate gratification.
If you are using yellow pages/NIS, read "README.yp" for tips on how
to check passwords there.
-- Uncomment out the crc checker, "crc.chk" (line 123), if you desire to
run it as part of the normal COPS run.
You should be ready to roll. COPS is run by simply typing "cops" (you
may wish to put in the background....) If you followed my advice and
set "MAIL=NO" in the "cops" shell file, after COPS is finished, there
will be a report file created ("year_month_day") that lists the time and
machine it was created on. Otherwise, COPS mails the report to the user
listed on the line 'SECURE_USERS="foo@bar.edu"'. There is a file
"warnings", which contains most of the warning messages COPS uses, as well
as a brief explanation of how the message might pertain to your system and
finally a suggestion as how to "fix" any problem.
NOTE: Change the shell script "cops" to reflect who you want the output
sent to and where the location of the program is BEFORE running the program.
5) Continued Use and Installing COPS
-------------------------------------
Once you are satisfied that COPS indeed does something useful
(hopefully this will occur :-)), a good way to use it is to run it
on at least a semi-regular basis. Even if it doesn't find any problems
immediately, the types of problems and holes it can detect are of the
sort that can pop up at any given time. One way of running COPS
might be to run it as an "at" job or by cron.
I highly advise that whatever directory COPS is placed in is to be
readable, writable, and executable only by the owner (typing
"chmod 700 /usr/foo/bar" or whatever the name is will do this) of the
directory. This is to prevent prying eyes from seeing any security
problems your site may have. Even if you don't think of them as
important, someone else might come around and change your mind. Since
COPS is fairly configurable, an intruder could easily change the paths
and files that COPS checks for, hence making it fairly worthless. Again,
this comes back to the point that COPS is only a tool -- don't put down
your defensive shields merely because COPS says "all clear". If this
sounds paranoid, it is! Security people are traditionally paranoid,
for a reason.... In any case, it is probably not a good idea to advertise
any (even) potential weaknesses.
Typing "make install" will create (if necessary) a subdirectory with
the name you put in $INSTALL_DIR (found on line 7 of "makefile"); if you
run a network with multiple architectures, you can have several executable
versions of COPS in the same NFS mounted directory structure. You can run
COPS with "cops archtype", and it will cd into the archtype directory, use
the binaries in that directory (placed there by a "make install"), and put
any results in a subdirectory of the archtype directory with the appropriate
host name.
For example, assume you have the following setup:
machine architecture hostname If run COPS with:
===================== ======== ==================
cray ribcage cops
vax bar cops vax
vax foo cops vax
sun earth cops sun
sun mars cops sun
sun venus cops sun
mips hades cops
If $SECURE (the secure directory variable in the "cops" shell script) was
set to "/usr/secure", the resulting directory/reporting structure would be:
/usr/secure/cops/ribcage
/usr/secure/cops/vax/bar
/usr/secure/cops/vax/foo
/usr/secure/cops/sun/earth
/usr/secure/cops/sun/mars
/usr/secure/cops/sun/venus
/usr/secure/cops/hades
Sometimes you will get the same report over and over again, everytime you
run COPS; for instance, with Ultrix 3.x, /dev/kmem is world readable -- this
is a security hole, but many utilities in Ultrix need this to function. If
you wish to only see reports that are _different_ than the old reports, you
first need to have an older report saved in a file (in $SECURE/hostname, or
wherever you usually save the reports); you can then set "MMAIL=YES" _and_
"ONLY_DIFF=YES" (lines 25 & 30, respectively) in "cops"; everytime COPS is
run after that, it will compare the report it generated for the current
check with the old report; if it detects any differences, it will mail you
a report. If not, it simply discards it. This can be a real boon for a
site with a lot of machines running COPS every night...
There are a couple of further options you may wish to explore. First
of all, since so many breakins are because of poor passwords selection
by users, it would be a wise idea to add options to your password checking
program (line 109 in "cops"). You may wish to try some words from a
dictionary; you may use either your system dictionary (usually found in
/usr/dict/words), or you may use the same dictionary that the internet
worm found so lucrative when hitting all those thousands of hosts; that
dictionary is in the file "pass.words" (example; the way to include the
worm dictionary is: "pass.chk -w pass.words"). Also, try some of the options
in the password program, such as "-b", "-g", "-s", and "-c", which add
checks for backward, gecos, single letter & number, and upper and lower
case guesses, respectively. Just as a note, each option will increase the
time needed to crack the passwords, of course; experiment! See what is
reasonable for your hardware and resource capabilities.
By using the "pass_diff.chk" program, you only check accounts that have
_changed_ their password since the last time you've checked -- this can
save enormous amounts of times with large systems; you can check your users
thoroughly once, then only check them as they change their passwords again.
Be careful, though, if you use this, and then later expand your checks
and/or your dictionary used to search for passwords, the earlier accounts
that were already checked with an inferior method will not be checked again
until they change their password. See the file "passwords" in the
"extensions" directory for a replacement "passwd" program, that can disallow
poor passwords to begin with.
The file "is_able.lst" contains a list of files that are to be checked
for world readability and/or writability; look at the file; add or delete
any files you feel are important to your system.
After running COPS, if any warnings are given that compromise any
individual users accounts (such as world writable .profiles, home
directories, guessed passwords, etc.), and the warnings are not corrected
immediately (or you are not sure whether or not it is worth hassling
the user to change it), try this:
Edit the file "init_kuang", and add the compromised user(s) uids and
groups in their respective target lines (below lines 20 and 27,
respectively), and run kuang again to see if the users can compromise
the entire system. You may change your mind about not thinking
they are a problem! In addition, kuang does not have to have "root"
as a target (the last line). Try putting in system administrators or
other powerful figures to see if they are in danger as well. If you
have "perl" installed on your system, try the perl version of kuang --
"kuang.pl" (you'll have to unpack the shar file this is inside --
"kuang.pl.shar", and you may have to edit the first line of the file
"kuang.pl", to reflect where the location that perl is on your system.)
6) Disclaimer and End Notes
----------------------------
COPS is meant to be a tool to aid in the tightening of security, not
as a weapon to be used by an enemy to find security flaws in a system.
It may be argued that allowing anyone to have access to such a tool may
be dangerous. But hopefully the overall benefit for systems that use
this package will outweigh any negative impact. To me it is akin to a
law enforcement problem -- that although telling the public how to break
into a house may foster a slight rise in break-in attempts, the overall
rise in public awareness on how to defend themselves would actually result
in a drop in break-ins. The crackers with black hats already know how
to crush system defenses and have similar tools, I'm sure. It's time
we fought back.
COPS is not the final answer to anyone's security woes. You can use
the system as long as you realize that COPS has no warranty, implied
or otherwise, and that any problems that you may have with it are
not my or any of the other authors' fault. I will certainly attempt to
help you solve them, if I am able. If you have ideas for additional
programs, or a better implementation of any of the programs here, I would
be very interested in seeing them. COPS was the work of a LOT of people,
both in writing code and in the testing phase (thanks beta testers!). For
a complete list of contributors, look at the file "XTRA_CREDIT".
So good luck, and I hope you find COPS useful as we plunge into UNIX
of the 1990's.
dan farmer
January 31, 1989
(Now January 31, 1990)
# include "./disclaimer"
Just for snix, here are some of the machine/OS's I know this sucker works
on; far and away the most common problem was getting that stupid password
cracking program to compile, followed by systems without the -ms package to
nroff. Some minor problems with config files -- I *think* these are all
ok:
DECstation 2100, 3100, 5000, Ultrix 2.x, 3.x, 4.x
(It should, I'm sitting in front of one now. Ultrix is braindead)
Sun 3's, 4's (incl. Solbourne) -- 3.x, 4.x
Gould 9080 Powernode, hacked up Gould OS (whatever it is)
sequent S-87 symmetry, dynix V3.0.12 (both att & bsd universes; att required
"BRAINDEADFLAGS = -lcrypt" to be uncommented.
eta-10P, Sys V R3 based
Convex boxes, all types, most OS's (up to 9.x, the most recent)
Apollo dn3000 & dsp90, Domain SR 9.7
Vax 11/780, 4.3 BSD (Mt. Xinu, tahoe and stock)
Vaxstation, MicroVax, Vax 6320 & 8800, Ultrix 2.0, 3.x
HP900/370, HP-UX 6.5
Cray 2 & Y-MP, UNICOS 5.0, 6.0
Amdahl 5880, UTS 580-1.2.3
SGI 2500's, IRIX GL 3.6
SGI 4D's, IRIX System V Release 3.X
'286 & '386 Boxes, running Xenix (README.xenix)
Apple Mac IIci, running AUX 2.x. The "test -z" seemed broken on this, but I
only had a brief chance to test it out, but kuang didn't like it as a result.
I'll get a working version soon; everything seemed ok (change the /etc/servers
line in "misc.chk".)
NeXT, 1.x
(password stuff is different on this machine, tho; cracking is strange. Diffs?)
Multimax 320, 12 Processors, 64Mb Memory, Encore Mach Version B1.0c (Beta)
(no crypt(3) on this machine. Sigh.)
IBM rs6000, AIX 3.1 (BRAINDEAD -- boo. hiss.)
COPS will *NOT* work well on this piece of trash -- the shell utilities are
garbage; however, you can still get *some* useful info. I'm not going to
rewrite everything because big-blue won't write an awk that works: