textfiles/internet/intwrm.vir

A REPORT ON THE INTERNET WORM 
Bob Page 
University of Lowell 
Computer Science Department 
November 7, 1988 
 

[Because of the many misquotes the media have been
giving, this report is Copyright (c) Bob Page, all
rights reserved. Permission is granted to republish
this ONLY if you republish it in its entirety.] 

Here's the scoop on the "Internet Worm". Actually it's
not a virus - a virus is a piece of code that adds
itself to other programs, including operating systems.
It cannot run independently, but rather requires that
its "host" program be run to activate it. As such, it
has a clear analog to biologic viruses -- those viruses
are not considered live, but they invade host cells and
take them over, making them produce new viruses. 

A worm is a program that can run by itself and can
propagate a fully working version of itself to other
machines. As such, what was loosed on the Internet was
clearly a worm. 

This data was collected through an emergency mailing
list set up by Gene Spafford at Purdue University, for
administrators of major Internet sites - some of the
text is included verbatim from that list. Mail was
heavy since the formation of the list; it continues to
be on Monday afternoon - I get at least 2-3 messages
every hour. It's possible that some of this information
is incomplete, but I thought you'd like to know what I
know so far. 

The basic object of the worm is to get a shell on
another machine so it can reproduce further. There are
three ways it attacks: sendmail, fingerd, and
rsh/rexec. 

THE SENDMAIL ATTACK: 

In the sendmail attack, the worm opens a TCP connection
to another machine's sendmail (the SMTP port), 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 a temporary
second-stage bootstrap file called x$$,l1.c (where '$$'
is the current process ID). This is a small (40-line) C
program. 

The first-stage bootstrap compiles this program with
the local cc and executes it with arguments giving the
Internet hostid/socket/password of where it just came
from. The second-stage bootstrap (the compiled C
program) sucks over two object files, x$$,vax.o and
x$$,sun3.o from the attacking host. It has an array for
20 file names (presumably for 20 different machines),
but only two (vax and sun) were compiled in to this
code. It then figures out whether it's running under
BSD or SunOS and links the appropriate file against the
C library to produce an executable program called
/usr/tmp/sh - so it looks like the Bourne shell to
anyone who looked there. 

THE FINGERD ATTACK: 

In the fingerd attack, it tries to infiltrate systems
via a bug in fingerd, the finger daemon. Apparently
this is where most of its success was (not in sendmail,
as was originally reported). When fingerd is connected
to, it reads its arguments from a pipe, but doesn't
limit how much it reads. If it reads more than the
internal 512-byte buffer allowed, it writes past the
end of its stack. After the stack is a command to be
executed ("/usr/ucb/finger") that actually does the
work. On a VAX, the worm knew how much further from the
stack it had to clobber to get to this command, which
it replaced with the command "/bin/sh" (the bourne
shell). So instead of the finger command being
executed, a shell was started with no arguments. Since
this is run in the context of the finger daemon, stdin
and stdout are connected to the network socket, and all
the files were sucked over just like the shell that
sendmail provided. 

THE RSH/REXEC ATTACK: 

The third way it tried to get into systems was via the
.rhosts and /etc/hosts.equiv files to determine
'trusted' hosts where it might be able to migrate to.
To use the .rhosts feature, it needed to actually get
into people's accounts - since the worm was not running
as root (it was running as daemon) it had to figure out
people's passwords. To do this, it went through the
/etc/passwd file, trying to guess passwords. It tried
combinations of: the username, the last, first,
last+first, nick names (from the GECOS field), and a
list of special "popular" passwords: 

 

	aaa	cornelius	guntis	noxious	simon	
academia	couscous	hacker	nutrition	simple	
aerobics	creation	hamlet	nyquist	singer	
airplane	creosote	handily	oceanography	single	
albany	cretin	happening	ocelot	smile	
albatross	daemon	harmony	olivetti	smiles	
albert	dancer	harold	olivia	smooch	alex	
daniel	harvey	oracle	smother	alexander	
danny	hebrides	orca	snatch	algebra	dave	
heinlein	orwell	snoopy	aliases	december	
hello	osiris	soap	alphabet	defoe	help	
outlaw	socrates	ama	deluge	herbert	oxford	
sossina	amorphous	desperate	hiawatha	pacific	
sparrows	analog	develop	hibernia	painless	spit	
anchor	dieter	honey	pakistan	spring	
andromache	digital	horse	pam	springer	
animals	discovery	horus	papers	squires	
answer	disney	hutchins	password	strangle	
anthropogenic	dog	imbroglio	patricia	stratford	
anvils	drought	imperial	penguin	stuttgart	
anything	duncan	include	peoria	subway	aria	
eager	ingres	percolate	success	ariadne	
easier	inna	persimmon	summer	arrow	edges	
innocuous	persona	super	arthur	edinburgh	
irishman	pete	superstage	athena	edwin	isis	
peter	support	atmosphere	edwina	japan	
philip	supported	aztecs	egghead	jessica	
phoenix	surfer	azure	eiderdown	jester	
pierre	suzanne	bacchus	eileen	jixian	
pizza	swearer	bailey	einstein	johnny	
plover	symmetry	banana	elephant	joseph	
plymouth	tangerine	bananas	elizabeth	joshua	
polynomial	tape	bandit	ellen	judith	
pondering	target	banks	emerald	juggle	pork	
tarragon	barber	engine	julia	poster	
taylor	baritone	engineer	kathleen	praise	
telephone	bass	enterprise	kermit	precious	
temptation	bassoon	enzyme	kernel	prelude	
thailand	batman	ersatz	kirkland	prince	
tiger	beater	establish	knight	princeton	
toggle	beauty	estate	ladle	protect	
tomato	beethoven	euclid	lambda	protozoa	
topography	beloved	evelyn	lamination	
pumpkin	tortoise	benz	extension	larkin	puneet	
toyota	beowulf	fairway	larry	puppet	
trails	berkeley	felicia	lazarus	rabbit	
trivial	berliner	fender	lebesgue	rachmaninoff	
trombone	beryl	fermat	lee	rainbow	tubas	
beverly	fidelity	leland	raindrop	tuttle	
bicameral	finite	leroy	raleigh	umesh	bob	
fishers	lewis	random	unhappy	brenda	
flakes	light	rascal	unicorn	brian	
float	lisa	really	unknown	bridget	flower	
louis	rebecca	urchin	broadway	flowers	
lynne	remote	utility	bumbling	foolproof	
macintosh	rick	vasant	burgess	football	mack	
ripple	vertigo	campanile	foresight	maggot	
robotics	vicky	cantor	format	magic	
rochester	village	cardinal	forsythe	malcolm	
rolex	virginia	carmen	fourier	mark	romano	
warren	carolina	fred	markus	ronald	water	
caroline	friend	marty	rosebud	weenie	
cascades	frighten	marvin	rosemary	whatnot	
castle	fun	master	roses	whiting	cat	
fungible	maurice	ruben	whitney	cayuga	
gabriel	mellon	rules	will	celtics	gardner	
merlin	ruth	william	cerulean	garfield	mets	sal	
williamsburg	change	gauss	michael	saxon	
willie	charles	george	michelle	scamper	
winston	charming	gertrude	mike	scheme	wisconsin	
charon	ginger	minimum	scott	wizard	
chester	glacier	minsky	scotty	wombat	
cigar	gnu	moguls	secret 

	woodwind	classic	golfer	moose	sensor	
wormwood	clusters	gorgeous	morley	serenity	yaco	
coffee	gorges	mozart	sharks	yang	coke	
gosling	nancy	sharon	yellowstone	collins	
gouge	napoleon	sheffield	yosemite	commrades	
graham	nepenthe	sheldon	zap	computer	gryphon	
ness	shiva	zimmerman	condo	guest	network	
shivers	cookie	guitar	newton	shuttle	
cooper	gumption	next	signature 



[I wouldn't have picked some of these as "popular"
passwords, but then again, I'm not a worm writer. What
do I know?] 

When everything else fails, it opens /usr/dict/words
and tries every word in the dictionary. It is pretty
successful in finding passwords, as most people don't
choose them very well. Once it gets into someone's
account, it looks for a .rhosts file and does an 'rsh'
and/or 'rexec' to another host, it sucks over the
necessary files into /usr/tmp and runs /usr/tmp/sh to
start all over again. 

Between these three methods of attack (sendmail,
fingerd, .rhosts) it was able to spread very quickly. 

THE WORM ITSELF: 

The 'sh' program is the actual worm. When it starts up
it clobbers its argv array so a 'ps' will not show its
name. It opens all its necessary files, then unlinks
(deletes) them so they can't be found (since it has
them open, however, it can still access the contents).
It then tries to infect as many other hosts as possible
- when it sucessfully connects to one host, it forks a
child to continue the infection while the parent keeps
on trying new hosts. 

One of the things it does before it attacks a host is
connect to the telnet port and immediately close it.
Thus, "telnetd: ttloop: peer died" in /usr/adm/messages
means the worm attempted an attack. 

The worm's role in life is to reproduce - nothing more.
To do that it needs to find other hosts. It does a
'netstat -r -n' to find local routes to other hosts &
networks, looks in /etc/hosts, and uses the yellow
pages distributed hosts file if it's available. Any
time it finds a host, it tries to infect it through one
of the three methods, see above. Once it finds a local
network (like 129.63.nn.nn for ulowell) it sequentially
tries every address in that range. 

If the system crashes or is rebooted, most system boot
procedures clear /tmp and /usr/tmp as a matter of
course, erasing any evidence. However, sendmail log
files show mail coming in from user /dev/null for user
/bin/sed, which is a tipoff that the worm entered. 

Each time the worm is started, there is a 1/15 chance
(it calls random()) that it sends a single byte to
ernie.berkeley.edu on some magic port, apparently to
act as some kind of monitoring mechanism. 

THE CRACKDOWN: 

Three main 'swat' teams from Berkeley, MIT and Purdue
found copies of the VAX code (the .o files had all the
symbols intact with somewhat meaningful names) and
disassembled it into about 3000 lines of C. The BSD
development team poked fun at the code, even going so
far to point out bugs in the code and supplying source
patches for it! They have not released the actual
source code, however, and refuse to do so. That could
change - there are a number of people who want to see
the code. 

Portions of the code appear incomplete, as if the
program development was not yet finished. For example,
it knows the offset needed to break the BSD fingerd,
but doesn't know the correct offset for Sun's fingerd
(which causes it to dump core); it also doesn't erase
its tracks as cleverly as it might; and so on. 

The worm uses a variable called 'pleasequit' but
doesn't correctly initialize it, so some folks added a
module called _worm.o to the C library, which is
produced from: int pleasequit = -1; the fact that this
value is set to -1 will cause it to exit after one
iteration. 

The close scrutiny of the code also turned up comments
on the programmer's style. Verbatim from someone at
MIT: From disassembling the code, it looks like the
programmer is really anally retentive about checking
return codes, and, in addition, prefers to use array
indexing instead of pointers to walk through arrays. 

Anyone who looks at the binary will not see any
embedded strings - they are XOR'ed with 81 (hex).
That's how the shell commands are imbedded. The
"obvious" passwords are stored with their high bit set.


Although it spreads very fast, it is somewhat slowed
down by the fact that it drives the load average up on
the machine - this is due to all the encryptions going
on, and the large number of incoming worms from other
machines. 

[Initially, the fastest defense against the worm is is
to create a directory called /usr/tmp/sh. The script
that creates /usr/tmp/sh from one of the .o files
checks to see if /usr/tmp/sh exists, but not to see if
it's a directory. This fix is known as 'the condom'.] 

NOW WHAT? 

None of the ULowell machines were hit by the worm. When
BBN staffers found their systems infected, they cut
themselves off from all other hosts. Since our
connection to the Internet is through BBN, we were cut
off as well. Before we were cut off, I received mail
about the sendmail problem and installed a patch to
disable the feature the worm uses to get in through
sendmail. I had made local modifications to fingerd
which changed the offsets, so any attempt to scribble
over the stack would probably have ended up in a core
dump. 

Most Internet systems running 4.3BSD or SunOS have
installed the necessary patches to close the holes and
have rejoined the Internet. As you would expect, there
is a renewed interest in system/network security,
finding and plugging holes, and speculation over what
will happen to the worm's creator. 

If you haven't read or watched the news, various log
files have named the responsible person as Robert
Morris Jr., a 23-year old doctoral student at Cornell.
His father is head of the National Computer Security
Center, the NSA's public effort in computer security,
and has lectured widely on security aspects of UNIX. 

Associates of the student claim the worm was a
'mistake' - that he intended to unleash it but it was
not supposed to move so quickly or spread so much. His
goal (from what I understand) was to have a program
'live' within the Internet. If the reports that he
intended it to spread slowly are true, then it's
possible that the bytes sent to ernie.berkeley.edu were
intended to monitor the spread of the worm. Some news
reports mentioned that he panicked when, via some
"monitoring mechanism" he saw how fast it had
propagated. 

A source inside DEC reports that although the worm
didn't make much progress there, it was sighted on
several machines that wouldn't be on its normal
propagation path, i.e. not gateways and not on the same
subnet. These machines are not reachable from the
outside. Morris was a summer intern at DEC in '87. He
might have included names or addresses he remembered as
targets for infesting hidden internal networks. Most of
the DEC machines in question belong to the group he
worked in. 

The final word has not been written - I don't think the
FBI have even met with this guy yet. It will be
interesting to see what happens.