A Brief Look at the

Evolution of Killer Worms

Paul A. Henry MCP+I, MCSE, CCSA, CCSE, CFSA, CFSO, CISSP, CISM, CISA

CyberGuard Corporation

A CyberGuard Corporation White Paper A Brief Look at the Evolution of Killer Worms Paul A. Henry MCP+I, MCSE, CCSA, CCSE, CFSA, CFSO, CISSP, CISM, CISA Senior Vice President CyberGuard Corporation

With more than 20 years of evolution behind them, killer worms are poised to wreak havoc today on the public Internet.

Historical Perspective

The origin of computer worms can be traced as far back as 1979, when Xerox engineers first built and experimented with worms to do useful work in a distributed environment. Some of these experimental “worker” worms did escape during testing, but they were not malicious and no harm was reported.

The Christma Exec Worm

Christma Exec is among the first and most notable worms to qualify as a network exploit. Many believed this network-based worm was written as an innocent prank that went wrong because the author did not understand that it would spread so far and so fast. The worm was written in Rexx script language and first launched from Germany on December 9, 1987, well before the Internet was officially born. The worm originated on the German EARN network, propagated through connected Bitnet sites and eventually worked its way through Bitnet connections to wreak havoc on the IBM Internal File Transfer Network (otherwise known as VNET) in the United States. The flood of traffic Christma Exec created left parts of the IBM network unusable on December 10 and 11 until it was finally brought under control a few days later.

Christma Exec required the user to execute a script attached to an e-mail message that appeared to come from an e-mail address that the recipient knew and trusted. While it looked innocent enough, executing the script to display the Christmas greeting would cause the program to proliferate by sending a copy of itself to every single person in the victim's address book and address history file. When it finished sending itself to all addressees, it erased itself from the original victim's computer. When new recipients received and activated their copies of Christma Exec, the scenario would repeat, flooding the network with Christma Exec messages.

Little data exists to establish exactly how many servers were affected by the Christma Exec worm; however, it has been clearly established that the worm generated enough traffic to render parts of the IBM VNET network unusable for several days. IBM prepared a comprehensive report on the Christma Exec worm that can be found at http://www.computer.org/security/v1n5/j5cap.htm.

The Morris Worm

The first Internet-based destructive on record was called the Morris worm, and it was unleashed on the Internet by Robert Tappan Morris Jr. on November 2, 1988. Intended to simply proliferate without causing any damage, a bug in Robert’s software allowed the worm to re-infect individual servers multiple times. Hence, each additional instance of the worm on the server caused additional CPU resources to be consumed, slowing the server and effectively causing the world’s first Internet denial of service (DoS) attack. At the time of the attack, there were approximately 56,000 hosts (http://www.isc.org/ds/host- count-history.html) connected to the Internet. The Morris worm infected approximately 6,000 servers. The United States General Accounting Office (GAO) estimated that Morris caused between $10 million and $100 million in damages.

The Morris worm was a “Multi Mode” worm that attacked DEC VAX servers running the Sun and BSD operating systems. It exploited weak passwords along with known vulnerabilities in the send mail application and Unix utilities fingerd and rsh/rexec.

Shortly after—some say as a result of—the Morris worm incident, the CERT Coordination Center was formed to act as a repository and clearinghouse for Internet security incident and vulnerability data.

A comprehensive analysis of the Morris worm was written by Eugene H. Spafford of the Department of Computer Sciences at Purdue University. The complete report can be found at http://protovision.textfiles.com/100/tr823.txt.

Melissa Worm

First appearing in March 1999, Melissa was among the most infamous worms to cause a serious impact with e-mail systems across the public Internet. The original version of Melissa written by David Smith used a Macro Virus to spread to the first 50 addresses in the user’s Outlook address book. It did little more than clog networks with e-mails. There were, however, some malicious twists. If Internet access or Outlook were not available, it would copy itself to other word documents and attempt to e-mail those documents, revealing potentially confidential information. Further, it would modify existing documents, inserting quotes from the Simpson’s television show.

The cost of damages from the Melissa worm was estimated at $1.1 billion. Several Melissa variants were found in the wild, each new version becoming progressively more malicious.

After e-mailing itself to four addresses in the user’s Outlook address book, the Melissa.U variant would delete several critical files from the computer.

• C:\Command.com • C:\Io.sys • C:\Ntdetect.com • C:\Suhdlog.dat • D:\Command.com • D:\Io.sys • D:\Suhdlog.dat

The Melissa.V variant would e-mail itself to 40 addresses in the user’s Outlook address book, then delete all files from the root of the F, H, I, L-Q, S, X and Z drives.

Damage from the Melissa worm was estimated at $1.1 billion.

I LOVE YOU

In May 2000, the I Love You worm appeared on the Internet—first in Asia, then spreading quickly across the globe. Instead of sending a copy of the worm to the first 50 or 100 addresses in the host’s Outlook address book, I Love You used every single address in the host’s address book, spreading faster and further than any previous e-mail worm.

Industry estimates indicated that the I Love You worm infected more than half of all business networks in the U.S. and nearly one million e-mail servers in Europe. Damage estimates from the I Love You worm went as high as $8.75 billion.

The I Love You worm was extremely malicious, causing damage in various ways.

• The I Love You worm would write over files on the compromised host’s hard disk, targeting files with *.JPG, *.GIF, and *.WAV, and *.CSS extensions. • I Love You also marked all *.mp3 files as hidden so the user also mistakenly believed mp3 files had also been deleted. • By overwriting files instead of simply deleting them, the I Love You worm made it virtually impossible to recover original files. • Later variations of the I Love You worm followed—some even deleted—*.COM or *.EXE and .INI files, preventing the computer from starting again after it was rebooted. • Lastly the I Love You worm downloaded and installed a Trojan program from a server on the Internet that would steal usernames and passwords from the host and e-mail them to an address in the Philippines, [email protected] — a trail that quickly lead to the author’s capture.

Only five days after the original I Love You worm was first seen, nearly 30 other variants were identified. Clearly, worms were evolving – spreading faster and further and becoming more malicious in nature. The I Love You Worm caused more damage, impacted more servers and caused more financial losses than any worm to that point.

Code Red

In July 2001, appeared, taking advantage of a flaw in Microsoft’s IIS Web server to spread across the Internet. Once it found a vulnerable host, Code Red would

Deface the host’s website, displaying “HELLO! Welcome to http://www.worm.com!/ Hacked By Chinese!"

Copy command.com and rename it root.exe in the Web server’s publically accessible scripts directory providing complete command line control to anyone who knew the Web server had been compromised.

Code Red would then use the compromised Web server to explore the Internet and identify other vulnerable IIS servers.

About 25 days after installation, Code Red was designed to launch a denial of service attack against the White House’s IP address.

Code Red spread at a speed that overwhelmed network administrators as more than 359,000 servers became compromised in just over 14 hours. At its peak, more than 2,000 servers were being compromised every single minute. Estimates are that Code Red compromised more than 750,000 servers.

Reports in the media were sensational and changing with regard to the real threat posed by Code Red. Initially, the “Hacked by Chinese” website defacements prompted reports that Code Red was an attack by Chinese against American websites. Later, it was reported that the Web site defacements were a diversion and the real purpose was the denial of service attack that was to be launched against the White House website. A few simple changes to Internet routers thwarted the denial of service attack.

Code Red damage estimates were $2.6 billion—considerably less than damages caused by the I Love You worm which had a higher number of available targets.

Code Red had an interesting twist. While automatically exploring random addresses on the Internet for new servers to compromise, an infected server would leave behind a tell tale signature in a Web server’s access logs. Using those Web server logs, anyone who knew what to look for could quickly compile a list of servers compromised by Code Red. Armed with this list, a malicious person could use the command.com that was renamed root.exe and assume complete command line control of the Web server. In the worst case, the individual could install a root kit on the Web serve, clean up all traces of Code Red and use the server again for future exploits.

NIMDA

The worm—which is “admin” spelled backwards—appeared in September 2001 and had several unique features.

When received as an e-mail attachment, the user did not have to open the attachment to execute the program. It would automatically execute when simply viewed in Outlook’s preview panel.

NIMDA contained its own e-mail program for sending e-mail, so it did not have to depend on the host having an operating mail server to further propagate the NIMDA worm. If the compromised host had an operational e-mail program, NIMDA would still use its own mail server so as not to leave evidence in the host’s mail program that it was e-mailing copies of NIMDA to addresses in the host’s address book.

NIMDA included an e-mail harvesting program that searched hosts for e-mail addresses to use in the “from” field, making it more difficult to track down the origination or source of the e-mail which contained the NIMDA worm code.

NIMDA provided a second method of propagation. If the compromised host was running a Web server, NIMDA would modify Web pages on the server so that anyone who opened a modified Web page using a Microsoft Web browser would also automatically download the NIMDA worm.

A third method of propagation added a copy of NIMDA to existing .exe files. If the .exe file were transferred to another machine and later executed, it would automatically install a copy of NIMDA.

There was yet a fourth method of propagation. Like Code Red it searched random IP addresses for Microsoft IIS Web servers taking advantage of a known vulnerability to install the NIMDA worm.

Some may not have considered NIMDA as malicious in nature as previous worms, but its advanced features and four different means of propagation allowed it to spread faster than any preceding worm.

NIMDA was clear evidence that worms were evolving and becoming smarter and more nimble, but damage estimates of $645 million were lower than for Code Red.

BadTrans.B

In November 2001, the BadTrans.B worm appered. BadTrans.B offered more advanced technical features as well as new social engineering features.

BadTrans.B would install a Trojan program that would steal user names and passwords and then e-mail them to a special e-mail address contained within the Trojan.

BadTrans.B would search though the host’s Outlook e-mail inbox for e-mails that had not been opened. It would then reply to that e-mail with an attachment containing the BadTrans.B worm. Like its NIMDA predecessor, the BadTrans.B worm only needed to be viewed in the Outlook preview panel to be automatically installed.

BadTrans.B would add an underscore character at the beginning of the “from” name in the e-mail. The recipient would not notice the character in the familiar e-mail address and, if the compromised host tried to reply to the original e-mail with the BadTrans.B Worm attachment, the bad address kept it from reaching the original sender.

BadTrans.B was more “socially innovative” in comparison to previous worms. In sending a reply e-mail to unanswered e-mail in the host’s Outlook e-mail box, it was able to compromise savvy users. BadTrans.B lacked the propagation capabilities of previous worms such as NIMDA and infected a small fraction of the number of NIMDA compromised hosts. BadTrans.B damage estimates were approximately $210 million.

Klez Worm

The Klez worm appeared in October 2001. A hybrid worm, Klex also installed a copy of the ElKern virus on the compromised host. Like many of its predecessors, Klez took advantage of a bug in Outlook that allowed it to be installed simply by viewing the e-mail in the preview panel.

While propagating only by e-mail, Klez incorporated a rather unique and “socially innovative” approach, selecting one e-mail address from the host’s address book to use as the “from” address, then sending the worm to all the other addresses. In this manner, the e-mail often appeared to have been sent from a co-worker or someone the addressee actually knew.

In a later variant, the e-mail not only appeared to come from a friend or co-worker, but also to contain a Klez “immunity tool” as an attachment. Recipients were instructed to disable their antivirus software prior to running the tool. By following those instructions, when recipients double-clicked on the program, they were actually installing Klez’ malicious payload – the “ElKern virus.”

The Klez worm is one of the longest living worms ever to trouble the Internet. First seen in October 2001, it dominated 2002 as the most prevalent worm on the Internet. In late 2003, reports continue to cite the Klez “H” variant as a threat. While it is difficult to determine the total dollar amount of damages attributable to Klez and its variants, estimates range as high as $9 billion.

SQL Slammer

The SQL Slammer worm struck January 25, 2003, and entire sections of the Internet began to go down almost immediately.

• Within minutes Level 3's transcontinental chain of routers began to fail – overwhelmed with traffic. • Three hundred thousand cable modems in Portugal went dark. • South Korea fell right off the map and 27 million people were without cell phone or Internet service. • Unconfirmed reports said that five of the Internet's 13 root-name servers – all hardened systems – succumbed to the storm of packets. • Corporate e-mail systems jammed. • Web sites stopped responding. • Emergency 911 dispatchers in suburban Seattle resorted to paper. • Unable to process tickets, Continental Airlines canceled flights from its Newark hub. Most of the company’s 75,000 servers were affected within the first 10 minutes.

SQL Slammer took advantage of a known vulnerability in Microsoft SQL Server software, a limit to the actual number of servers compromised.

Using the now-familiar random address scanning technique to search for vulnerable hosts, SQL Slammer included elements that enabled it to propagate rapidly.

By using the inherently faster UDP communications protocol in lieu of TCP as a communications protocol, SQL Slammer eliminated the overhead of a connection- oriented protocol.

At only 367 bytes, SQL Slammer was one of the smallest worms on record.

A variation of SQL Slammer was reported to have been responsible for a disruption at a nuclear power plant in Ohio on June 20, 2003. Some reports suggest that a SQL Slammer variant may have played a role in the August 14, 2003, power failure that blacked out cities from Ohio to New York. Damage estimates for SQL Slammer were $1.2 billion.

Looking toward the future

While worms have evolved from both the technological and social engineering perspectives, there has been little change in the basic method of propagation – the initial scanning phase in which the worm looks for the vulnerable hosts. Once a worm reaches an installation base of 10,000 or more hosts, propagation becomes exponentially faster. To date in virtually all cases, worms have been slow to find the initial 10,000 or so exploitable hosts. During this scanning phase, worms produce quite a bit of “noise” as they scan random address ranges across the Internet looking for targets. This causes firewalls and IDS systems to generate alerts and serves as an early warning that a new worm is winding its malicious way across the Internet.

All of this is about to change. Future worms will take advantage of new fast scanning routines that will dramatically accelerate the initial propagation phase and even use pre- scanning data to virtually eliminate that first slow phase of scanning for vulnerable hosts.

This new strain of worms is referred to as a “fast scanning” worm, sometimes called a Warhol worm. An excellent paper that discusses the Warhol worm concept, written by Nicholas C. Weaver at the University of Berkley in 2001: “A Warhol Worm: An Internet plague in 15 minutes!” (http://www.cs.berkeley.edu/~nweaver/warhol.old.html), is recommended reading for all network administrators.

Even with 14 hours of advance warning, networks and systems were completely overwhelmed with the speed of Code Red. There was no chance to defend against SQL Slammer as it circled the globe in about an hour. What will the devastation be when a worm eliminates the initial scanning phase of hunting for 10,000 vulnerable hosts? Estimates average that it would take about six minutes for this new type of worm to completely saturate the Internet. It is no longer a matter of how this can be accomplished. It is simply a matter of when. The technology is here now to facilitate this new worm. All that is lacking is the attacker with the will and malicious intent.

Here are the top 12 things you can do to harden your enterprise against Worm attacks.

1. Patch all of your systems (both servers and desktops) and remove or disable all un- necessary services. 2. Review your security policy and re-evaluate the business need for all services you allow access to on the Internet. Eliminate all but those services that are essential to the operating your business. 3. Use application proxies with complete packet inspection on all traffic inbound to your publicly accessible servers. 4. Isolate all publicly accessible servers, each on their own physical network segment. Servers should be grouped by trust, not by convenience. 5. Create granular access controls that prevent your publicly accessible servers from originating connections either to the public Internet or to your intranet. 6. Create access controls to limit outbound access for internal users to only services that are necessary. 7. Strip all potentially malicious e-mail attachments within your SMTP application proxy firewall. (See addendum 1.) 8. Use an antivirus server on an isolated network segment to eradicate virus and worms from permitted e-mail attachments before allowing e-mail through your firewall. 9. Deploy antivirus software on all desktops throughout your business. 10. Use ingress anti-spoofing filters on your border router to keep the spoofed packets that are common to worm propagation from entering your network. (Refer to http://www.zvon.org/tmRFC/RFC2827/Output/chapter3.html for a good explanation of ingress filtering.) 11. Use egress anti-spoofing on your border router to prevent a worm or potentially malicious internal user from launching spoofed IP address-related attacks across the Internet from inside your network. (Refer to http://www.sans.org/y2k/egress.htm for a good explanation of egress filtering.) 12. Create an incident response plan that includes an out-of-band communications method to your bandwidth provider so you can head off attacks and shun IP addresses on the provider’s border routers, minimizing any impact within your pipe.

Addendum 1

File extensions (in alphabetical order) that should be considered:

• ad - Microsoft Access Project Extension • ade - Microsoft Access Project Extension • adp - Microsoft Access Project • asp - Active Server Page • bas - Microsoft Visual Basic Class Module • bat - Batch File • chm - Compiled HTML Help File • cmd - NT Command Script • com - Microsoft MS-DOS Program • cpl - Control Panel Extension • crt - Security Certificate • exe - Program • hlp - Help File • hta - HTML Program • inf - Setup Information • ins - Internet Naming Service • isp - Internet Communication Settings • js - JScript File • jse - Jscript Encoded Script File • lnk - Shortcut • mdb - Microsoft Access Program • mde - Microsoft Access MDE Database • msc - Microsoft Common Console Document • msi - Microsoft Windows Installer Package • msp - Microsoft Windows Installer Patch • mst - Microsoft Visual Test Source Files • pcd - Photo CD image, Microsoft Visual Compiled Script • pif - Shortcut to MS-DOS program • reg - Registration Entries • scr - Screen Saver • sct - Windows Script Component • shb - Shell Scrap Object • shs - Shell Scrap Object • url - Internet Ohortcut • vb - VBScript File • vbe - VBScript Encoded Script File • vbs - VBScript File • vsd - Microsoft Visio File Type • vss - Microsoft Visio File Type • vst - Microsoft Visio File Type • vsw - Microsoft Visio File Type • wsc - Windows Script Component • wsf - Windows Script File • wsh - Windows Script Host Settings File

References:

This paper is the result of the review of numerous publicly available posted works found on the public Internet and read over the course of my career. The author has tried to list all applicable references and has not intentionally slighted anyone who may inadvertently have not been referenced and/or cited.

Merry Christma: An Early Network Worm – Peter G. Capek, David M. Chess, and Steve R. White, IBM T.J. Watson Research Center Alan Fedeli, IBM Business Partner for Managed Security Services – IEEE, 2003

Simulating And Optimizing Worm Propagation – Tom Voght, 2003

Analysis of the Klez Worm – Daniel Biado, Trend Micro, 2002

Computers Under Attack – Addison-Wesley, 1990

A Report on the Internet Worm – Bob Page, University of Massachusetts Lowell, 1988

The Internet Worm Incident – Eugene H. Spafford, Purdue University, 1988

Examples of Malicious Computer Programs – Ronald B. Standler, 2002

CERT® Advisory CA-2001-19 "Code Red" Worm – CERT/CC 2002

Melissa Worm – PestPatrol’s Pest Research Center, 2003

Trend Micro Virus Encyclopedia 2003

Blaster Worm Linked to Severity of Blackout – Dan Verton, ComputerWorld, 2003

Egress Filtering v 0.2 – SANS, 2000

Restricting forged traffic – ZVON RFC Repository 2000

CyberGuard Corporate Headquarters 2000 West Commercial Boulevard Suite 200 Fort Lauderdale, Florida 33309 Phone: 954.958.3878 Fax: 954.958.3901 E-mail: [email protected]

CyberGuard Europe Limited Asmec Centre, Eagle House The Ring, Bracknell Berkshire, RG12, 1HB United Kingdom Phone: +44 (0) 1344 382550 Fax: +44 (0) 1344 382551 E-mail: [email protected] www.cyberguard.com

Copyright© 2003 by CyberGuard Corporation. All rights reserved. This publication is intended for use with CyberGuard Corporation products by CyberGuard's personnel, customers and end users of CyberGuard's products. It may not be reproduced in any form without the written permission of CyberGuard Corporation.

CyberGuard® is a registered trademark of CyberGuard Corporation. UnixWare® is a registered trademark of Santa Cruz Operations, Inc. All other trademarks are the property of their respective owners.