Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume21 / cops / part05 < prev next >

Wrap

Internet Message Format | 1990-03-21 | 21.2 KB

Subject: v21i027: System ecurity analysis tool, Part05/05 Newsgroups: comp.sources.unix Approved: rsalz@uunet.UU.NET X-Checksum-Snefru: ac9f5dab 17871498 6a1c8ba3 863825fe Submitted-by: Dan Farmer <df@sei.cmu.edu> Posting-number: Volume 21, Issue 27 Archive-name: cops/part05 # 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/docs/pass # cops/docs/passwd # cops/docs/rc # cops/docs/release.notes # cops/docs/root # cops/docs/suid.man # cops/docs/tilde # cops/docs/user # cops/docs/warnings # This archive created: Tue Jan 30 23:27:14 1990 # By: dan (Purdue University) echo shar: extracting cops/docs/pass '(1289 characters)' cat << \SHAR_EOF > cops/docs/pass .TH PASS.CHK 1 "December 31, 1989" .UC 4 .SH NAME pass.chk \- Checks critical files for writability. .SH SYNOPSIS .B pass.chk [ options ] .SH DESCRIPTION By default .I pass.chk only checks for accounts with passwords the same as the login name. The following options add more extensive checking. (The tradeoff is cpu time -- with all options enabled it can run into the 100's of MINUTES.) Any argument that does not begin with a "-" is assumed to be a file name. (A single '-' means stdin.) If no file name is given, /etc/passwd is used. .PP Options are: .TP .B \-v verbose -- list all guesses on stdout .TP .B \-u output the username on the line of the password file currently being checked. If the program stops abruptly you will then know how far it got. .TP .B \-w file use the list of words contained in "file" as likely passwords. Words in the file are one to a line. .TP .B \-b check all guesses backwards too .TP .B \-g use the Full Name portion of the gecos field to generate more guesses .TP .B \-s check the single letters a-z, A-Z, 0-9 as passwords .TP .B \-c with each guess, check for all lower case and all upper case versions too. .TP .B \-n complain about null passwords (default is to keep quiet) .TP .B \-p print the password when guessed .SH FILES .Ps /etc/passwd .Pe SHAR_EOF echo shar: extracting cops/docs/passwd '(781 characters)' cat << \SHAR_EOF > cops/docs/passwd .TH PASSWD.CHK 1 "December 31, 1989" .UC 4 .SH NAME passwd.chk \- Checks password file(s) for inconsistencies. .SH SYNOPSIS .B passwd.chk .SH DESCRIPTION .I passwd.chk checks the password files -- /etc/passwd and yppasswd if yellow pages are being used -- for incorrect number of fields, duplicate ids, non-alphanumeric login names, nonnumeric user ids', users with uid = 0 and not root, blank lines, accounts with no passwords, invalid login directories, and non-numeric password id's. .SH FILES .Ps /etc/passwd passwd.chk uses the process id as a temporary file name for the ypchecking. .Pe .SH "SEE ALSO" .Ps passwd(5) .Pe Awk part based on _password_ from _The AWK Programming Language_, page 78. .SH BUGS It doesn't use the exact syntax of yellow pages to check for errors. SHAR_EOF echo shar: extracting cops/docs/rc '(775 characters)' cat << \SHAR_EOF > cops/docs/rc .TH RC.CHK 1 "December 31, 1989" .UC 4 .SH NAME rc.chk \- Checks contents of /etc/rc* file(s) for potential danger. .SH SYNOPSIS .B rc.chk .SH DESCRIPTION .I rc.chk This checks pathnames and files inside the shell script files /etc/rc* (e.g. /etc/rc, /etc/rc.local, etc.) for writability. It filters out all paths or files that have a /tmp, /dev/null, or /dev/*ty, plus everything after a ">"; e.g. if crontab is writing to a file it doesn't care. .SH FILES /etc/rc* .SH BUGS Awk runs out of room ("bails out") if too many files are found in the /etc/rc* files. .PP Spurious messages can occur -- .I rc.chk only uses a approximation of which files should be checked. Also, Unless a file has a full pathname (i.e. begins with a "/", it will not be checked for writability. SHAR_EOF echo shar: extracting cops/docs/release.notes '(3580 characters)' cat << \SHAR_EOF > cops/docs/release.notes Brief Info-Capsule of COPS programs and files (release 1.0): ------------------------------------------------------------------------- Programs and some important files that are included in this release: ------------------------------------------------------------------------- cops A driving shell script for most of the programs below. It tosses output to /dev/null except what it wants, and mails any pertinent output to the users $SECURE_USER listed in the COPS file. Usage: cops suid.chk Checks the system for _changes_ in SUID status. This is the one program that should be run as superuser. You must first run a find on all SUID programs from the / directory, and then use that as a "stop file" (see man page below.) suid.man Manual for COPS.suid findsuid.stop The database originally set up with "find". Usage: suid.chk makefile A makefile for programs enclosed. Type "make" to make 'em (see Makefile for more information.) chk_strings Checks for writable paths/files in a file. Usage: chk_strings <file> cron.chk Checks for writable paths/files in /usr/lib/crontab. Usage: cron.chk dev.chk Checks /dev/*mem and all devs listed by "/etc/fstab" command for world read/writability (respectively.) In addition, checks a small group of files for non-world readability (/usr/adm/sulog, etc.) Usage: dev.chk [-g] (-g checks for group read/writability as well) dir.chk Checks directories listed in "dirs.chklst" for writability. dir.chklst List of directories for above. Usage: dir.chk [-g] (-g checks for group writability as well) file.chk Checks files listed in "files.chklst" for writability. file.chklst List of directories for above. Usage: file.chk [-g] (-g checks for group writability as well) group.chk Checks /etc/group for non-unique groups, invalid fields, non-numeric group ids, etc. Usage: group.chk home.chk.c Checks all users home-dirs listed in /etc/passwd for bad modes (basically world write, strangeness). Usage: home.chk rc.chk Checks all commands and paths listed in /etc/rc* for writability. Usage: rc.chk reconfig Changes the paths for the programs used in COPS. Example: changes /bin/awk --> /usr/bin/awk file.paths Data file for reconfig (created by reconfig.) Usage: reconfig is_readable Checks a file/directory and determines readability status; returns a "0" if is readable, a "1" otherwise. Usage: is_readable [-g] filename is_writable Checks a file/directory and determines writability status; returns a "0" if is writable, a "1" otherwise. Usage: is_writable [-g] filename kuang The U-Kuang expert system. Read the accompanying instructions in kuang.man. It basically checks to see if a given user (by default root) is compromisible, given that certain rules are true (i.e. /etc/passwd writable gives root access, etc.) Usage: kuang init_kuang Contains the targets for the kuang system. passwd.chk Checks /etc/passwd for non-unique uids, invalid fields, non-numeric user ids, etc. Usage: passwd.chk pass.chk Checks /etc/passwd for crummy passwords. pass.words Data file for pass.chk; use "pass -w pass.words" to use them. Defaults to checking for the users' id. Usage: pass.chk [-flags] user_chk.c Checks all users listed in /etc/passwd; looks at .login/.cshrc/.rhosts/.profile, etc., for bad modes (basically world write, strangeness). Usage: user_chk SHAR_EOF echo shar: extracting cops/docs/root '(414 characters)' cat << \SHAR_EOF > cops/docs/root .TH ROOT.CHK 1 "December 31, 1989" .UC 4 .SH NAME root.chk \- Checks contents of root owned startup files as well as a variety of miscellaneous potential dangers. .SH SYNOPSIS .B root.chk .SH DESCRIPTION .I root.chk This checks the paths inside root's startup files for the current directory being used as a valid path and for improper umask settings (world writable). .SH FILES .Ps /.login /.cshrc /.profile .Pe SHAR_EOF echo shar: extracting cops/docs/suid.man '(1065 characters)' cat << \SHAR_EOF > cops/docs/suid.man findsuid \- find changes in setuid and setgid files .sp SYNOPSIS .sp .ul findsuid .sp DESCRIPTION .PP Findsuid is a shell script intended to be run periodically by .ul cron (8) in order to spot changes in files with the suid or sgid bits set. .PP .ul Findsuid uses .ul find (1) to search system directories for all files with the 4000 or 2000 permission bits set. It then compares these files with the contents of a ``stop file'' containing .ul \*Qls -lga\*U output for known setuid or setgid programs. Any additions or changes to this list represent potential security problems, so they are reported by mail to system administrators for further investigation. .sp FILES .sp .nf /usr/adm/findsuid.stop the ``stop file'' .fi .sp SEE ALSO .sp find(1), chmod(1), cron(8) .sp BUGS .sp The location of the stop file, the directories to be searched and the names of users to be informed of changes are all defined by shell variables in the source. .PP Keeping the stop files up to date with changes to all the suid files on more than a couple of hosts is a royal pain! SHAR_EOF echo shar: extracting cops/docs/tilde '(230 characters)' cat << \SHAR_EOF > cops/docs/tilde .TH TILDE 1 "December 31, 1989" .UC 4 .SH NAME tilde \- returns a user's home directory. .SH SYNOPSIS .B tilde user .SH DESCRIPTION This merely prints a user's home directory, or "Error" if not found. Named for the Csh feature. SHAR_EOF echo shar: extracting cops/docs/user '(461 characters)' cat << \SHAR_EOF > cops/docs/user .TH USER.CHK 1 "December 31, 1989" .UC 4 .SH NAME user.chk \- Checks key files in user home directories for world writability. .SH SYNOPSIS .B user.chk .SH DESCRIPTION This checks the following files in all of the user home directories (it calls getpwent() to get user directories) for world writability: .Ps .rhost .profile .login .cshrc .bashrc .kshrc .tcshrc .rhost .netrc .forward .dbxinit .distfile .exrc .emacsrc .Pe SHAR_EOF echo shar: extracting cops/docs/warnings '(10292 characters)' cat << \SHAR_EOF > cops/docs/warnings This file contains a list of most of the security warnings that you might see while using the COPS system. Not included here are messages that you may receive from the Kuang system and the SUID checker. For help on using those tools, read the appropriate documentation on each of those ("kuang.doc and suid.doc".) First, I'll define some arbitrary terms which I'll use when describing any problems you may encounter, then I'll list the messages, what they may mean, and how you can change your system to eliminate any danger posed. Some almost identical warnings were eliminated from the list; however most warnings should have an analogous entry that is very close syntactically to it in this file. All messages in COPS are prepended by "Warning!"; this has been excluded here for brevity. There may be more than one way to overcome any problem listed here. If you are unsure about whether to change a problem, try looking at some of the references listed at the end of the technical report (cops.report) for more information on how an attacker may compromise your system. Some of the more dangerous security holes include writable directories and key files (such as /etc/passwd), root owned SUID files writable to world or that give a root shell, null passwords, and writable files that are executed by root. Don't take everything that COPS says as gospel! What may be a serious security hole on one machine may not be on your own, and vice-versa. However, the more you value the information on your machine, the more you should be concerned about security. Some terms I'll use: xyz -- An arbitrary number. Usually a line number in a file. foo_file -- stands for a file you might see in your warning message. foo_file2 -- Same as "foo_file", stands for a different file than the first (used when two filenames are needed in one message.) foo_dir -- a typical directory. Group file -- /etc/group or the yellow pages group. If the warning starts with "Group", it is the former, "YGroup" is the latter. foo_group -- either /etc/group or ygroup. Password file -- /etc/passwd or the yellow pages password. If the warning starts with "Password", it is the former, "YPassword" refers to the latter. foo_pass -- either /etc/passwd or ypasswd. cron_file -- will be either /usr/cron or /usr/spool/cron/crontabs/foo_file. foo -- anything that doesn't fit above. Usually an arbitrary name, or group name, or whatever. bar -- As "foo", if more than one name is needed in one message. foo_bar -- As "foo", if more than two names are needed in one message. WARNING MESSAGES ----------------- 1) foo_file is _World_ writable! foo_file is group readable! This simply means that a file is world writable; e.g. Anyone can modify or delete this file. This can be especially bad if the file can (even indirectly) give root access, such as the system password file, "/etc/passwd". To fix, type: chmod a-w foo_file This removes write access for group "all/world". 2) foo_file (in cron_file) is World writable!" File foo_file (inside root executed file foo_file2) is _World_ writable!" File foo_file (in /etc/rc*) is _World_ writable!" Similar to the above messages, but potentially more serious. Files in this group are being used by root, and either being utilized as input, output, or for execution. Examine the file they are inside and see how it is being used. Files being executed are the most dangerous because if they are changed, the new file gets executed with root privileges. Input files are next, because changing them can alter what the executing program does and cause undesirable side affects. Even output files can be dangerous, however, because they may be used as an output or even as a program file later on. To fix, either delete the reference to foo_file inside the cron/rc*/foo_file2/whatever file, or type: chmod a-w foo_file to remove write access for group "all/world". 3) Directory foo_dir is _World_ writable! This simply means that a directory is world writable; e.g. Anyone can delete this directory, as well as mess with the files and subdirectories inside of it. For instance, if /usr/spool is world writable, even if cron is not writable, this is a problem, because the cron directory can be replaced and new crontab files put in (which all run with root privileges.) As a general rule, if you wish to have a file or directory secure, all directories that are parent directories must be secure. To fix, type: chmod a-w foo_dir This removes write access for group "all/world". 4) Duplicate Group(s) found in foo_group:" This means that one or more duplicate group names have been found. This is mostly a system accounting problem; when adding or deleting names from a group you will have problems. To fix, remove all but one instance of each group in your /etc/group file. 5) Group foo_bar has duplicate user(s):" Similar to (4), a group has the same user listed more than once. If all instances of the user is not deleted, they probably will remain with their old privileges. To fix, remove all but one instance of a user in each group of your /etc/group file. 6) Group file, line xyz, non-numeric group id: foo Group id's must be numeric. Testing a non-numeric id will give unpredictable results. To fix, change the old id to a valid group id. 7) Group file, line xyz, is blank To fix, remove all blank lines. 8) Group file, line xyz, does not have 4 fields: foo More trouble. Testing of one or more of the groups will result in invalid results, depending which is the missing field(s). To fix, ensure group has four valid fields. 9) Group file, line xyz, nonalphanumeric user id: foo As (6). To fix, change the old id to a valid group id. 10) Group file, line xyz, group has password: foo To fix, change the old password to an asterisk ("*"). 11) Password Problem: Guessed: foo shell: bar passwd: foo_bar If an account has a guessed password, it is susceptible to other password guessing programs (the one in COPS is rather crude and slow). Obviously, if the password is known, the account is compromised. To fix, either have the user change her/his password or change it yourself. 12) Password Problem: null passwd: foo shell: bar Password file, line xyz, no password: foo If an account has no password, anyone can log into the account at will. To fix, either have the user change her/his password or change it yourself. 13) Duplicate uid(s) found in foo_passwd:" This is a problem, especially if the accounts have different permissions or privileges. When the user's account is deleted, one or more accounts may remain active. To fix, simply delete all but one occurrence of the users account. 14) Password file, line xyz, user foo has uid = 0 and is not root bar Ideally, no one but root should have uid = 0. Anyone with uid=0 is superuser, for all purposes. Occasionally, a maintenance account has uid=0, or perhaps a small group of administrators. Be very careful! To fix, change the uid from 0 to some other valid number. If the account or person really needs root privileges, have them use the root account so you can keep track of who is using root. 15) Password file, line xyz, nonalphanumeric login: foo Another maintenance problem. Someone's been messing with the password file, or you have some bugs in your software that fools around with it. To fix, delete or change the login to a valid login. 16) Password file, line xyz, invalid login directory: foo User foo's home directory bar is not a directory! A user has a non-existent or invalid login directory listed in the password file. Sometimes these are maintenance accounts, but it is discouraged. Examine the account to see if it should really exist. To fix, either delete the account or put in a valid login directory. 17) Password file, line xyz, nonnumeric group id: foo Password file, line xyz, nonnumeric user id: foo A user has a invalid user or group id. Dangerous if, when checked, it translates to invalid number (who knows what would happen), or worse yet, 0. To fix, change the field to a legal, numeric value. 18) Password file, line xyz, does not have 7 fields: foo Dangerous, because when a program checks for a field value it will come up with who knows what. To fix, ensure all fields have legal values. 19) Password file, line xyz, is blank To fix, delete all blank lines. 20) NFS file system foo exported with no restrictions. Anyone can mount the file system. May or may not be a problem, but look over closely, if you value ANY of the info on it! To fix, put in a valid list of hosts that may mount it. 21) Root's umask set to xyz If root's umask is set incorrectly, any files that it creates will be have bad permissions (e.g. world writable if 000, x00, or xy0). To fix, put a "safe" value; 077 or whatever. 22) "." is in roots path! Trojan horses traditionally play upon having the current directory in a users path. A bad user will put a trojan horse with a the same name as a common system command ("ls" is a favorite) and place it in a location that s/he thinks might be executed. When the trojan horse is executed, it will not only execute the command, but will also either steal your account privileges or have your account perform some action that they desire. 23) User foo's home directory foo_dir is mode xyz! If a user's home directory is writable, you have the same problems as (3), except all of the user's files are in jeopardy this time. To fix, type: chmod a-w foo_dir 24) User foo: .bar is mode xyz! In this case, ".bar" stands for one of the user's initialization files, such as .login, .profile, .exrc, ect. If the user's file is world writable, then anyone can modify that file, and whenever the user logs in or executes a command (such as "vi", when referring to ".exrc"), they will execute whatever commands the bad girl/boy wants them to. To fix, type: chmod a-w foo_file SHAR_EOF # End of shell archive exit 0 From @medusa.cs.purdue.edu:df@cs.purdue.edu Wed Jan 31 00:01:51 1990 Received: from BBN.COM by pineapple.bbn.com id <AA01286@pineapple.bbn.com>; Wed, 31 Jan 90 00:01:48 -0500 Received: from medusa.cs.purdue.edu by BBN.COM id aa22146; 30 Jan 90 23:57 EST Received: by medusa.cs.purdue.edu (5.61/PURDUE_CS-1.2) id <AA08905@medusa.cs.purdue.edu>; Tue, 30 Jan 90 23:57:37 -0500 From: dan <df@cs.purdue.edu> Message-Id: <9001310457.AA08905@medusa.cs.purdue.edu> Subject: COPS, note #2 To: Rich Salz <rsalz@BBN.COM> Date: Tue, 30 Jan 90 23:57:34 EST In-Reply-To: <8910021306.AA00139@prune.bbn.com>; from "Rich Salz" at Oct 2, 89 9:06 am X-Mailer: ELM [version 2.2 PL10] Status: R The shar files are in no special order, nor do they have to be unpacked in any order. Since I don't know much 'bout shar, I put in some mkdir's at the beginning of the shars so the directory structure I wanted would be preserved. You may do with them what you will.... -- dan