20-755: The Internet Lecture 11: Secure services

1. 20-755: The InternetLecture 11: Secure services David O’Hallaron School of Computer Science and Department of Electrical and Computer Engineering Carnegie Mellon University Institute for eCommerce, Summer 1999

2. Today’s lecture • Vulnerabilities of hosts (30 min) • Break (10 min) • Vulnerabilities of hosts on networks (45 min)

3. Approach for this lecture • Microscopic view of security • Focus on specific holes (vulnerabilities) and related attacks. • Your security course will provide a more macroscopic view with theory and defensive strategies. • Focus on Unix • Unix sources available to everyone and open to scrutiny by experts. • Many holes and attacks are documented and well understood. • Other operating systems have similar flaws • Situation might be worse because of the triple whammy of closed sources (and thus limited scrutiny), incomplete disclosure of attacks and holes, and crushing complexity. • e.g., Linux: < 1M source lines, NT: ~30M source lines

4. Vulnerabilities of single hosts • World-readable /etc/passwd file • A “superuser” with all privileges • The suid protection bit • Single-user mode • “.” in search path

5. Security hole:Unix world-readable /etc/passwd file • Description of hole • Each Unix system contains a world-readable (i.e., readable by anyone) file called /etc/passwd • /etc/passwd contains a list of all users with (among other things) their login id and an encrypted password. encrypted password home directory login name login shell bdz:.X2azkaN0o2pE:3249:443:Brian Zill:/afs/cs/user/bdz:/usr/cs/bin/csh droh:fLYCRbpUo8ETU:3478:92:Dave OHallaron:/usr2/droh:/usr/cs/bin/csh wvcii:fZsTEJhL3r75c:3524:443:Bill Courtright:/usr3/wvcii:/usr/cs/bin/csh

6. Security hole: Unix world-readable /etc/passwd file • Example attack: Dictionary attack • Try to exploit the fact that people often use common easily remembered English words as passwords. • For each user in /etc/passwd • For each word in the online dictionary /usr/dict/words • compare encrypted word to the encrypted password for user • Points out a serious weakness with the notion of passwords • Many users have numerous accounts that require passwords. • Puts onus on users to remember all these passwords. • Many use the same password for all accounts out of necessity.

7. Security hole:Unix superuser (root) • Description of hole: • The user whose login ID is root can inspect, modify, delete, and execute any file. • Root login is often called the superuser. • Reason for superuser: • Someone has to administer and manage the system.

8. Security hole:Unix superuser (root) • Example attack: Obtain root password • An attacker obtains the root password via... • lucky guess • dictionary attack • “social engineering” • tricking someone into divulging password • packet sniffing unencrypted passwords • Attacker can then... • delete files • or create a root shell using setuserid (next example) • or modify the password file

9. Security hole:Unix setuserid protection bit • Description of the hole • Alice creates an executable program called suidprog. • Alice sets the “setuserid” (suid) protection bit • chmod +s suidprog • Any user who runs suidprog runs with all of Alice’s permissions. • Extremely useful for giving users access to system resources in a controlled way • e.g., using “ps -aux” to list all the processes running on a system. • requires access to protected files in /dev

10. Security hole:Unix setuserid protection bit • Example attack: • Attacker with root password logs in as root and creates a shell program with the suid bit set. • cp /usr/local/bin/tcsh . • suid +s tcsh • mv tcsh innocent_looking_program • Attacker can now run a shell with root privileges forever, even if the root password is changed the next day.

11. Security hole: Unix single user mode • Description of the hole • When machine is turned on (I.e., booted up) the person at the console has the option to boot in “single user mode” • LILO boot: linux single • When boot is complete, the user is logged in as root

12. Security hole:Unix single-user mode • Sample attack: Obtain physical access • Attacker gets physical access to a machine and boots machine in single-user mode • Attacker now has root privilege and can inspect, modify, run, or delete any file on the system. • Example: • Attacker adds an account for himself by editing /etc/passwd. • Attacker can hereafter login remotely with telnet • Example: • Attacker creates suid program with root privileges • Bottom line: • Anyone with physical access and enough time can break into any Unix or Windows machine.

13. Security hole:“.” in search path • Description of hole: • users often put “.” (i.e., the current directory) at the beginning of their search path. • This tells the shell to look first in the current directory for programs that the user wants to run. • Convenient because user doesn’t have to type “./foo” every time they want to run a program foo in the current directory. • Can type “foo” instead. Here’s the “.” euro.ecom.cmu.edu> printenv PATH .:/afs/cs.cmu.edu/user/droh/bin:/bin:/usr/bin:/usr/local/bin: /usr/ucb:/usr/sbin:/sbin:/usr/misc/bin:/usr/bin/X11

14. Security hole: “.” in search path • Example attack: classic Trojan horse • Alice creates an executable file called “ls” in her home directory that when executed: • copies a shell program to home directory • sets suid bit on shell program • renames shell to something innocuous • then invokes the real “ls” command • This version of “ls” is a Trojan horse • masquerades as the real ls program. • Later, a root user with “.” as the first entry in the search path does an “ls” in Alice’s home directory. • When the command finishes, Alice now has a shell program in her directory that allows her to run as root.

15. Break time!

16. Today’s lecture • Vulnerabilities of hosts (30 min) • Break (10 min) • Vulnerabilities of hosts on networks (45 min)

17. Vulnerabilities of hosts on networks • Servers that don’t authenticate clients. • Spoofability of email • Servers that accept requests from any client. • Servers that run other programs. • “..” in CGI URIs • back quotes in CGI URI program names • backquotes in CGI URI arguments • Servers that don’t check input sizes • Case study: The 1988 Internet Worm

18. Security hole:“Spoofability” of email • Description of hole: • the sendmail server doesn’t authenticate the identity of a client that sends mail sendmail server(25) email client SMTP conversation (Simple Mail Transfer Protocol) email message User’s mailbox email messages email client

19. Example attack:Spoofing email euro.ecom.cmu.edu> telnet kittyhawk.cmcl.cs.cmu.edu 25 Trying 128.2.194.242... Connected to kittyhawk.cmcl.cs.cmu.edu. Escape character is '^]'. 220 kittyhawk.cmcl.cs.cmu.edu SMTP, Problems to: Help@FAC.CS.CMU.EDU HELO euro.ecom.cmu.edu 250 kittyhawk.cmcl.cs.cmu.edu MAIL FROM: <bogususer@foobar.com> 250 OK RCPT TO: <droh@cs.cmu.edu> 250 Rcpt OK DATA 354 Enter Mail, end with a '.' Note: Text in red is what the spoofer types

20. Example attack:Spoofing email From: bogususer@foobar.com To: droh@cs.cmu.edu Subject: You're our grand prize winner! Dear David O'Hallaron: We at foobar.com are happy to announce that you are our grand prize winner. To claim your prize, please send $100 to PO Box 666, Las Vegas, NV. Have a nice day, The staff and management of foobar.com. . 250 Sub & q (msg.aa24684) QUIT 221 Goodbye Connection closed by foreign host. euro.ecom.cmu.edu>

21. Example attack:Spoofing email Email message received by droh@cs: From: bogususer@foobar.com To: droh@cs.cmu.edu Subject: You're our grand prize winner! Dear David O'Hallaron: We at foobar.com are happy to announce that you are our grand prize winner. To claim your prize, please send $100 to PO Box 666, Las Vegas, NV. Have a nice day, The staff and management of foobar.com.

22. Security hole:Servers that accept requests from any client • Description of hole: • A server accepts any number of requests from any number of clients. • Reasonable approach for ecommerce site that wants to give access to everyone.

23. Security hole:Servers that accept requests from any client • Example attacks: Denial of service attacks • Attacker sends a stream of requests to server. • Effectively denies service to other clients. • Attacker sends a series of partial connection requests • Consumes limited socket resources on host until host is no longer able to accept connections. • Attacker with access to packet filter can spoof the “From” address field in TCP/IP packets. • Very difficult to defend against.

24. Security hole:“..” in CGI URI • Description of hole: • Server allows a “..” (I.e., the parent directory) in CGI URIs • Example attacks: • Example: delete user files • /cgi-bin/../../bin/rm /usr/kilroy/* • action: server creates shell process, which executes • . /cgi-bin/../../bin/rm /usr/kilroy/* • Example: create login account for attacker • /cgi-bin/../../usr/local/bin/tcsh -c “echo ‘droh:fLYCRbpUo8ETU:3478:92:Dave OHallaron:/usr2/droh:/usr/cs/bin/csh’ >> /etc/passwd” • action: server creates shell process, which executes • ./cgi-bin/../../usr/local/bin/tcsh -c “echo ‘droh:fLYCRbpUo8ETU:3478:92:Dave OHallaron:/usr2/droh:/usr/cs/bin/csh’ >> /etc/passwd”

25. Security hole:back quotes in CGI URI prognames • Description of hole: • Allow back quotes “`” in the program name part of a CGI URI • Example attack: • create login directory for attacker • /cgi-bin/`tcsh -c “echo ‘droh:fLYCRbpUo8ETU:3478:92:Dave OHallaron:/usr2/droh:/usr/cs/bin/csh’ >> /etc/passwd”` • action: server creates shell process, which executes • tcsh -c “echo ‘droh:fLYCRbpUo8ETU:3478:92:Dave OHallaron:/usr2/droh:/usr/cs/bin/csh’ >> /etc/passwd”

26. Security hole:back quotes in CGI URI args • Description of hole: • Allowing backquotes in the arguments to a CGI script. • Example attack: • programmers need to call existing programs from within CGI scripts • e.g., database access programs. • these database programs take arguments • if the arguments contain back quotes, then when the database program is invoked inside the CGI script, then the shell will execute the command inside the backquotes, which could be something like catting a new line to the /etc/password file. • dbprogram `bad program` $arg2 $arg3

27. Security hole:Servers that don’t check input sizes • Description of hole: • Servers that use C library routines such as gets() that don’t check input sizes when they write into buffers on the stack. local variables Stack frame for proc a proc a { b(); # call procedure b } return addr 64 bytes for buffer proc b { char buffer[64]; # alloc 64 bytes on stack gets(buffer); # read STDIN line into stack buffer } Stack frame for proc b return addr

28. Servers that don’t check input sizes • Vulnerability stems from possibility of the gets() routine overwriting the return address for b. local variables proc a { b(); # call procedure b } # b should return here, instead it # returns to an address inside of buffer return addr exec(“/bin/sh”) proc b { char buffer[64]; # alloc 64 bytes on stack gets(buffer); # read STDIN line to stack buffer } attacker’s return addr

29. Security hole:Servers that don’t check input sizes • Example attack: classic buffer overflow attack • Early versions of the finger server (fingerd) used gets() to read the argument sent by the client: • finger droh@cs.cmu.edu • To attack fingerd, send a binary string that puts a program to execute a shell on the stack followed by a new return address to that stack location, padded with enough bytes so that it overwrites the real return address. • finger “program padding new return address” • After the finger server reads the argument from the client, the client has a direct TCP connection to a root shell running on the server! • STDIN and STDOUT on the server are bound to the connection socket for the TCP connection. • Bottom line: client can now execute any command on the server.

30. Case study:The 1988 Internet Worm • Worm: an independent program that replicates itself across the host machines on a network. • November 1988: Thousands of Sun and DEC machines on the Internet are attacked by a “worm” written by Cornell grad student Robert Morris. • Because of a bug in the worm, it replicated itself multiple times on many of the Internet hosts, causing them to crash. • had the effect of a denial of service attack • Resulted (after a similar attack weeks later) in the formation of CERT (Computer Emergency Response Team) and better awareness of security.

31. Worm overview • Main program: • Once running on a local host, the main program collects names of other remote hosts on the network • Main program then attempts to exploit a number of security holes in order to create a TCP connection between the local host and a shell running on the remote host: • dictionary attack on world-readable /etc/password file, followed by an attempted remote login using rsh. • buffer overflow attack on the finger server. • sendmail DEBUG attack (not explained here) .

32. Worm overview • Bootstrap (grappling hook) program • The main program transfers the source code for a short bootstrap program (99 lines of C code) to the remote host, compiles it, and executes it. • The bootstrap program then transfers a binary version of the main program across the open TCP connection and runs it. • The main program begins looking for new hosts to infect and the process repeats.