Melissa was first reported on Friday afternoon. By the end of the weekend it had taken down mail servers at, among others, Microsoft, Lockheed Martin, and Lucent. By Monday morning, US-CERT was issuing emergency advisories and several major employers had told staff not to open Word attachments under any circumstance.
This is, on the available evidence, the worst single piece of email-borne malware in the history of the internet to date. It is also a clear escalation of the trajectory I wrote about in January with Happy99. I want to write down, while it is still fresh, what Melissa actually does and what the immediate lessons are.
How Melissa works
Melissa is a Word macro. It propagates as an attachment in an email, with subject Important Message From <Name> where the name is the previous victim's. The body of the email reads, plausibly enough: Here is that document you asked for ... don't show anyone else ;-). Attached is a Word document called LIST.DOC.
If the recipient opens the attachment in Microsoft Word with macros enabled — which is, for almost every Word installation in the field, the default — the macro executes.
The macro does three things:
First, it lowers the macro security setting to "never warn", so subsequent malicious macros will not prompt the user.
Second, it constructs an email containing a copy of the infected document, addressed to the first 50 entries in the user's Outlook address book, and sends them via MAPI. The user does not see this. Outlook silently sends the messages.
Third, the macro modifies Normal.dot, the default Word template, so that subsequent documents the user creates are also infected.
Fifty new infections per opening. Each of those produces fifty more. The math is exponential and the doubling time is hours, not days.
Why it killed mail servers
The propagation mechanism produces a sustained burst of outbound mail from each infected machine. A mid-sized company with five thousand employees, of whom even ten per cent open the attachment in the first morning, can produce 25,000 infected emails in an hour, each carrying a 40-kilobyte Word document.
This is significant traffic. More importantly, it is signature traffic — every message has the same shape, the same approximate size, and the same sequence of mail-server actions (RCPT, DATA, end-of-message). Naïve mail servers, configured to accept everything from internal sources, hit their limits — disk fill on queue directories, RAM exhaustion, connection-table overflows.
The outage was not, in most cases, the virus attacking the server. It was the server's own legitimate processing of the virus's outbound flood, which the server had no way to distinguish from a legitimate flood.
What I have done on my own infrastructure
The small mail relay I run for friends does not, fortunately, see Word documents pass through it in significant volume — most of my correspondents are technical and prefer text. But I have put in place, over the weekend, three new defensive measures:
Outbound rate limiting. No source IP on my network can send more than 60 messages in a five-minute window without being temporarily blocked. This would not stop Melissa from propagating one user's address book, but it would prevent the cascading flood pattern.
Subject-line filtering. A small procmail rule rejects any incoming message with Important Message From in the subject line. This is a temporary signature-based filter; it will be useless next week when Melissa variants change the subject. It is useful this week.
Attachment stripping for .doc. Inbound Word documents from untrusted sources are stripped at the relay and replaced with a notice that the attachment was removed for safety. This is more aggressive than I would have done last week. It is, I think, where the operational standard should sit going forward.
The last decision is the controversial one. Stripping .doc attachments will annoy users who genuinely needed to receive a Word document. Several of my friends are not technical and use Word for everything. They will be inconvenienced.
The trade-off, however, is becoming clear: the cost to the operator of accepting attachments is now larger than the cost to users of having to use a different mechanism. Word documents can be replaced with PDFs (which currently do not support macros to anything like the same degree) or plain text. The friction is real but solvable. The exposure is, after Melissa, no longer survivable for serious operators.
What this means for the threat model
A few things, which I do not think were obvious until this weekend.
Macro-bearing documents are executable code. This is technically true and has been since macros were added. It has been operationally treated as not-quite-true, because most macros most people see are benign. Melissa is the public proof that they are not benign in general, and the corollary — all macro-bearing documents are subject to executable-code policy — is now an operational reality.
The address book is now a critical asset. The combination of automated mail propagation and self-modifying templates means a compromised desktop's address book is the seed for a new generation of infections. Securing the contents of address books — keeping them off compromised machines, making them harder to read by arbitrary processes — is suddenly important. Today's operating systems do not really support this.
Self-modifying defaults are themselves a vulnerability. Melissa's trick of lowering the macro security setting silently is the deeper bug. Any application that lets a document modify the application's own configuration is, in effect, allowing every document it opens to attack itself. The fix is structural: documents should not be able to change application security settings, full stop. This is going to take Microsoft years to ship.
What is going to happen next
Melissa is the proof of concept. The architecture — macro virus, automated propagation via the user's own address book — is now demonstrated and, with the source widely circulated, will be reused.
The next thing I expect to see is a Melissa variant with a more aggressive payload. Melissa's payload is essentially decorative — it inserts a quote from the Simpsons into documents. A malicious variant could, instead, encrypt or delete files, install a backdoor, or do any of the things a process running with the user's privileges can do. None of that requires further breakthroughs. It requires only that someone willing to do harm rather than mischief releases the next variant.
Between that and the open question of how Microsoft and the antivirus industry respond, I expect the next 12 to 18 months to be a period of intense and rapid evolution in this category. None of which is good news for operators.
Writing this on Monday evening, with mail still slow at every shop I have spoken to. The single thing I keep coming back to: every previous prediction in this space has under-estimated the speed of escalation. We should plan for the next one to under-estimate it, too.