Note: This is an historic document. We are no longer maintaining the content, but it may have value for research purposes. Pages linked to from the document may no longer be available.

The Melissa Virus: Inoculating Our Information Technology from Emerging Threats

Testimony of Richard Pethia, Director, Survivable Systems Initiative and CERT^® Coordination Center
Software Engineering Institute
Carnegie Mellon University

Before the Subcommittee on Technology, Committee on Science, U.S. House of Representatives

April 15, 1999

Contents:

• Introduction
• Background
• Melissa Macro Virus
• How the Melissa Virus Works
• Impact of the Melissa Virus
• Solutions
• Overview of the CERT/CC Response to the Melissa Virus
• Why is Melissa so serious?
• Possible Solutions
• Conclusion
• Appendix A - CERT Advisory CA-99-04 Melissa Macro Virus
• Appendix B - CERT/CC Melissa FAQ

Introduction

Madam Chairman and members of the Subcommittee on Technology of the House of Representatives Committee on Science:

My name is Richard Pethia. I manage the Survivable Systems Initiative and the CERT® Coordination Center at Carnegie Mellon University’s Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania.

Thank you for the opportunity to testify on the role of the CERT/CC in combating the Melissa virus. Today I will give some background on the CERT/CC, describe our experience with the Melissa virus, and outline steps that I believe must be taken to reduce the impact of future security incidents.

Background

The CERT® Coordination Center (CERT/CC) is located at the Software Engineering Institute (SEI), a federally funded research and development center at Carnegie Mellon University in Pittsburgh, Pennsylvania. Following the Internet Worm incident, which brought 10 percent of Internet systems to a halt in November 1988, the Defense Advanced Research Projects Agency (DARPA) charged the SEI with setting up a center to coordinate communication among experts during security emergencies and to help prevent future incidents. Since then, the CERT/CC has handled 15,000 computer network security incidents and analyzed more than 1,100 vulnerabilities in network-related products. The incident handling practices of the CERT/CC have been adopted by nearly 80 incident response teams around the world.

Today, the Defense Information Systems Agency (DISA) and the Federal Bureau of Investigation (FBI) sponsor the CERT/CC’s work. The CERT/CC provides assistance to computer system administrators in the Internet community who report security problems. When a security breach occurs, CERT/CC staff members help the administrators of the affected sites to identify and correct the vulnerabilities that allow the incident to occur. The CERT/CC staff also coordinates the response with other sites affected by the same incident. When a site specifically requests, CERT/CC staff members facilitate communication with law enforcement agencies. The scale of emerging networks and the diversity of user communities make it impractical for a single organization to provide universal support for addressing computer security issues. Therefore, the CERT/CC staff regularly works with sites to help them form incident response teams and provides guidance to newly formed teams. The CERT/CC is also responsible for the day-to-day operations of the FedCIRC (Federal Computer Incident Response Capability) Operations Center, an organization that provides incident response and other security-related services to Federal civilian agencies. The General Services Administration (GSA) manages FedCIRC.

The CERT/CC also handles reports of vulnerabilities in commercial products. When we receive a vulnerability report, our vulnerability experts analyze the potential vulnerability and work with technology producers to inform them of security deficiencies in their products and to facilitate and track their response to these problems. Another source of vulnerability information comes from incident analysis. Repeated incidents of the same type often point to the existence of a vulnerability and, often, the existence of public information or automated tools for exploiting the vulnerability. To achieve long-term benefit from vulnerability analysis, we have begun to identify the underlying software engineering and system administration practices that lead to vulnerabilities and, conversely, practices that prevent vulnerabilities.

Our ongoing computer security incident response activities help the Internet community to deal with its immediate problems while allowing us to understand the scope and nature of the problems and of the community's needs. Our understanding of current security problems and potential solutions comes from first-hand experience with compromised sites on the Internet and subsequent analysis of security incidents, intrusion techniques, configuration problems, and software vulnerabilities.

As a result of our incident and vulnerability analysis work, the Networked Systems Survivability (NSS) Program and its CERT/CC have a broad view of incident and vulnerability trends and characteristics. We communicate this information back to the community through online reports, presentations at conferences and workshops, and training courses. In addition critical information about specific threats goes out to the Internet community through security alerts such as CERT advisories, incident notes, vulnerability notes, and vendor-initiated bulletins. The government receives early warnings through "special communications" to the Department of Defense (through its incident response teams), Federal civil agencies (through FedCIRC), and the FBI. This work is possible because the CERT/CC has become a major reporting center for incidents and vulnerabilities because staff members have an established reputation for discretion and objectivity. As a result of the community's trust, we receive thousands of reports every year.

In addition to incident response and vulnerability handling, the NSS Program focuses on security improvement and network survivability.

In the area of security improvement we are defining security improvement practices to provide concrete, practical guidance that will help organizations improve the security of their networked computer systems. These practices are being published as security improvement modules and focus on best practices that address important problems in network security. We have published the following modules: Security for a Public Web Site, Security for Information Technology Service Contracts, Preparing to Detect Signs of Intrusion, Detecting Signs of Intrusion, Responding to Intrusions, Securing Desktop Workstations, and Securing Network Servers.

NSS staff members are also developing a comprehensive, repeatable technique for identifying vulnerabilities in networked systems through self-evaluation. The information security self-evaluation takes into consideration policy, management, administration, and other organizational issues, as well as technology, to provide a comprehensive view of the information security state of an organization. We are also developing an adaptive security management approach to the operation of networked information technologies. This approach allows an organization to maintain an acceptable level of security by quickly adapting to changes in the internal and external environments. The approach is based on a model, currently under development, that describes the categories of changes, the risks introduced by those changes, and actions that can mitigate those risks.

In the area of network survivability, we are concentrating on the technical basis for identifying and preventing security flaws and for preserving essential services in the event of intrusions, accidents, or failures. This work draws on the incident data collected by the CERT/CC. We are developing a survivable network analysis method, which uses a structured architectural specification of an existing or proposed network application to determine the most likely points in the architecture where accidents and/or intrusions could cause the mission of the application to fail. This method leverages SEI expertise in risk and architectural analysis, network intrusion expertise, and vulnerability analysis. It is applied to a selected system by a SEI assessment team working with system architects and stakeholders. Survivable network analysis identifies essential services and assets of the application that must survive intrusion, evaluates its ability to withstand attack, and recommends architecture strategies to mitigate vulnerabilities that are uncovered. The method is designed to scale to highly distributed systems in unbounded domains such as the Internet, for which traditional security techniques are inadequate.

Along with the analysis method, NSS staff is building a simulator to explore survivability characteristics of large networked applications in an environment of limited administrative control. This will enhance the analysis of national infrastructures dependent on information systems that are interconnected and interdependent. This simulator will be used as part of a more advanced analysis technique for networked applications and network protocols. The simulator will help us understand how cascade effects and other complex failures arise from large networked domains where administrative control is localized but there is a dependence on network elements beyond this administrative control.

We transition best incident response and security practices through courses offered by the SEI and by the SEI’s transition partners. These courses include Managing Computer Security Incident Response Teams, Information Security for Managers, Introduction to Information Security for System and Network Administrators, Information Security for System and Network Administrators, Computer Security Incident Handling for Technical Staff (Introductory), and Computer Security Incident Handling Workshop for Technical Staff (Advanced).

Melissa Macro Virus

It was 10 years ago last October that a young college student wrote a "worm program" that caused a geometric explosion of copies of itself to be sent to computers all around the Internet. This program—the first Internet security incident to make headline news—was the wake-up call for network security. In response, the CERT/CC was established at the SEI.

The Melissa macro virus is one of the thousands of problems that have been reported to the CERT/CC each year since then. Macro viruses for Microsoft products appeared as early as 1995, with over 1000 variants for Word and other products by 1998. Melissa is different from other macro viruses because of the speed at which it spread. The CERT/CC received its first confirmed reports of Melissa early in the afternoon of Friday, March 26, 1999. Over the next four days, the CERT/CC received a continuous stream of reports from United States government organizations, educational institutions, and corporations including telecommunications providers, energy utilities, manufacturing companies, and computer vendors. In addition, calls came in from many countries including Canada, the Netherlands, New Zealand, Qatar, Singapore, Sweden, and the United Kingdom. By Tuesday, March 30, the CERT/CC had reports that it had reached more than 233 organizations and infected 81,285 computers. Some sites had to take their mail systems off-line. One site reported receiving 32,000 copies of mail messages containing Melissa on its systems within 45 minutes.

How the Melissa Virus Works

The Melissa macro virus propagates in the form of an email message containing an infected Word document as an attachment. When a user opens the infected .doc file with Microsoft Word97 or Word2000, the macro virus is immediately executed if macros are enabled. Upon execution, the virus first lowers the macro security settings to permit all macros to run when documents are opened in the future. Therefore, the user will not be notified when the virus is executed in the future. The virus proceeds to propagate itself by sending an infected email message to the first 50 entries in every Microsoft Outlook MAPI address book readable by the user executing the macro. If any of these email addresses are mailing lists, the message goes to everyone on the mailing lists.

The macro then infects the Normal.dot template file. By default, all Word documents use the Normal.dot template; thus, any newly created Word document becomes infected. Because unpatched versions of Word97 may "trust" macros in templates, the virus may execute without warning. If users open an infected document with macros disabled and look at the list of macros in this document, neither Word97 nor Word2000 list the macro. Users have to use the Visual Basic editor to see the code.

Users who open an infected document in Word97 or Word2000 with macros enabled will infect the Normal.dot template, causing any documents which later reference this template to be infected with this macro virus. If another user opens the infected document, or uses the Normal.dot template, the document, including the macro virus, will propagate. This could cause the user's document to be propagated instead of the original document, and thereby unknowingly leak sensitive information. A more detailed description of how the Virus works is included as Appendix A.

Impact of the Melissa Virus

Solutions

The CERT/CC also recommended that users

• disable macros by default
• be cautious when operating any product when macros are enabled
• set Word to prompt the user before making any changes to the normal.dot file
• keep their antivirus software up to date
• be wary of unsolicited documents or executable programs received in electronic mail and of software that comes from untrusted sources
• notify anyone who sends them a virus; the sender might not realize they have it

Overview of the CERT/CC Response to the Melissa Virus

The CERT/CC staff received the first report of the Melissa virus on Friday afternoon, March 26, 1999. It soon became evident that the virus had the potential to cause severe problems across the Internet. Both government and industry sites contacted the CERT/CC to report problems. In response, the CERT/CC contacted many other government sites, including the House of Representatives, and also provided information to the National Coordination Center for Telecommunications, the National Infrastructure Protection Center, and the Critical Infrastructure Assurance Office. Eight hours after receiving the first report of Melissa, the CERT/CC gave early warning, through the first of five "special communications" to DoD incident response teams, the FedCIRC Management Office, the FBI, and other sensitive sites.

Staff members worked through the night to analyze the virus, speak with other technical experts, and work with vendors on solutions, including Microsoft, Computer Associates, McAfee/Network Associates, Sophos, Symantec, and Trend Micro. By Saturday morning, the CERT/CC had already received reports from about 50 organizations that the virus had infected their sites. Many reported that their mail servers had been overwhelmed by the mail generated by the virus and others reported that they had taken their mail servers out of service to prevent the spread of the virus. On Saturday morning, the CERT/CC issued an advisory to its 70,000-address electronic mailing list and published it on its Web site at http://www.cert.org and the FedCIRC Web site http://www.fedcirc.gov. Based on the analysis work that occurred through the night and the information received from the vendors, the advisory provided accurate, detailed information about the virus and recommended protective measures. The advisory was downloaded 30,000 times during the first seven hours alone; demand for the advisory was so great that the CERT/CC had to rebuild its Web server (both hardware and software) to handle the expected load.

Concerned that the virus could cause major problems when the work week began on Monday morning, the CERT/CC issued a press release on Saturday morning, and the release was quickly picked up by the major wire services, including the Associated Press, Reuters, and United Press International. On Sunday, the ABC and NBC television networks came to Pittsburgh to tape interviews with the manager of the CERT/CC operations group. The interviews aired on the NBC Today Show and ABC Good Morning America on Monday. CERT/CC staff members also provided on-air interviews for the CNN, CNBC, and Fox News networks. Between Friday and Tuesday, the CERT/CC also worked with print media to bring the story about the Melissa virus to the public’s attention. Articles about the Melissa virus, with interviews with CERT/CC personnel, appeared in publications throughout the world, including USA Today, The New York Times, The Wall Street Journal, The Washington Post, The Los Angeles Times, and many others.

At the same time, CERT/CC staff handled email inquires and answered its hotline, which began ringing around the clock over the weekend. It added new information from vendors to the advisory and sent three more special communications to DoD, the FedCIRC Management Office, Federal civil agencies, and the FBI.

The advisory was downloaded 188,000 times between midnight and 7:00 PM on Monday, and 160,000 additional times on Tuesday. By Monday evening, 233 organizations had reported infections to the CERT/CC, affecting 81,285 computers. However, as a result of defensive measures taken by system administrators across the Internet, the proliferation of the virus began to subside. On Tuesday, only about 50 additional sites reported infections to the CERT/CC. The CERT/CC began to hear of variants of the Melissa virus on Tuesday.

On Tuesday, the CERT/CC sent the fifth special communication, noting the reduction in reports of Melissa and providing updated information about macro viruses. On Wednesday, we published a Melissa FAQ (frequently asked questions – see Appendix B) to address users concerns. As troublesome as the Melissa virus was, the CERT/CC helped to avert much more severe consequences through its technical and communication efforts (see Appendix C for a visual timeline).

Why is Melissa so serious?

The Melissa virus represents a new level of sophistication in the progression of computer viruses. Melissa’s impact is so great because it exploits, in a very simple and clever way, the power that has been built into the flexible and expressive technologies in use on the Internet today. It also exploits the high level of connectivity brought about by the Internet and the informal rules people commonly use when handling electronic mail. Melissa’s notable characteristics include:

• The speed at which it spread - Acting like an automatic electronic chain letter, Melissa spread through the Internet much faster than any other virus. Because Melissa used address books of valid electronic mail addresses to spread through the Internet, rather than trying other techniques such as generating random addresses, Melissa was extremely efficient.

• Possible transmission of sensitive information – If undetected, Melissa infects the template used to create documents. Under certain conditions, this could cause an organization to unwittingly send its internal documents to people outside the organization.

• Passes people’s reasonableness test – Since many people are unaware of the threat of macro viruses, they see no reason not to "read" any mail that is sent to them. For those who are aware, Melissa-generated mail was still read by many because it looked like it came from someone they knew. In this case, the old caution of "know who you interact with" was not enough. Melissa effectively masqueraded as someone the mail recipient knew and was still able to cause infection.

• Big impact from little work – The Melissa virus itself contains only 105 lines of code. Melissa achieved its impact because of the power of the software that it exploited: the macro-processor and electronic mail system. It demonstrates some of the consequences possible of using powerful software in a networked environment without also using adequate controls. While Melissa had a large impact, it could have been much worse. Melissa’s "payload" focused on propagating documents through the Internet, it could have just as easily done more damaging things such as destroying or altering the contents of data in files accessible to the mail recipient or sending all of the file data to some external location.

Possible Solutions

For a variety of reasons, the damage done by Melissa was limited. The virus carried its own source code making it relatively easy to understand. Vendors of anti-virus products, and other products such as electronic mail packages, were able to upgrade their products or create special filters that "caught" Melissa quickly. The incident response community (the CERT/CC, the FedCIRC, other incident response teams, and the FBI’s NIPC) effectively shared information with each other and with their constituents. The news media spread the story widely and provided accurate information on how to identify and eradicate the virus. Armed with good information, information technology managers and others at individual sites took steps to protect themselves and eradicate the virus if they were infected. All in all, the problem was quickly contained and the damage minimized.

Melissa, however, signals a new era for viruses. Future mutations, or entire new strains, could easily be much harder to detect, spread even more quickly, and cause significantly more damage. Even worse, network attackers focused on doing damage to some critical infrastructure could launch multiple variants of Melissa-like viruses as a diversion to disguise their real attack. Melissa demonstrates that these scenarios are both possible and likely.

Successfully combating these new threats will require improvements to existing capabilities as well as fundamental changes to the way technology is developed, packaged, and used.

• Enhanced incident response capabilities – The incident response community handled Melissa well, but was strained to capacity in the process. Had some other broad-based attack been launched at the Internet at the same time, the response community could easily have fragmented, dividing its attention across the problems thereby slowing progress on each. In addition, system operators could easily be confused as they tried to understand if they were dealing with one problem with multiple symptoms or with multiple, simultaneous problems. New forms of communications must be developed that provide system operators with near real-time status on network security events with less person-to-person interaction than is required today. Incident response organizations must develop more effective ways to analyze security events and vulnerability data and to disseminate the results of the analysis to their constituents quickly. The mechanisms we have today work in units of hours and days, more time than we will have if faced with widespread, rapidly moving problems.

• Changes in technology development, packaging and use – In the long-term, it is unrealistic to expect that response organizations and system administrators, even with highly automated procedures, will be able to stay ahead of problems that move at Internet speed. While response teams will always be needed to handle new threats and unprecedented situations, technology producers must recognize that their products are being used in hostile environments and take steps to insure that their products are fit for use in those environments. Computers and software are becoming more powerful and more interconnected. At the same time, the average level of technical understanding of system users is declining. Powerful computers and software that anyone and everyone can use, without having a deep understanding of the technology, are now available. In this environment, a security approach based on "user-beware" is unacceptable. The systems are too complex for this approach to work.

The long-term solutions required are a combination of the following:

• Virus-resistant/proof software – There is nothing intrinsic about digital computers or software that makes them vulnerable to virus attack or infestation. Viruses propagate and infect systems because of design choices that have been made by computer and software designers. Designs that allow the import of executable code, in one form or another, and allow the unconstrained execution of that code on the machine that received it, are the designs that are susceptible to viruses and their effects. Unconstrained execution allows code developers (e.g. macro-code developers) to take full advantage of a system’s capabilities, but does so with the side effect of making the system vulnerable to virus attack. To effectively control viruses in the long term, vendors must provide systems and software that constrain the execution of imported code, especially code that comes from unknown or not-trusted sources. Some techniques to do this have been known for decades. Others, such as "sandbox" techniques, have been more recently developed.

• Widespread use of strong authentication – Melissa was successful partly because it was able to masquerade as being from a person that the email recipient knew. Carefully implemented authentication technology, such as digital signatures, that is in widespread use would allow people to reject messages, documents and code from unknown sources. This would have an immediate impact of inhibiting the spread of viruses like Melissa. Strong cryptographic technology exists today to provide integrity and authentication, but it is not in widespread use. Widespread deployment will require secure key distribution infrastructures and research and development to produce these infrastructures should be accelerated.

• High-security default configurations – With the complexity of today’s products, properly configuring systems and networks to use the strongest security built into the products is difficult, even for people with strong technical skills and training. Small mistakes can leave systems vulnerable and put users at risk when connected to the Internet. Vendors can help reduce the impact of security problems by shipping products with configurations that enable security options rather than require the user to enable them. The user can lower these "default" configurations if desired, but should provide the best security possible unless the user takes explicit steps to reduce it.

Conclusion

Melissa represents a new form of virus that demonstrates how quickly an infection can spread across a network and hints at the kind of damage that could be done. Incident response organizations were able to limit Melissa’s damage by working effectively together to analyze the problem, synthesize solutions, and alert the community to the need to take corrective action. With possible future viruses, it may not be possible to act as quickly or effectively. Response organizations will always have a role to play in identifying new threats and dealing with unprecedented problems, but response methods will not be able to react at Internet speeds with complicated viruses or with multiple, simultaneous attacks of different types.

The long-term solutions to the problems represented by Melissa will require fundamental changes to the way technology is developed, packaged, and used. It is critical that system operators and product developers recognize that their systems and products are now operating in hostile environments. Operators must demand, and developers must produce, products that are fit for use in this environment. As new forms of attack are identified and understood, developers must change their designs to protect systems and networks from these kinds of attack.

Appendix A - CERT Advisory CA-99-04 Melissa Macro Virus

http://www.cert.org/advisories/CA-1999-04.html

Appendix B - CERT/CC Melissa FAQ

http://www.cert.org/tech_tips/Melissa_FAQ.html

Appendix C - CERT/CC Melissa Timeline

See the conditions for use, disclaimers, and copyright information.

This page was last updated on February 27, 2006.