Lecture 5

1. Lecture 5 UNIX Security

2. Contents • UNIX login and user accounts • Unix Access control • UNIX instances of General Security Principles • Local Vulnerabilities and exposures • Auditing UNIX system from the inside • Remote Vulnerabilities and exposures • Auditing UNIX system from the outside

3. Login • identification + authentication: = (username, password) • password length: 8 characters • password protection: encrypted with Crypt(3), and stored in /etc/passwd file.

4. Format of the Password File • Format: • Username: encrypted password:user ID: Group ID: ID string: home directory: login shell • ID string = user’s full name • User ID and group ID = explained later. • Login shell: the Unix shell available to the user after successful login.

5. Format of the Password File • Displaying the password file: cat /etc/passwd • dieter:RT.QsZEEsxT92:100026:53:Dieter Gollman:/home/staff/dieter:usr/local/bin/bash • When the password field is empty, the user does not need a password for login. • If the password field starts with an asterisk, the user cannot login, because such values cannot be the results of an f(cleartext password).

6. Other Issues • Passwd(1): change password by supplying old one twice • Shadow password file: in security conscious version of Unix, it is stored in /.secure/etc/passwd • Expiry date and control of old password: set • Root login: can be restricted to terminals nominated in /etc/ttys

7. Users and Superusers • Users by user name, up to 8 characters • Users by user ID (UID) internally, a 16-bit number • UIDs are linked to user names in /etc/passwd. • Unix does not distinguish between users having the same UID.

8. Special User IDs • Superuser has UID 0, and the name root. • The root account is used by the operating system for essential tasks like login, recording the audit log, or access to I/O devices. • -2 nobody • 0 root • 1 daemon • 2 uucp • 3 bin • 4 games • 9 audit

9. Special User IDs • Almost all security checks are turned off for the superuser. • The root account performs also certain administrative tasks. • The systems manager should not use root as his personal account. • When necessary, changing to root can be requested by typing /bin/su without specifying a user name.

10. Super User and Protection • Remark: The superuser can do almost everything. • Remark: Every precaution has to be taken to control access to superuser status.

11. Control of Access to Superuser Status • The files /etc/passwd and /etc/group have to be write-protected. [UID => 0 in /etc/passwd] • Record all su attempts in the audit log together with the user (account) who issued the command. • Separate the duties of the system manager, e.g., by having special users like uucp or daemon to deal with networking. If one of these special users is compromised, not all is lost.

12. Groups • Fact: Users belong to one or more groups. • Why? Collecting users in groups is a convenient basis for access control decisions. • Example: put all users allowed to access email in a group called mail. • Primary group: contains every user. The group ID (GID) of the primary group is stored in /etc/passwd.

13. Set UserID and Set GroupID • Question: If /etc/passwd is read-only, how can you change your password? • Answer: controlled invocation, Set UserID Program (SUID). • Remark: temporarily take on the UID of the owner of the password file. (i.e., root)

14. Access Control • Tree Structure for files and directories

15. Unix File Structure • The directory is a pointer to a data structure, inode. • – use “ls –l” to find • Fields in the inode that are relevant to access control. • FIELDS in inode relevant to security • • mode : type of file access rights • • uid : user who owns the file • • gid : group which owns file • • atime: access time • • mtime: modification time • • itime: inode alteration • • block count: size of file • physical location

16. Unix File Structure • Each directory contains [“ls –a” gives all] • a pointer to itself, the file ‘.’ • a pointer to its parent directory, the file ‘..’ • Each file • has an owner, usually the user who created the file; • belongs to a group (its owner’s or directory’s group). • A newly created file belongs either to its creator’s group or its directory’s group.

17. Fields in inode • Inspect a directory with command ls -l • -rw-r--r-- 1 dieter staff 1617 Oct 28 11:01 d.tex • drwx------ 2 dieter staff 512 Oct 25 17:44 ads/ • The 1st character gives the type of file. ‘-’ a file, ‘d’ a directory, ‘b’ a block device file, ‘c’ a character device file. • The file permission (to be discussed later). • The link counter, the number of links (pointers) to the file. • The name of the owner and the group of the file. • The size of the file in bytes. • The date and time is mtime, the time of the last modification. • The name of the file. The ‘/’ after ads indicates a directory. • The permission bits are grouped in three triples (read, write and execute) access for owner, group, and other. • ‘-’ indicates no grant of right. • The uid, gid tell who own the file.

18. Changing Permissions with chmod by owner or superuser only • Absolute mode • chmod [-fR] absolute file specify the value for all permission bits • chmod 644 = 110100100 = rw-r--r-- • chmod 777 = 111111111 = rwxrwxrwx • chmod 755 = 111101101 = rwxr-xr-x • The option -f suppresses error messages, the option -R applies the specified change recursively to all subdirectories of the current directory. • Symbolic mode • will not introduced here. For details, see, page 91

19. Default Permissions • Unix utilities (e.g., editors or compilers): • 666 when creating a new file • 777 when creating a new program • Adjust the permissions by umask, specifying the rights that should be withheld. • umask 777 denies every access • umask 000 does not add any further restriction • 022 all for owner, r and x for group and other. • 077 all for owner, no for group and other. • umask value is in /etc/profile • actual default permission is computed as: • default ^ umask = 666 ^ 077 = 600 • A^B = A and [not(B)] (AND NOT)

20. Instances of General Security Principles • Deleting Files • Question: If we remove (delete) a file from the file system, does it still exist in some form? • Remark: We have to talk about how a file was constructed! • Two types of copying: cp, link and ln • cp: identical but independent file owned by the user running cp. • link, ln: only create a new file name with a pointer to the original file and increase the link counter of the original file.

21. Deleting Files • Conclusion: If a new file shares its content with the original, and if the original is deleted with rm or rmdir, it disappears from its parent directory, but its contents as well as its copy still exist. • Question: How do we get rid of a file? • The super user runs ncheck to list all the links to that file and then deletes those links. • Conclusion: Once a file has been deleted, the memory space allocated to this file becomes available again. However, until these memory locations have actually been used again, they will still contain the file’s contents. • Question: How do we get rid of a file? • Overwrite its contents with all-zeros before deleting it.

22. Protection of Devices • Information: Unix treats devices like files. Thus access to memory or a printer can be controlled like access to a file through setting permission bits. • How to create devices: use the mknod command which should only be executable by root. • /dev/console – console terminal • /dev/mem – main memory map device (image of the physical memory) • /dev/kmem – kernel memory map device (image of the virtual memory) • /dev/tty – terminal

23. Memory Device Must be Protected • An attacker can bypass the controls set on files on directories, if they can access to the memory devices holding these files. • If the read or write permission bits are set on a memory device, an attacker can browse through memory or modify data in memory without being affected by the permissions defined for the files stored in this memory. • Conclusion: Almost all devices should NOT be readable or write-able by others.

24. Attacks • Attacks are the result of one of two problems • Vulnerability • A weakness in a system that leads to unexpected, undesired, or unauthorized results. • Exposure • A state in system that is not a universal vulnerability. Includes a capability the behaves as expected, but can be compromised. • Vulnerabilities allow attackers to execute commands as another user. • Exposures allow an attacker to conduct information gathering.

25. Local/System V&Es • Physical Compromise Countermeasures • Secure the host and console in a cabinet or locked room. • Password protect console and BIOS • Disable booting from removable media • Password protect single user mode • Buffer Overflows Countermeasures • Disable the execution of code on the stack, via OS patch or kernel parameters. • Use safe programming practices: • strncpy() instead of strcpy() • char *strcpy(char *dest, const char *src); • char *strncpy(char *dest, const char *src, size_t n); • Remove SUID bit from executables that aren’t required for normal system operation. • Apply vendor OS and application patches.

26. Symlink Attacks • A symbolic link is a pointer file that names (or points to) another file elsewhere in the filesystem. • Sometimes programs create a temporary file in /tmp and modify the permissions such that other users can read or write the file. • Attackers pre-create a symlink file with the right name that points to a file they want to modify. • When the application does a chmod(), the target of the symbolic link will inherit the permissions of the chmod().

27. Symlink Attack - Countermeasures • Check to see if the application respects the $TMP environment variable. By setting $TMP to a directory that isn’t “world” writeable, you can prevent other users from creating symbolic links. • Apply vendor patches, or submit a complaint/bug report with the vendor if no patches exist.

28. Trojaned LKM Countermeasures • LKMs are loadable kernel modules: they’re code (usually device drivers) that get loaded by the kernel when access to the particular device is needed. • LKMs can be trojaned to modify the kernel in malicious ways; to mask a system cracker’s presence for example. • Countermeasure: compile a monolithic kernel with all device drivers included. (Only available in some OSes.) • http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-custom-kernel-monolithic.html

29. Audit Logs & IntrusionDetection • Auditing: records security relevant events in an audit log (audit trail) for later analysis. • Intrusion detection: detects suspicious events when they happen and inform the system manager by email or by messages sent to the operator console. • Comment: The audit log should be well protected from writing by an attacker.

30. Auditing your system (from inside) • Steps you need to take (we’ll go over each) • Verify most recent patches are applied to OS and applications • Disable unused services and daemons • Address user account and password issues • Protect from unauthorized remote access • Other general types of checks

31. Protecting the Audit Log • Set a “logical protection” on the audit log so that only privileged users have write access. • Sent the audit log to another computer where root on the audited machine has no superuser privilege. • Sent the audit log to a secure printer.

32. Auditing - Verify patches • Verify that you have installed the most recent OS and application patches • Most Operating System vendors and applications have web pages and mailing lists to announce product updates. • Some automated tools exist • up2date for OS and kernel updates to red hat Linux. • Debian is much more slick at this • Also gnorpm is helpful, but not great. • www.windowsupdate.microsoft.com (now has an automatic install)

33. Auditing - Unused services • Disable any unused services and daemons. • They may be exploited if they are vulnerable and you (the administrator) aren’t aware they’re running. • The commands “ps” and “netstat” are useful for determining which processes are running, and what (if any) network ports processes are listening on. • See Unix Review lecture notes or man pages for the use of ps and netstat.

34. Auditing - Unused services: “ps” • ps -e • shows information about all processes currently running on the system. • ps -l • shows, among other things, the priority of your job, the memory size in blocks of your process, and the cumulative CPU time of the process. • http://www.computerhope.com/unix/ups.htm#03

35. Using netstat to find open ports • netstat --inet --all (Linux, show network ports) • netstat -f inet (Solaris, Digital Unix) • netstat provides useful information regarding traffic flow. • In particular, netstat -i lists statistics for each interface, netstat -s provides a full listing of several counters, and netstat -rs provides routing table statistics. • netstat -an reports all open ports. • netstat -k provides a useful summary of several network-related statistics, but this option is officially unsupported and may be removed in a future release.

36. Auditing - Disabling stand-alone daemons • Disable stand-alone daemons that are started at boot time by modifying the “rc” start-up script. • rc is the command script which controls the startup of various services • For Example: sendmail In /etc/rc.d/rc2.d the sendmail startup script is S88sendmail. Move S88sendmailto s88sendmail and the “rc” process will ignore it. (The “rc” process is looking for all files starting with a capital letter) • On Linux this can also be done with the linuxconfand sysconfig utilities.

37. Various Daemons • S05kudzudetects and configures new and/or changed hardware on a system • S10networkActivates/Deactivates all network interfaces configured to start at boot time. • S11portmapmanages RPC connections, which are used by protocols such as NFS and NIS • S14nfslockNetwork File System (NFS) functionality • S16apmdbattery/power management for laptops • S20randomused for random number generation • S25netfsmounts NFS and Samba mount points • S30syslogassists programs in logging events • S35identdmatches users to TCP connections • S40atdlike cron, but for users • S40crondperiodically runs programs • S45pcmciafor supporting cards on laptops • S50inetstarts and runs inetd • S55xntpdRuns the Networks Time Protocol for syncing clocks

38. Services that should be firewalled • These services don’t need internet connectivity at all. • Anything NFS related • RPC services (remote procedure call) • Printer lpd • Probably don’t need these: • Sendmail (plenty of holes historically) • Qmail • BIND (DNS) • Replace all of these with ssh (scp, and sftp) • r-services: rsh, rlogin, rcp • telnet • ftp

39. Auditing - User accounts and passwords • Establish a clearly defined password policy • frequency of forced password changes • enforce mixture of alpha, numeric and other characters. • Educate users to not share or write down their passwords • Disable unused accounts • Enable shadowed passwords • Frequently do the following: • Check that all accounts have a password • Check if any accounts other than root have UID 0 • Run a password cracker to ensure secure passwords

40. Auditing- Unauthorized access • If you need to run the “r-services” (you don’t), make sure it’s done as securely as possible. • Disallow and periodically check for users’ .rhosts files. This file lists the hosts and users that are allowed to log into the user’s account via the r-services without providing a password. • Disallow /etc/hosts.equiv, which lists hosts considered to be “trusted” (i.e. users can connect via r-services from those hosts without supplying a password) • We will spend an entire class on how to exploit the rsh service.

41. Auditing-Unauthorized access • Don’t allow root to log directly; force user with root password to log in then “su” to root. • Or, only allow root to log in from the console. (Assuming the console is in a secure location) • On Linux, /etc/securetty contains a list of terminals that root can login from. • Why are you logging in as root at all? Don’t run programs or surf the web as root.

42. Auditing- Other things to check • Make sure root’s $PATH does NOT contain a “.” • $PATH is set to a list of directories where commands (binaries) can be found and is searched each time a command is executed. $PATH=/usr/bin:/usr/sbin:/usr/local/bin • Attack: malicious user Mallory looks at roots . profile and realizes root has “.” as part of the $PATH. Mallory creates a shell script in her home directory called “ls” which copies /usr/bin/bash to a specified location and make it SUID root. • Mallory then tells the admin . that there’s something wrong in her home directory, the admin goes to look in her home dir. and types “ls”. If the “.” is in the path before the directory that contains the real “ls”, Mallory’s “ls” will get executed, and Malloy will have access to an SUID root shell.

43. Local auditing Tools • COPS - Local system auditing application • Crack - Password cracking program for UNIX • netstat - Can be used to show “open” network ports. • lsof - Used to show network ports associated with processes. • Tripwire - Application to hash system files and periodically check to see if files have changed. • Bastille Linux - Linux “hardening scripts”

44. Other various suggestions • Why stay connected to the Internet all the time? • If you aren’t running a server, consider disconnecting network services at night, or while at work. • Don’t trust wireless services for several years or more. • Place them outside your firewall • Only use secure application level services above them, like ssh or secure web browsing. • Use xlock-locks the local X display until a password is entered • Use vlock-either locks the current terminal (which may be any kind of terminal, local or remote), or locks the entire virtual console system, completely disabling all console access. vlock gives up these locks when either the password of the user who started vlock or the root password is typed.

45. Remote Vulnerabilities and Exposures • Over the course of the semester we will be studying several remote vulnerabilities. • Some include: • Remote Buffer overflow • Session Hijacking • Unauthorized access to network services

46. Remote Buffer Overflow - Countermeasures • Disable the execution of code on the stack, via OS patch or kernel parameter • Use safe programming practices. • Apply vendor OS and application patches • Something you should do anyway for other types of exploits.

47. Session Hijacking - Countermeasures • Session hijacking is a method by which an attacker can steal a connection from another host. • The attacker can insert whatever it wants into the TCP stream • E.g., echo “* *” >> .rhosts • Such attacks are based on the ability of the attacker to guess the TCP initial sequence number during the three way handshake. • Apply system patches or tweak kernel variable to increase randomness of TCP initial sequence generation • Sufficiently randomizing TCP sequence numbers makes session hijacking more difficult.

48. Unauthorized Access to Network services - Countermeasures • IP based access control • TCP Wrappers • ftp://ftp.porcupine.org/unix/security • Secure portmapper/rpcbind • ftp://ftp.porcupine.org • NFS shares (/etc/exports, /etc/dfs/dfstab)

49. tcp_wrappers • IP based access control to services spawned by inetd can be configured using the tcp_wrappers package developed by Weitse Venema. • Stand alone daemons such as ssh, sendmail and secure portmapper/rpcbind can be compiled using libwrap.a, a shared library which provides tcp_wrappers access control. • tcp_wrappers uses the configuration files /etc/hosts.allow and /etc/hosts.deny to determine whether or not a specific host can gain access to a service.

50. tcp_wrappers • Example:Check out the line for telnet in /etc/inetd.conf:telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd"tcpd" is the wrapper program, and it calls in.telnetd (the telnet daemon) after it "authenticates" the remote host for a service.The best and most paranoid method of configuring is denying all services to all hosts; • then give explicit permissions to those you want to be able to connect on an individual service basis. • Why not disallow access to your home machine from all hosts but a specific machine at UMass?