The Morris worm to Nimda
how little we've learned or gained
by: Ron DuFresne
(c) 2002
2001 was a tumultuous year. Prior to the September 11 airline attacks on
three sites in the United States costing thousands of lives and causing
recessive economies across the globe to hit near depression levels, we
had an influx of security attacks that continues to affect thousands of
systems throughout the world. First there were the various Code Red worm
variants, and then the Nimda worm, all working their nasty mechanisms in
quick succession, and at some corporate sites brining their systems to
grinding halts, even clogging their bandwidth with relentless torrents of
abusive code seeking new live on uninfected systems elsewhere.
Not long after these events, while reading the October issue of
Information Security magazine put out by Trusecure Publications, which
offered an nice interview with Ian Goldberg, titled Chief Cypherpunk. The
article was very informative and captivating. And there was one area of
the interview that really raised our eyebrows here, it was concerning
Ian's 1995 article on Internet Security and commence, the interviewer was
asking Ian how much had changed in the six years since that articles
release, to which Ian asked back "Have you been hit by the SirCam worm?"
The interviewer acknowledged how easy it was for this nasty bit of code to
enter enterprise systems and continue it's bastardly assault across
systems. Ian responded:
Right. Back in 1988 we had the Morris worm caused by a
buffer overflow, which was a pretty new thing, a really
cool way to penetrate systems.
The Trusecure interviewer interjected; "And buffer overflows are still a
problem." Furthering this response again from Ian:
Right! Thirteen years later, they still do buffer overflows.
It's crazy. We've learned nothing.
There is not a security practitioner in the IT industry that could read
this without shrugging, shaking their head in acknowledgment, and
wondering when code writers producing applications might well wakeup and
take note. It prompted us to review once again Eugene H. Spafford's
analysis of the Morris worm, and it's aftermath. A document recommended
to all security related folks in the IT industry and administrators in
general, if for nothing more then an eye-opener.
It was surprising to note how little has really changed since 1988 and the
release and cleanup after the Morris worm outbreak, as well as the few
changes that have come to pass. For one, the Morris outbreak was very
short lived. Having been released on November 2nd of that year, it spread
very quickly and brought many systems to their knees as is common in worm
outbreaks to this day, yet, the cleanup process was rather short compared
to what we now face, and Mr. Spafford reported that the last effects of
the worm were wiped out by early December of 1988. Not so now days, the
Internet is much bigger now then it was back then, in what we here like to
refer to as the Internet's teen years. Now in the early adult years of
the Internet, the affects of a worm with a payload as devastating as the
Morris worm's like those mentioned in our topic and the many others
released in recent times can persist for years.
The lack of skilled administrators and security personnel was cited in
Spafford's review, when it came to the topic of accountability. This is a
common topic of the security related mailing lists and Usenet groups to
this day. Mr. Spafford said specifically:
The claim that the victims of the Worm were somehow responsible
for the invasion of their machines is also curious. The
individuals making this claim seem to be stating that
there is some moral or legal obligation for computer users to
track and install every conceivable security fix and mechanism
available. This totally ignores the many sites that run turn-key
systems without source code or administrators knowledgeable
enough to modify their systems. Those sites may also be running
specialized software or have restricted budgets that prevent them
from installing new software versions. Many commercial and
government sites operate their systems this way. To attempt to
blame these individuals for the success of the Worm is
equivalent to blaming an arson victim for the fire because
she didn't build her house of fireproof metal.
Outlooks in this area might well be changing in the e-commerce arena that
the Internet is being exploited for by many companies and organizations
these days. We have governments now working to protect individual
privacy here and in Europe. And there have been great rumblings in the
security arena about Microsoft's poor certification programs and their lack
of security training. Yet, all too often, because of the lack of skills
in the administrative area as well as the fact that most IT departments
are so scarcely staffed, responsibility and accountability is often
avoided by those responsible for maintaining the systems that are placed in
exposed settings. It is very reminiscent of the rumblings recently by the
security contractors at many of our countries airports, which mirrors
societies issues of responsibility and accountability for the last 4-5
decades. This has worked, along with the wishes to make a quick buck from
ISP's and those connecting people across the globe to the Internet, to
make it difficult, if at times near impossible in getting a system
attacking another to be removed from the Net until it is at least fixed
and no longer a threat to others. This is one of the reasons that some of
the most recent worms have worked because administrators had not applied
patches that would have prevented things like the code red variants and
Nimda from succeeding had 'due diligence' been employed on those systems
exploited by these nasty bits of code. I guess here I'd like to counter
the Spafford's argument against placing blame on those responsible for
maintaining systems attached to the Internet by likening it more to the
car industries original reluctance to include seatbelts in vehicles. It
took legislation to finally get compliance in that realm, and it appears
it is going to take much tougher legislation to get the same results in
systems management and network security, once again, look at the airline
and travel industry in light of the September 11 2001 attacks and you
should get a good take on the picture we are painting here. In the very
least, jobs should be on the line when companies are compromised by code
that could have long been prevented by patching of applications and OS's,
especially when those patches have been widely available and publicly
announced. Even an arson victim faces penalties if they have violated
building codes that contributed to the disaster forced upon them by a
criminal. And we have not even broached the topic here of vendor
responsibility...
references:
The Internet Worm Incident Technical Report CSD-TR-933 *Eugene H. Spafford
Information Security October 2001 *Trusecure Publications
| Hosted by: |
|