Re: Magistr virus

At 22:26 2001-07-31 -0500, Gregory Berardi wrote:
> http://www.symantec.com/avcenter/venc/data/w32(_dot_)magistr(_dot_)24876(_at_)mm(_dot_)html
Well, reading that, you'll find that the EXE files sent will be smaller 
than 128KB (before infection).  That's at least one aspect you could 
use.  Give it a fudge factor (dunno the size of the virus itself, but 
figure 10-15K would probably handle it - if you have a known EXE attachment 
in your posession, you should be able to ballpark the viral overhead by 
comparing that filesize against the known uninfected version of the same 
program), then don't scan messages which have attachments which exceed this 
size.  Don't forget to factor the 3:4 growth of MIME encoding of course.
The document also states that there is an 80% chance that the number 1 will 
be the second character of the address shown as the sender.  Using scoring, 
you could take this into consideration.
The virus code should contain the phrases "YOUARESHIT" and "YOU THINK YOU 
ARE GOD" "BUT YOU ARE ONLY A CHUNK OF SHIT".  While MIME encoding these (or 
these strings as DBCS), then ignoring the first and last characters of the 
encoded string might normally identify a similar virus, this one is 
polymorphic, so that approach is shot.
> Yes it does mutate the filename and I can't find any "static components" 
> in the mail and was hoping one of you had.
Don't take offence, but generally speaking, every time some great new virus 
comes out, there isn't a discussion about it here - very few viruses 
actually get discussed here on the procmail list.  A search of the procmail 
list archives (see the link from procmail.org) should turn up anything 
which anyone has posted to the list about any SPECIFIC virus.
An approach to dealing with this - and other viruses in general - may be to 
install an attachment scanner - you pass the message with an attachment to 
a program which extracts the attachments and actually scans them for 
viruses.  The scanner would return an error in the event that a virus was 
found in the attachment, and procmail could then bounce the headers and a 
notification to the sender (which in this case may not be a valid email 
address, but hey, at least you tried to notify them), possibly passing 
along a notification message to the intended recipient as well.
Keep in mind that some viruses have certain header characteristics, usually 
intended so that the author of the virus can avoid receiving a bunch of them.
> What I see in the body text is very random.  Possibly exerts from the 
> document that was attached.
Reading the document at the URL you provided confirms this.  Same goes for 
the subject text.
> Removing all executables is really not an option here.
Bummer, since adopting a "we accept no executable attachments - if you have 
a need to send an executable, pack it up in a PKZIP file first", is a 
decent start to reducing viral spread, AND typically reduces email sizes to 
boot.
I'm assuming that you're working for an ISP of a corporate IT department - 
if that is the case, then the argument for installing a virus scanner is 
probably that much easier for you to make.
There are three alternatives to REMOVING the attachment:

        1. Extracting it from the message and putting it into a file on 
the server, then placing a link in the message for the user - esp. if that 
link passes them to a page that advises that executable attachments can be 
dangerous and should not be executed unless the sender is known and 
trusted, and the attachment was EXPECTED.  It should advise the user to run 
A/V software on it (this is in fact something you might be able to do 
online through McAfee).  This method has the benefit of reducing mailbox 
sizes and download times (esp if you have a smart storage system which 
tracks files by their signatures - then multiple copies of the SAME 
attachment file all refer to the SAME single file on the server), though it 
can be annoying for a user who fetches mail then goes offline.  You would 
of course have to write a D/L management interface for your webserver.
        2. Rename the attachment to a non-executable extension, so that 
the user must rename it in order to actually run it.  This is an approach 
used by one of the attachment filters available for procmail.
        3. Prefix the message body with a text block (perhaps in its own 
mime chunk) reminding the user that there is an executable attachment by 
the name of "xxx" in this message which may pose a security threat to the 
users machine if they don't exercise due dilligence.
> Thanks for the link to the testbed.  I'm sure it will be helpful.
If nothing else, it beats the heck out of cramming a script into a live 
mail stream and hoping for the best.
> Sorry, CERT is awful.  I use Bugtraq!
Bugtraq isn't about viruses (then again, neither is CERT, really) about 
security weaknesses in certain software - a totally different thing from a 
"here idiot, click on this attachment" virus.  Code Red appeared there 
because it gains a foothold via a buffer overflow bug in IIS.  This sort of 
virus you're talking about takes control via an idiot at the console, not 
because of inherent software bugs (other than the inescapable fact that 
Windows lacks any process security, but if that was open season, nobody 
would be able to wade through bugtraq).
[snip - the extra footers can and should be clipped from replies]

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail