On the plus side, there are mitigating
circumstances...
First, let me point out that although the antivirus
companies will lag behind the virus authors, the antivirus guys aren't
sleeping.
For many years, the bad guys have been using encoding
methods and 3rd party applications to obfusticate their software as a
cheaper alternative on their time than writing polymorphic code whose very
technique gave them away.
PKLite was probably the first 3rd party tool
used. I've recently seen PAK, UPX and FSG... all three of which were
caught by F-Prot because the antivirus guys simply make signatures for the
binary itself, and don't bother including unpacking methods for all possible
compression/encryption methods. This explains why we have relatively
few upgrades on the engines themselves.
The F-Prot documentation mentions (I think) only zip
decoding, but we know that it certainly does UPX and RAR decoding based on
issues that have been raised with each (for the former, pathetic speed and
the former, a buffer overflow).
If you want to see what your virMMDD.log might reveal
about this latest malware this month and what attachments you're seeing
anyway, try this:
egrep "\.BHX|\.HQX|\.B64|\.UU|\.MIM|\.MME"
vir01??.log
(if you don't want the filename, stick a -h parameter
and a space before that first quotation mark)
By doing this, against my virMMDD.log I just discovered
that F-Prot decodes BHX and HQX attachments too.
By doing something similar against my nightly
virus-scan-the-spam-folder logs I also discovered that I have zero non-viral
messages using the unconventional attachment formats in the last two
months. You can take that as an indication that it's okay to ban those
formats if you wish, but I'll warn that I have a pretty homogeneous Windows
user base.
.... and that's a wrap for
tonight.
Andrew 8)
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