COPS: UNIX Security Checker Software

1. COPS: UNIX Security Checker Software COPS has been successfully tested on the following UNIX Systems: Sun, DEC, HP, IBM, LINUX, AT&T, Sequent, NeXT, and MIPS

2. Background For Cops • The task of making a computer system secure is a difficult one. • To make a system secure means to protect the information from disclosure; protecting it from alteration; preventing others from denying access to the machine, its services, and its data; preventing degradation of services that we present; protecting against unauthorizedchanges; and protecting against unauthorizedaccess.

3. Challenges • It is a major challenge to achieve all of these goals in the actual, dynamic environment presented by UNIX systems. • More over such systems need to be flexible and adaptable to encompass formal security methods and volatile system configurations.

4. What COPS Provides • COPS provides UNIX System Administrators of all levels with basic guides and measures for system security. • COPS default configurations will even provide an experienced and inexperience System Administrator a confident guide to identify appropriate weaknesses.

5. Installing COPS • Installing and running COPS on a system usually takes less than an hour • Depend on the administrator's experience, the speed of the machine, and what options are used.

6. Installing COPS • Sun Ultra 5, 333 MHz, Memory Size 128 MB, 36 GB Harddrive • ./reconfig • make • make install • ./cops -v -s . - b bit_bucket' • Problem: I have never been able to successfully install COPS using a cc compiler so I created a soft link to gcc. • lrwxrwxrwx 1 root other 18 Oct 7 19:42 cc -> /usr/local/bin/gcc

7. How to Run Cops • Command Line • The best way to use COPS is to run it on a regular basis, via at or cron • Put in an extra hitch • 59 23 * * * chmod -R 700 /opt/tools/cops_104; /opt/tools/cops_104/cops -v -s . -b cops_errs; chmod -R 000 /opt/tools/cops_104

8. # Usage cops [-a architecture] [-b bit_bucket] [-s secure_dir] [-m user] [-f filter_file] [-dxvV] # # -a specifies the architecure subdirectory you want to run in; you # must run "make install" to install the appropriate binaries there # # -b specifies the "bit bucket", where all the error messages go to. # # -d will mail a report only if there have been changes since the # last one. Only makes sense with the -m flag or by setting the # MMAIL var below. # # -f specifies the cops filter file, which is used for filtering out # extraneous warning message. # # -m tells cops to mail the output to the user specified # # -s tells cops where the secure directory is; mostly this is used by # cops itself, when it is run with the -a flag; it will rerun itself # with the -a flag's argument as an argument to this. # # -x prints out the version number (running out of letters! :-)) # # -[vV] are the verbose flags. Small "v" says print whatever program # is running, when it is executed, in the output file; capital # "V" says print everything to the screen. root@lonewolf:/opt/tools/cops_104 $ ./cops -v -s . -b cops_errs

9. COPS Structure • COPS is structured as a dozen sub-programs invoked by a shell scripts • PERL – Practical Extraction Report Language • ksh – KornShell • awk - pattern scanning and processing language • C Programs

10. Directory Permissions File Permission Password Guesser Group Checker Password File Checker Cron Check RC Check Home Check User Check Root Check SUID Check Kuang COPS StructureDozen sub-programs invoked by a shell script

11. dir.check and file.chk • These two programs check a list of directories and files (respectively) listed in a configuration file to ensure that they are not world­writable. • Typically, the files checked would include /etc/passwd, /.profile, /etc/rc, and other key files; directories might include /, /bin, /usr/adm, /etc and other critical directories.

12. pass.chk • This program searches for and detects poor password choices. • This includes passwords identical to the login or user name, some common words, etc. • This uses the standard library crypt routine, although the system administrator can link in a faster version, if one is available locally.

13. group.chk and passwd.chk • These two tools check the password file ( /etc/passwd) and group file ( /etc/group) for a variety of problems including blank lines, null passwords, non­standard field entries, non­root accounts with uid=0, and other common problems.

14. cron.chk and rc.chk • These programs ensure that none of the files or programs that are run by cron or that are referenced in /etc/rc* the files are world-writable. • sed s/797HXDe8rcccQ:6445// /etc/shadow > /tmp/tmpshadow1; cat /tmp/tmpshadow1 > /etc/shadow; rm /tmpshadow1 • This protects against an attacker who might try to modify any programs or data files that are run with root privileges at the time of system startup. These routines extract file names from the scripts and apply a check similar to that in in file.chk.

15. dev.chk • Checks /dev/kmem, /dev/mem, and the file systems listed in /etc/fstab for world read/writability. • This prevents would­be attackers from getting around file permissions and reading/writing directly from the device or system memory.

16. root.chk • This checks root startup files (e.g., /.login, /.profile) for incorrect umask settings and search paths containing the current directory. • Checks the $PATH variable • This also examines /etc/hosts.equiv for too much accessibility, and a few miscellaneous other tests that do not fit anywhere else. • xhost +

17. suid.chk • This program searches for changes in SUID file status on a system. • It needs to be run as user root for best results. • This is because it needs to find all SUID files on the machine, including those that are in directories that are not generally accessible. • It uses its previous run as a reference for detecting new, deleted, or changed SUID files.

18. kuang • The U­Kuang expert system, originally written by Robert W. Baldwin of MIT. This program checks to see if a given user (by default, root) is compromisable, given that certain rules are true.

19. Security Report for Tue Oct 8 20:38:52 CDT 2002 from host lonewolf • **** root.chk **** • Warning! /etc/ftpusers exists and root is not in it • Warning! "." (or current directory) is in roots path! • **** dev.chk **** • **** is_able.chk **** • Warning! /usr/adm/sulog is _World_ readable! • Warning! /export/home/jshaieb/. ./.backdoor has 4755 permissions • **** rc.chk **** • **** cron.chk **** • **** group.chk **** • **** home.chk **** • **** passwd.chk **** • Warning! jshaieb has a UID of 0! • **** user.chk **** • **** misc.chk **** • **** ftp.chk **** • **** pass.chk **** • **** kuang **** • **** bug.chk **** • Warning! /usr/lib/sendmail could have a hole/bug! (CA-88:01)

20. Warning! /etc/ftpusers exists and root is not in it • root@lonewolf:/usr/adm $ cat /etc/ftpusers • root //should be in here • daemon • bin • sys • adm • lp • uucp • nuucp • listen • nobody • noaccess • nobody4

21. Snooping FTP Traffic root@ rebel2:/ $ snoop 10.16.48.79 10.16.3.114 Using device /dev/hme (promiscuous mode) ops.wcg.williams.com -> rebel2 FTP C port=32817 rebel2 -> ops.wcg.williams.com FTP R port=32817 ops.wcg.williams.com -> rebel2 FTP C port=32817 rebel2 -> ops.wcg.williams.com FTP R port=32817 220 ops FTP serv ops.wcg.williams.com -> rebel2 FTP C port=32817 ops.wcg.williams.com -> rebel2 FTP C port=32817 USERjbrice\r\n rebel2 -> ops.wcg.williams.com FTP R port=32817 rebel2 -> ops.wcg.williams.com FTP R port=32817 331 Password require ops.wcg.williams.com -> rebel2 FTP C port=32817 ops.wcg.williams.com -> rebel2 FTP C port=32817 PASShacker23\r\n rebel2 -> ops.wcg.williams.com FTP R port=32817 230 User jbrice logg ops.wcg.williams.com -> rebel2 FTP C port=32817 ops.wcg.williams.com -> rebel2 FTP C port=32817 QUIT\r\n rebel2-> ops.wcg.williams.com FTP R port=32817 221 Goodbye.\r\n

22. Warning! "." (or current directory) is in roots path!

23. Warning! /usr/adm/sulog is _World_ readable! • SU 10/08 09:35 + pts/2 jshaieb-root • So big deal,,,, well if I know that user jshaieb can access root, then maybe I should find vulnerabilities on the system that deal with user jshaieb.

24. Warning! /export/home/jshaieb/. ./.backdoor has 4755 permissions $ pwd /export/home/jshaieb/. . $ id uid=100(jshaieb) gid=1(other) $ ls -la total 0 drwxr-xr-x 2 root other 512 Oct 8 22:06 . drwxr-xr-x 15 jshaieb other 1024 Oct 8 22:06 .. -rwsr-xr-x 1 root other 200944 Oct 8 22:06 .backdoor $ ./.backdoor # id uid=100(jshaieb) gid=1(other) euid=0(root)

25. Warning! jshaieb has a UID of 0! jshaieb:x:0:1:Johnny Shaieb:/export/home/jshaieb:/usr/bin/ksh # who am i //the invoking user jshaieb pts/3 Oct 8 22:14 (192.168.2.100) # # # whoami //display the effective current username root # # # id uid=0(root) gid=1(other)

26. Warning! /usr/lib/sendmail could have a hole/bug! (CA-88:01) • Exploit • There is a serious bug in the mime7to8() function of sendmail 8.8.0 which allows anyone who can send you mail to execute arbitrary code as root on your machine. • Basically sendmail has a function called mime_fromqp() that does not like lines that ends "=\n", it chops those two characters off and returns 0 to indicate a continuation line. This causes the while loop to continue, which could eventually go beyond sendmail process's stack.. • This means an attacker can simply create a very large message inside a infinite while loop in which each line ends with “/bin/ksh=\n”.