Antivirus: May 2004 Archives

W32.Korgo.A is a worm that attempts to exploit Microsoft LSASS Windows vulnerability, described in Microsoft Security Bulletin MS04-011.

At a certain point all of these worms going after one vulnerability gets kind of old. Its kind of like shooting ducks in a barrel isn't it? Anyone still not patched kind of deserves what they get if they ignored the first worm.

http://www.symantec.com/avcenter/venc/data/w32.korgo.a.html

Microsoft has provided an antivirus defense in depth guide. http://www.microsoft.com/downloads/details.aspx?FamilyID=f24a8ce3-63a4-45a1-97b6-3fef52f63abb&DisplayLang=en

I don't quite understand why they choose to make documents available via MSI. Do I really need to get yet another item in my start menu just to read a pdf? The first thing I note after installing the document is that the pdf is 666 KB. Apparently this antivirus document is of the devil.

This is a long document that begins with a brief definition and history of viruses, and moves on to many best practices that should be implemented. It is well worth a read.

We do it all the time. We dont want to take the time to close all of the applications, shut down the system and have to wait for it to boot when they get into the office. So we use standby or hybernate to save some time. What kind of security problems could this cause?

The first item of concern is that users aren't running the login scripts of their corporate domains. Many companies use a login script to deploy patches and antivirus, or just to gather information about what is out there.

Secondly, when systems are put into standby or hibernate, the programs they are running at that time, continue to run when the system is resumed. Most viruses write themselves to hard drive and configure the system to launch the virus at each boot. But I cant help but think about SQLSlammer. Viruses that stay memory resident are tough for antivirus to detect. If you suspend, the virus is being walked right into the network. If you had shut down the system, a virus like slammer would no longer be a problem.

The traditional model of antivirus management on the SMTP gateway overloads the average users mailbox with unnecessary and confusing messages.

Originally, virus laden email were otherwise legitimate messages that just happened to contain a macro virus in a word document or something similar. It was desired therefor to clean the virus from the message and ensure delivery of the non-viral content. At the same time it was important to notify the sender of their virus infection so they could get the problem rectified.

The problem with this approach is obvious today. Viruses today have moved beyond the simple macro virus. Instead they are self-generating and contain no redeeming content that the user would want to see. The problem first manifested itself in unnecessary calls to the help-desk. The user would be worried that they received a message with the "subject" and the "from" line that we warned them about!!! Of course, if they had opened the message they would see that the attachment had been removed by the anti-virus software. Messages like this really waste the end users time and also the time of the help-desk. The problem came to a head with swen.a as some unlucky user accounts received thousands to 10s of thousands of virus messages, all appropriately defanged by the anti-virus software. This was basically a denial of service attack that could have been prevented if the anti-virus software ate the offending message.

The other side of the problem is the forged sender problem. Most email worms pick random return addresses. Antivirus systems that follow the old model and send a warning back to the supposed sender are generally going to be bothering an innocent party.

So what do you do about it? You dont want to participate in harassing innocent third parties, yet you dont want to harass your own employees. Common sense says you shouldn't drop email messages down a rabbit hole. The compromise position is, if a message contains a virus do not deliver to the employee. If the virus is a network worm, then there is no need to tell the sender or recipient about the problem (there is no legitimate content). If the virus is not a network worm, then it is ok to tell the sender that their message was not delivered and why (we blocked it because it contains virus x in file y). This is a simple matter of adding a flag in the virus definition to describe which viruses are email worms. Many vendors have that now, and others are moving toward that model.

This will help cut down on the completely unnecessary mail traffic associated with many email viruses. Unfortunately, this will not stop the problem completely as not everyone will be running a good anti-virus product. Users will still receive email bounces (no such email address), and notifications for file removal for mail that they did not send. Until SMTP messages are secured in some manner (look into SPF) there isn't anything that can be done on that part of the problem.

Not all antivirus companies respond to new threads, and put out new definitions with equal allacrity. With a network worm like Sasser, it isn't quite as important to have the new definition quickly because you aren't preventing exploitation. Rather you are helping clean up after the fact, and if you are incredibly fortunate, preventing future infection.

A German site, took note of the virus definition release times for several prominant antivirus firms.

This link may work otherwise the content is below. (translated from german) http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=de_en&url=http%3a%2f%2fwww.pcwelt.de%2fnews%2fviren_bugs%2f39734%2findex.html
Note, I've used babelfish to translate from german to english, so this may sound like engrish.

Win32/Sasser.A: So fast the AV manufacturers reacted

Most anti-virus manufacturers reacted quite fast to the new threat. Only the Ikarus virus utilities could recognize the Win32/Sasser-Wurm by heuristic also without updates. The response times of the other offerers find you in the table (all data in Central European summer time).

RAV 2004-05-01 - 07:35
Dr. Web 2004-05-01 - 07:45
F-Prot 2004-05-01 - 08:00
Bitdefender 2004-05-01 - 08:30
F-Secure 2004-05-01 - 08:35
Sophos 2004-05-01 - 08:55
AntiVir 2004-05-01 - 09:35
Avast 2004-05-01 - 09:45
Norman 2004-05-01 - 11:15
Trend Micro 2004-05-01 - 11:25
Panda 2004-05-01 - 11:55
Quickheal 2004-05-01 - 12:05
Symantec 2004-05-01 - 12:05
AVG 2004-05-01 - 13:15
InoculateIT VET 2004-05-01 - 13:35
ClamAV 2004-05-01 - 15:05
InoculateIT CA 2004-05-01 - 15:05
COMMAND 2004-05-01 - 17:05
Virusbuster 2004-05-01 - 17:10
Fortinet 2004-05-01 - 17:45
McAfee 2004-05-01 - 18:45
Kaspersky 2004-05-01 - 19:10
Esafe 2004-05-01 - 19:55

McAfee (BETA) 2004-05-01 - 05:20
Symantec (BETA) 2004-05-01 - 06:35
F-Secure (BETA) 2004-05-01 - 08:15
Trend Micro (BETA) 2004-05-01 - 11:25
Panda (BETA) 2004-05-01 - 11:35

What I see from these numbers is that McAfee and Symantec beat everyone if you include what they call beta defs. I suspect that the smaller companies put out defs, to get them out the door and the later released further updates to get it right. Symantec and McAfee dont have that luxury. They need their update to work across multiple platforms/products and be right the first time (although they often miss that goal).

The Dabber worm attempts to exploit the buffer overflow in the ftp server left by the Sasser worm.

The SANS Internet Storm Center has reported it to be in the wild. It was first reported by http://www.lurhq.com/dabber.html

Fortunately Sasser turned out to not be such a big deal for most companies. After these major incidents, I think it is important to take a look back to assess what worked well, what didn't work and whether we dodged a bullet through luck or skill.

1. Patches Patches Patches Patches
Companies that stayed up to date on patches were more likely to stay out of trouble with sasser. The April 2004 patches were more problematic than most patches for the past year. Some companies held off patching due to reports of bad experiences. With nothing else in place, that left them vulnerable.

2. Personal Firewalls cover a multitude of sins
If a personal firewall is in place, it can block access to these worms. This allows the administrator to take more time to test the patches and role it out in a gradual measured fashion. That is always preferable to the chinese firedrill that can occur at outbreak time.

3. Know they network. How will you know when you are infected? If your answer is when the routers get knocked offline, the servers yo-yo and the helpdesk line is ringing off the hook, you are in deep trouble.
Host based IDS and Network IDS along with honeypots and centralized logging are all ideas that could provide insight into the corporate network.

4. Plan now for what needs to happen in a virus emergency.
Rod Trent of myitforum.com had a good question recently. Are you the single point of failure in your enterprise patch management or your enterprise security?

It seems like every time I go on vacation or even attend a conference there is a major virus incident of some type. If you are the single point of failure, you need to document what you do in case of virus outbreak, you need to communicate that documentation to others.

5. Education
I dont think education is the cureall of security vulnerabilities. But I'm not willing to abandon it all together. Most people want to do the right thing. If you tell them what that is, and it isn't too much of a hastle for them, they might actually follow the policy. I think that one thing that helped in this sasser incident was the amount of press coverage it received. That caused a few users who otherwise might have connected their laptop to the network to instead contact the help desk.

To summarize, a secure network is so much more than keeping the antivirus up to date, and posting a security policy on the company intranet.

A buffer overflow has been discovered in the FTP server used by the sasser worm. An infected computer sets up a FTP server on an obscure port so the machines it attacks will connect back on that port. This port is what is vulnerable to a buffer overflow.

The F-Secure weblog points out that this is a bit of overkill since a machine infected with Sasser is likely still vulnerable to the LSASS exploit anyway. So its not clear if this is just a point of amusement, or if there really is a large segment of machines that got patched but were already infected.

This may be part of the ongoing snipeing between the netsky writer or writers and mydoom.

An 18 year old German student has admited to creating the sasser worm. Right now it isn't know how he was caught or if he is responsbile for every varient of the worm. Some virus experts have postulated that the sasser worm author was also responsible for the netsky worm. I find it likely that he only borrowed their code.

While it is cool they grabbed this kid so quickly, I do not agree with the antivirus experts who predict this will slow down further worm development. The dumb high school punk worm writting contingent wont be phased by this recent arrest. Also the people who actually know anything have removed themselves from exposure to authorities and are unlikely to be discovered. Remember the big arrest related to blaster? It turned out to be a punk kid who released a worm that didn't get widespread circulation. He was so sloppy, he was practically picked up before the worm was in circulation.

- update -
In this AP article http://apnews.myway.com/article/20040508/D82ELAKG0.html the police report that this guy did do all 4 varients of sasser and also did netsky.a (likely all the netskys).

Looks like he talked too much and was nabbed by someone wanting the Microsoft virus writters bounty.