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
