|
John, the other formats are common (or, were common) on
Macintosh and Unix based systems for binary attachments and for attached
messages. Eudora for Windows used to expose several of these formats for
message construction.
They've fallen into disuse in favour of MIME attachments,
but they are still extant.
Blocking messages containing those attachment formats
may be reasonable for you if you're doing postmaster alerts and can check
whether you've found false positives.
Like Matt, I'm somewhat worried that this technique will
become as common a nuisance as encrypted zips. Until recently, I've put my
faith in the combination of Declude unpacking the attachments (I've assumed MIME
encoding only) and F-Prot's packed and server options to otherwise do message
decoding before virus scanning.
I've been watching for copies of Blackworm that might be
caught on my system so that I check if Declude+F-Prot would catch these other
packing formats, but no luck so far (or rather, I've had the good luck to
receive so few copies in so few formats).
Andrew 8)
Actually, I am
already blocking hqz and uue so I went and added the others and will see what
happens.
John
T
eServices For
You
"Seek, and ye shall
find!"
-----Original
Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of John T
(Lists)
Sent:
Tuesday,
January 31, 2006
5:37
PM
To: Declude.Virus@declude.com
Subject: RE: [Declude.Virus] Encoded
viruses...worried
Matt, are you
saying the attachment as Declude would see it is B64, UU, UUE, MIM, MME, BHX
and HQX? If that is so, what harm would be in blocking those for
now?
John
T
eServices For
You
"Seek, and ye shall
find!"
-----Original
Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Matt
Sent: Tuesday,
January 31, 2006
4:50
PM
To: Declude.Virus@declude.com
Subject: [Declude.Virus] Encoded
viruses...worried
Someone just reported to me that MyWife.d
(McAfee)/Kapser.A (F-Prot)/Blackmal.E (Symantec)/etc., has a 3rd of the month
payload that will overwrite a bunch of files. It's really nasty.
More can be found at these links:
http://isc.sans.org/diary.php?storyid=1067
http://vil.nai.com/vil/content/v_138027.htm
This
started hitting my system on the 17th, possibly seeded through Yahoo!
Groups. The problem is that it often sent encoded attachments in BinHex
(BHX, HQX), Base64 (B64), Uuencode (UU, UUE), and MIME (MIM, MME), and I'm not
sure that Declude is decoding all of these to see what is inside. For
instance, I found that some BHX files that clearly contained an executable
payload, showed up in my Virus logs like so:
01/16/2006 05:36:49 Q7741EFB6011C4F95
MIME file: [text/html][7bit; Length=1953 Checksum=154023]
01/16/2006
05:36:50 Q7741EFB6011C4F95 MIME file: Attachments001.BHX [base64;
Length=134042 Checksum=8624521]
There was no mention about the payload inside of it,
and there almost definitely was. The same attachment name with the same
length was repeatedly detected as a virus later on that day. This likely
was a PIF file inside, though it could also have been a JPG according the
notes on this virus. I, like most of us here, don't allow PIF's to be
sent through our system, but when the PIF is encoded in at least BinHex
format, it gets past this type of protection.
Here's the
conundrum. This mechanism could be exploited just like the Zip files
were by the Sober writers and continually seeded, but instead of requiring
some of us to at least temporarily block Zips with executables inside, an
outbreak of continually seeded variants with executables within one of these
standard encoding mechanisms would cause us to have to block all such
encodings. I therefore think it would be prudent for Declude to support
banned extensions within any of these encoding mechanisms if it doesn't
already. I readily admit that this could be a lot of work, but it could
be very bad if this mechanism becomes more common. This particular virus
is so destructive that a single copy could cause severe damage to one's
enterprise. I cross my fingers hoping that none of this would be
necessary, but that's not enough to be
safe.
Matt
|
