(This was originally released as:SANS Flash Report - Melissa virus, March 28, 1999 Ė Last updated April 22, 1999, Editor Ė Stephen Northcutt)
Table of Contents:
Many sites were aware of Melissa on Friday, others over the weekend and of course, still others found Monday morning, March 28, to be a challenging day. By late Friday, an excellent description of the virus, including how to identify and contain it at the host level had been developed and published by the Computer Emergency Response Team at Carnegie Mellon. This document is available at: http://www.cert.org/advisories/CA-99-04-Melissa-Macro-Virus.html
Major anti-virus vendors have already released descriptions and anti-viral signatures. URLs for NAI and Symantec are listed below:
SANS applauds the work done by these organizations as well as other CIRT and FIRST teams whose rapid response helped keep this from becoming an even larger problem.
The focus of this document is on the lessons learned and also the bigger picture from the Melissa Macro virus. We will discuss the implications raised by the speed of infection, the impact from a user and also from a security managerís point of view of an infection and finally, some lessons learned on based on the experiences of userís who replied to the original Flash report.
1. What Melissa teaches us
The Internet was not truly prepared for Melissa, the number of affected sites is a warning that we had best learn. In this section we will consider some of the implications of this virus. In the conclusion we will also consider lessons learned, but these are based on the responses of readers from the first Flash report.
1.1 Infection Speed
According to NAIís web site, the virus was first discovered on an "alt.sex" newsgroup and spread rapidly. This serves as a warning how fast a virus with an unknown signature can spread. A modified, non-operative copy of the source code is included as an appendix to this document. If you search for the string "For y = 1 To DasMapName.AddressLists.Count", you can see how the virus replicated so rapidly by going through Microsoft Outlook address books and sending itself to the first 50 entries in each book. The most well published sections of the code are marked with comments that begin with ***.
Of course all the copies in the world are to no avail if they donít have anywhere to go. Though address books will have some errors, on the whole the point to active accounts which proved to be fruitful targets.
In the March 02 webcast, (http://www.sans.org/webarchives.htm) Stephen Northcutt discussed another MS Word Macro Virus, M97.Marker.a. This virus is an information gathering virus. Marker sends the Microsoft Office registration information of infected systems outside organizations via FTP. Northcuttís point was that this would allow a prospective attack to develop an infection map and by knowing who sends what to who, to target future rapid, focused attacks. Melissa wasnít targeted, but it certainly was rapid.
As a community we need to learn the lessons that Marker and Melissa teach, neither virus was destructive. They are both quite different, their primary similarity is that they are Macro viruses. However, they both serve as a warning shot, a heads up for security professionals to reconsider the risks of the macro virus threat vector. With a few adjustments in the source code either virus could have caused significant damage to organizations.
1.2 Collateral damage
The Melissa virus did no damage in the sense of deleting, or stealing files; only sites with desktop systems running Microsoftís Outlook email client were directly affected. However, even systems that did not spread the virus directly by email still had their Microsoft Word documents infected and continued to pass on the virus. Moreover, the cost of dealing with Melissa is in the millions of dollars. How did a virus that does no explicit damage wreak so much havoc? The financial losses are mostly in the area of lost productivity:
1.3 Need for defense in depth
Though Melissa was primarily spread by e-mail, passing an infected floppy disk worked just as well to move the virus to a new system, possibly even a new organization. This means that a single line of defense such as a content checking firewall might be easily circumvented. Sites discovered that the more defensive layers they had deployed, the more options they had. These defensive layers included virus checking at firewalls, servers and desktops, as well as email filters, quick hacks, and special cleaning programs.
Several creative, short term, "band-aid" solutions were developed to slow the spread of the virus. These quick hacks are reminiscent of the guy who saved his home from burning during the Malibou wild fires by standing on his roof spraying a garden hose. We can call him crazy, but his house stands unburned today. The primary electronic mail filter that was made available did its work by searching for Melissaís signature subject line, "Important Message From ". This worked and certainly helped get Melissa under control, though it certainly helped that variant Melissaís were not released early in the attack with different subject lines. Another band-aid that was tried by some organizations was to create fifty or more blank lines at the beginning of Outlook address books. It is easy to criticize band-aids as unsophisticated, but when you have to deal with a cut, a band-aid sure can be handy!
Several sites have reported they were unable to apply either the sendmail filter, or firewall based scanners because they didnít have the latest version of software. Monday morning, March 28 was too late to update software, the Internet feeds for the antivirus companies were saturated by clients all over the Internet trying to download updates to their virus signatures.
Virus scanning at the firewall, on servers and on the desktop systems as well as physical entry points for magnetic media are recommended for sites that want to avoid the kind of punch Melissa exhibited.
2. One siteís experience
One of the hidden costs of Melissa, is the impact on people. Here we present two stories from an infected site from two points of view, a user who received and opened the attachment and the security manager who led the cleanup at the site.
2.1 A Userís Story
"As I composed the last email of the day, a message hit the Inbox of my Microsoft Outlook email application. The subject line read: "Important Message From [Jane Doe]". I viewed the message, and the body read "Here is that document you asked for... don't show anyone else ;-)"
Attached was a Microsoft Word document titled "list1.doc".
"Although I hadn't requested any documents from [Jane Doe], I was expecting a couple of them from other people. It wasn't inconceivable to think that she had become involved, even though I didn't know who she was. I double-clicked on the Word document. A pop-up window appeared, warning me that a macro was contained in the document, and that macros can potentially be dangerous. I knew that... :-) So, I shut down the Word application, and checked the document with several of the virus detection packages that I had. Everything appeared clean."
"Since this was from someone in my organization, apparently a trusted source, I went ahead and opened the document with the macros enabled. In less than a second, a duplicate of the message had hit my mailbox, this time with my name attached. I hit the power-off button on my computer, but it was late. The payload had been delivered. My name was now attached to a file containing pornographic web sites, and an apparent username and password for each site. Moments later, duplicate messages from others who had made the same mistake began to appear."
"At this point I knew we, as an organization, were in trouble. This virus (or worm) was snowballing fast, too fast. I immediately called our information systems security manager, only to find that his phone was already busy. I left a voicemail detailing my appraisal of the situation, and my fear that this incident could get serious... very quickly. What I didn't know was that I was too late, it was already *very* serious."
This user now realizes that opening a file from a user he didnít know with an attachment pertaining to something he didnít know about and then allowing the macroís to execute was a serious error. Hopefully we can all learn from it!
2.2 A security managerís story
"As soon as we discovered the virus late Friday afternoon, we disconnected our servers (all SMTP relays and Exchange servers at our Internet connection) from the network until we could contain the infection. This happened at approximately 1800 hours Friday.
"System administrators for both corporate and departmental Exchange servers worked through Friday night and well into Saturday. Many returned Saturday and again on Sunday to complete the isolation and cleanup. They cleaned up the Exchange servers with updated anti-viral signatures as soon as they were available. The corporate servers and one departmental server were ready to come back on-line late Sunday. We left IMS (Internet Mail Service) disabled until we could contain (filter) email at the SMTP server.
"Our version of sendmail is one removed from the latest and filter updates provided by the author would not work on our version. We resorted to getting the word out for ALL users to update the AV signatures and refrain from sending Word docs until any with macros had been identified as coming from trusted sources. The administrator for the SMTP relay host downloaded a trial version of InterScan VirusWall from TrendMicro. For more info, see: http://www.antivirus.com/products/isvw/index.htm
"The clean-up picture would have been much bleaker if we hadn't had so many things in our favor:
3. Conclusion and Lessons Learned
Because Melissa exploited one of the most valuable benefits of the net -- the ability to share documents -- to propagate and to multiply itself, it affected more people and spread faster than earlier viruses. The silver lining in this cloud is that a relatively benign virus like Melissa was an effective way of gaining user and organizational awareness. Just about every organization on the Internet learned something about incident handling and how dependent on Internet services they are. The organizationís that learn from Melissa will be stronger and better prepared to deal with whatever comes next. After reviewing the comments from users and debriefing organizations, here are some of the primary lessons learned from the experience:
Appendix: Melissa Source Code
NOTE: Several errors have been introduced into this copy of the code as a safety measure so that this will not run as is. Also some sections have been removed. We hope this will not overly impact your opportunity to understand how the software works, but could not be responsible for furthering live version of Melissa. Text comments have been inserted at the "famous" locations preceded by three asterisks "***"
*** Begins by checking security, the environment, and whether already infected
Private Sub Document_Open()