Hacking Unix and Unix Security

1. Hacking Unix andUnix Security Lesson 11

2. Let’s talk about Unix and Security • Passwords • Originally passwords in /etc/passwd. World readable as numerous programs needed access to information contained in it (more than just passwords, UID, GID, preferred shell, etc…) • Passwords encrypted in file using one-way hash so you can’t decrypt them. • Cracking accomplished by finding a hash for another for a word that matches your password hash, thus your password • Since having /etc/passwd world readable makes it easier for folks to grab password file to crack, systems generally now utilize a shadow file in a location such as /etc/shadow • Change password with passwd command • Unless NIS is being used, then use yppasswd

3. Users, Groups, and the Superuser • Some common users you may find in the /etc/passwd file: • root– the superuser • daemon or sys– associated with some utility systems on some versions of Unix • guest– used for site visitors • ftp– used for anonymous ftp access • uucp– manages the UUCP system (unix to unix copy program) • lp– used for the printer system • nobody– a user that owns no files and is sometimes used as a default user for unprivileged operations.

4. Users, groups, superuser • User Identifiers (UIDs) • A mapping between the username and the UID is kept in the /etc/passwd file. • The OS actually uses the UID for identifying a user and his/her processes. The username is just a convenience for the human user. • If two users are assigned the same UID, as far as Unix is concerned they are the same user. • Generally considered a bad idea

5. Users, groups, superuser • Every Unix user belongs to one or more groups. • Groups have both a groupname and group identification number (GID). • Each user belongs to a primary group. This GID is stored in their entry in the /etc/passwd file. • Groups provide a handy mechanism to handle several users in a specified way. • Groups can be used to restrict access to sensitive information or specific programs. • /etc/group file contains the list of groups with their names, GID, and list of users in the group. • Wheel group on some systems is group 0, the sysadmins • Users listed in groups in this file are in addition to their primary group found in the /etc/passwd file

6. Users, groups, superuser • The superuser has a UID of 0 and is usually called root. • The superuser can exercise almost complete control over the system. • Generally good idea to NOT have sysadmin log in as root. Create another account so that in case a mistake is made you don’t trash the system. • Security checks turned off for Superuser. • Thus, remote logging in for root considered a bad thing, should not be allowed. • Sysadmins should log in using their own account and su to root. This makes tracking who is using root account easier. • su – “substitute user” • You can restrict login of root to specific terminals on some versions of UNIX. Thus, you will need to have two passwords to be able to gain root access.

7. Log files • Different versions of Unix store messages in different files. • /etc/syslog.conf file on Linux to identify where log messages will go. • /var/adm/messages – a possible place message may be found • May also be in /var/log/messages • /var/adm/sulog – another possibility, used to log su attempts • /var/log/secure

8. inodes • Unix uses a system called inodes (index nodes) to implement the file system. Each inode contains: • Location of the item’s contents on the disk • Pointers to the locations where file is stored, indirect blocks used for larger files • The item’s type • The item’s size • The time the inode was last modified • The time the file’s contents were last modified • The time the file was last accessed • A reference count (the number of names the file has) • The file’s owner (UID) • The file’s group (GID) • The file’s mode bits (file permissions or permission bits)

9. The ls command % ls –lF total 161 -rw-r--r-- 1 fred user 505 Feb 9 12:10 file1 -rw-rw-r-- 1 fred marketing 1234 Feb 10 13:20 client_lst -rwx--x--- 1 fred user 223433 Jan 29 09:17 stats* • - The file’s type. For regular files this field is always a dash • rw-r--r-- The file’s permissions • 1 The number of “hard” links to the file; the number of “names” for the file • fred The name of the file’s owner • user The name of the file’s group • 505 The file’s size in bytes • Feb 9 12:10 The file’s modification time • file1 The file’s name

10. The ls command with –F option % ls –lF total 161 -rw-r--r-- 1 fred user 505 Feb 9 12:10 file1 -rw-rw-r-- 1 fred marketing 1234 Feb 10 13:20 client_lst -rwx--x--- 1 fred user 223433 Jan 29 09:17 stats* • The –F option for the ls command prints a special character after the filename to indicate what type of file it is. • If blank then regular file or named pipe (FIFO) • If “*” then executable program or command file • If “/” then a directory • If “-” then a socket • Socket used for interprocess communication by generalizing file I/O • If “@” then a symbolic link

11. Understanding File permissions % ls –lF total 161 -rw-r--r-- 1 fred user 505 Feb 9 12:10 file1 -rw-rw-r-- 1 fred marketing 1234 Feb 10 13:20 client_lst -rwx--x--- 1 fred user 223433 Jan 29 09:17 stats* drwxr-xr-x 1 fred user 512 Feb 1 10:11 saved/ • The first character of the file’s mode field indicates the type of file. • If “-” then just a plain old ordinary file • If “d” then it’s a directory • If “c” then it’s a character device (tty or printer) • If “b” then it’s a block device (usually disk or CD-ROM) • If “l” then it’s a symbolic link (BSD or V.4) • If “s” then it’s a socket (BSD or V.4) • If “=“ or “p” then FIFO pipe (System V, Linux)

12. Understanding File permissions % ls –lF total 161 -rw-r--r-- 1 fred user 505 Feb 9 12:10 file1 -rw-rw-r-- 1 fred marketing 1234 Feb 10 13:20 client_lst -rwx--x--- 1 fred user 223433 Jan 29 09:17 stats* drwxr-xr-x 1 fred user 512 Feb 1 10:11 saved/ • The next nine characters, taken in groups of three, indicate who on your computer can do what with the file. There are 3 permissions: • r – permission to read • w – permission to write • x – permission to execute • The three groups represent the different classes of individuals, taken from the left in groups of three: • Owner • Group, users who are in the file’s group • World (other), everybody else on the system

13. Changing permissions % ls –lF total 161 -rw-r--r-- 1 fred user 505 Feb 9 12:10 file1 -rw-rw-r-- 1 fred marketing 1234 Feb 10 13:20 client_lst -rwx--x--- 1 fred user 223433 Jan 29 09:17 stats* drwxr-xr-x 1 fred user 512 Feb 1 10:11 saved/ • The chmod command is used to change a file’s permissions • chmod [-Rfh] [agou] [+-=] [rwxXstugol] filelist • Changes the permissions of filelist which can be either a single file or group of files • agou: specify whose privileges are being modified, can have none, one, or more • a=modify privileges for all users • g=modify group privileges • o=modify others’ privileges • u=modify owner’s privileges • +-= specify what is supposed to be done with the privileges • + adds to current privilege, - removes from current privilege, = replaces current privilege • rwxXstugol specify which privilege is to be adjusted (some Unix variant specific) • r is for Read access • w is for write access • x is for execute access • s is for SUID or SGID • t is for the sticky bit • Rfh depends on variant, • R for recursive if filelist a directory, f to suppress error messages, h to not perform operation on links

14. Changing permissions % ls –lF total 161 -rw-r--r-- 1 fred user 505 Feb 9 12:10 file1 -rw-rw-r-- 1 fred marketing 1234 Feb 10 13:20 client_lst -rwx--x--- 1 fred user 223433 Jan 29 09:17 stats* drwxr-xr-x 1 fred user 512 Feb 1 10:11 saved/ • Some examples • chmod o-r client_lst /* removes ability for others to read client_lst */ • chmod g+w file1 /* adds ability for group to write to file1 */ • Can also use octal representation • chmod 711 stats /* gives everybody execute, owner also rw */ • 7 = 111, thus rwx • 1 = 001, thus just x

15. The umask • Short for “user file-creation mode mask” • A four-digit octal number that UNIX uses to determine the file permission for newly created files. • Every process has its own umask, inherited from its parent process. • Specifies the permissions you do NOT want given by default to newly created files and directories. • Normally set in your .login, .cshrc, or .profile files. • e.g. umask 033 /* would turn off wx for folks in/* /* group and others */

16. Directories and permissions • What do the values for rwx mean for directories? • r: you can use ls to find out what is in the directory • w: you can add, rename, or remove entries in the directory • x: you can determine the owners and the lengths of the files in the directory. You also need execute to make the directory your current working directory or to open files inside the directory.

17. SUID, SGID, and Sticky Bits • Sometimes unprivileged users must be able to accomplish tasks that require privileges • e.g. passwd program needs to write to password file which users normally don’t have write permissions for. • Users can assume another UID or GID when running a program. A program that changes its UID is called a SUID program (set UID). • When a SUID program is run, its effective UID becomes that of the owner of the file, rather than the user who is running it. • If a program is SUID or SGID, the output of the ls –l command will have the x in the display changed to an s. If the program is sticky, the last x changes to a t. • Sticky bit originally used to speed up swapping for files often used, now if with directory limits who can remove or rename files • Obvious security implications with SUID • If person were to execute: • cp /bin/sh /tmp/specfile /* create copy of sh */ • chmod 4755 /tmp/specfile /* SUID so it runs as if your UID */

18. SSH • Secure SHell • Most commonly used as a secure replacement for telnet, rsh, rcp, and rlogin. • Offers secure TCP communications between any two systems regardless of what untrusted systems might be between them • Uses public key encryption techniques to encrypt each message. • Check www.ssh.org or www.openssh.com

19. Remote versus Local Access • Remote Access: “gaining access via the network or other communication channel.” • Local Access: “having an actual command shell or login to the system.” • Also known as privilege escalation attacks. • Attackers may (often) start with a remote access attempt. If successful in obtaining shell access then they are considered local for further attempts.

20. Remote Access • Four primary methods used to remotely circumvent the security of a UNIX system. • Exploit a listening service • If it isn’t listening, it can’t be broken into. • Route through a UNIX system • Kernel had IP forwarding turned on (more on this in later chapter) • User-initiated remote execution attacks • A hostile web site or Trojan horse email • Promiscuous mode attacks • There are ways to exploit a NIC that has been placed in promiscuous mode.

21. Brute Force Attacks • Nothing more than guessing a user ID/password combination on a running service that includes authentication. (Implies we need usernames!) • Common services to brute force: • Telnet • FTP • The “R” commands (rlogin, rsh, …) • SSH • SNMP community names • Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) • HTTP • Several tools to help with “brute-forcing” • Brutus, brute_web.c, pwscan.pl, …

22. Data Driven Attacks • Executed by sending data to an active service that causes unintended or undesirable results. • Buffer Overflow Attacks • Nov 1996 Phrack Magazine article “Smashing the Stack for Fun and Profit” • “On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address.” • “A buffer overflow is the result of stuffing more data into a buffer than it can handle.” • “How can we place arbitrary instruction into its address space? The answer is to place the code we are trying to execute in the buffer we are overflowing, and overwrite the return address so it points back into the buffer.” • Associated with certain commands such as strcpy(), strcat(), and sprintf(). • If we find a program that has one of these in it, and we overflow the buffer, we may be able to execute a shell. If the original program was running as root, so will this shell!

23. Buffer overflow attacks • To exploit a buffer overflow (beyond simply crashing the program) takes quite a bit of sophistication. • Fortunately, there are others who have already written exploit code for us so we don’t have to. • Exploit code for buffer overflows very system specific. • Buffer overflows are problems at the coding level and the real solution is secure programming practices. • For administrators the best thing you can do is to ensure all appropriate patches have been installed.

24. Input Validation Attack • An input validation attack occurs when: • A program fails to recognize syntactically incorrect input. • A module accepts extraneous input. • A module fails to handle missing input fields. • A field-value correlation error occurs. • An early example of this was the PHF vulnerability that came standard with early versions of the Apache web server. • The program did not properly parse and validate input it received. • A newline character could be sent which would cause subsequent commands to be executed with the privilege that the web server was running at. • Common early exploit was to cause it to execute cat command to print password file which gave user names and encrypted passwords which could then be cracked.

25. Gaining Shell access and other remote attacks • What we want to be able to do is have shell access. • Number of different techniques described in text. • FTP: useful but frequently anonymous use allowed. • Is file system restricted? World-writable directory? (if so, watch out for .rhosts files) • Sendmail • Numerous exploits over the years, as far back as 1988 when Morris worm exploited a vulnerability in sendmail as part of its capability to gain access to systems. • Numerous other possible attacks, check textbook for more details…

26. Local Access • Password cracking possible if you can obtain password file in /etc/passwd or shadow file. • Number of Unix password crackers that can be run on both Unix and Windows platforms. • Buffer overflows are a problem here as well. • Check file and directory permissions as they may not have been set to be secure. • Number of other possibilities, again, check the text.

27. Rootkits • After gaining root, one of the first things an attacker will want to do is install a rootkit. • A rootkit generally consists of: • Trojan programs such as altered versions of login and ps. • Backdoors • Sniffers • System log clearers • Some of the latest rootkits are kernel rootkits which modify the OS kernel. • A Loadable Kernel Module (LKM) allows a running kernel to be modified without having to compile it into the kernel.

28. The 7 most deadly sinsfrom Real World Linux Security 2ed • The list was created to help folks secure systems, for us it provides ideas to test. • Weak and Default Passwords • Open Network Ports • Old Software Versions • Insecure and Badly Configured Programs • Insufficient Resources and Misplaced Priorities • Stale and Unnecessary Accounts • Procrastination

29. Summary • What is the importance and significance of this material? • Unix has been around for a long time and versions of Linux have been cutting into MS dominance. • How does this topic fit into the subject of “Security Risk Analysis”? • Need to know how to attack these systems. Also need to know how these systems work as many tools are designed for Unix environment.