I am curious how network operators are dealing with the latest w32/bagle
variants which seem particularly evil.
Also, does anyone have tools for regexp and purging these mails from unix
mailbox (not maildir) mailspool files? Eg purging these mails after the
fact if they were delivered to user's mailboxes before your virus scanner
got a database update.
-Dan
Quoting Dan Hollis <goemon@anime.net>:
I am curious how network operators are dealing with the latest w32/bagle
variants which seem particularly evil.Also, does anyone have tools for regexp and purging these mails from unix
mailbox (not maildir) mailspool files? Eg purging these mails after the
fact if they were delivered to user's mailboxes before your virus scanner
got a database update.
I am also interested in what network/mail folks are doing about this situation.
Blocking all zip files at the mail level is next to impossible (since of course
when we started blocking executable files, we told people to zip up executables)
and since business can't be taken care of without someone requiring zip files to
pass. I will be the first to admit that using mail as a file transfer protocol
isn't the way to go, but getting people to realize that (and forcing them to
change) is next to impossible.
Brian
The clamav team is doing a great job of keeping up to date with the Bagle
varients, and they've also deployed a couple of generic signatures which
should catch at least some variations as they show up.
As for finding them on the filesystem once delivered, an easy place to
start is "support@$domain" where $domain = your local domain. That seems
to be the one getting the most spread today that I've seen.
I have to admit at least our users seem to be learning (hit them with a
switch (either wooden or 3548) enough and they stop opening everything.
Once nice "feature" of the newer Bagle varients is them seem to lookup
their local domain's MX instead of pulling the MX out of a user's
configuration. Since all of our domains are MX'd to a non-relaying, virus
scanning server, it's helping us keep our users from spreading the joy.
-S
Blocking all zip/exe/pif/etc files - seems to work pretty well here -
granted, it's on a smaller scale (~6k users, ~50k emails/day, ~7k
mails rejected/day, ~7k spam filtered/day)
- d.
Quoting Dan Hollis <goemon@anime.net>:
I am curious how network operators are dealing with the latest w32/bagle
variants which seem particularly evil.
We are currenly blocking *all* .zip attachments as a short-term work around,
until we can modify our virus scanner to block only password-protected zip
files. If anybody has already modified amavisd-new to act in this way, I would
appreciate a hand. I'm *not* a perl person, and my first attempt at changing the
source code has not had the desired effect.
Also, does anyone have tools for regexp and purging these mails from unix
mailbox (not maildir) mailspool files? Eg purging these mails after the
fact if they were delivered to user's mailboxes before your virus scanner
got a database update.
It seems that this virus uses a limited number of subject lines:
# E-mail account disabling warning.
# E-mail account security warning.
# Email account utilization warning.
# Important notify about your e-mail account.
# Notify about using the e-mail account.
# Notify about your e-mail account utilization.
# Warning about your e-mail account.
There's a script, expire_mail.pl, that's userful for this. It's available at
binarycode.org. It can be used
as such:
/usr/local/bin/expire_mail.pl -verbose -noreset -subject "[subject of message
containing virus]" /var/mail/*
Of course, this won't work if/when the virus starts sending out emails with
randomized subjects. Let's hope the that the author isn't reading NANOG. 
-Adam
Turns out that the ZIP file format that all of these beasties are
using is a little bit non-standard. Specifically they are all version
1.0 zip archives and the first (and only) component is not
compressed.
At MIT we are matching these two strings to recognize the infected ZIP
files while letting most (actually I have seen no false positives) if
not all "real" ZIP files. We are matching them anywhere within an
attachment (well, within the first 16K). However you really only need
to see if they are the beginning characters (this is a ZIP file
header).
What follows are the base64 encoded strings. I have put an asterisk
between the first and second character, so my own filters won't reject
this message, do remove that before using...
U*EsDBAoAAAAAA <= Matches unencrypted ZIP file
U*EsDBAoAAQAAA <= Matches encrypted version.
-Jeff
pass. I will be the first to admit that using mail as a file transfer protocol
isn't the way to go, but getting people to realize that (and forcing them to
change) is next to impossible.
Until there's an easy way of getting a file to your friend down the
street that's as easy as sending an email, we're stuck with this.
Curtis
What follows are the base64 encoded strings. I have put an asterisk
between the first and second character, so my own filters won't reject
this message, do remove that before using...U*EsDBAoAAAAAA <= Matches unencrypted ZIP file
U*EsDBAoAAQAAA <= Matches encrypted version.
Hi,
That'll get the current bagle strains, but the thing could mutate further,
setting some of the initial zip header fields differently.
As of today we're blocking all possible encrypted zips, not just bagles,
with this reg-exp:
UEsDB....[Q-Za-fw-z0-9\+/]
checking the start of attachments. Derivation below for anyone who cares.
Cheers
Chris
Dan Hollis [3/4/2004 1:54 AM] :
Also, does anyone have tools for regexp and purging these mails from unix mailbox (not maildir) mailspool files? Eg purging these mails after the fact if they were delivered to user's mailboxes before your virus scanner got a database update.
Others have given you regexps.
Grepmail - http://grepmail.sourceforge.net/ - should help you pull mails matching a regexp out of mbox files, into a separate mbox.
srs
Curtis Maurand wrote:
Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this.
There are actually several, some with features much superior to using
email as the truck.
The problem with them is: Nobody wants to consider them.
Or, like me, nobody knows about them. Maybe its time we educate our
users.
Curtis
** Reply to message from "Laurence F. Sheldon, Jr."
<LarrySheldon@cox.net> on Wed, 03 Mar 2004 22:04:44 -0600
Curtis Maurand wrote:
> Until there's an easy way of getting a file to your friend down the
> street that's as easy as sending an email, we're stuck with this.There are actually several, some with features much superior to using
email as the truck.The problem with them is: Nobody wants to consider them.
Okay, so what are several ways to share files with a friend, where you
don't share any accounts or passwords, and where only your friend will
be able to access them?
FTP'ing to a web site is out - you either have no guarantee that
they'll be the only one to be able to access the file, or you have to
mess with password protected websites, not something a person is going
to do to send the kids photos to Grandma.
Jeff Shultz wrote:
** Reply to message from "Laurence F. Sheldon, Jr."
<LarrySheldon@cox.net> on Wed, 03 Mar 2004 22:04:44 -0600Curtis Maurand wrote:
Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this.
There are actually several, some with features much superior to using
email as the truck.The problem with them is: Nobody wants to consider them.
Okay, so what are several ways to share files with a friend, where you
don't share any accounts or passwords, and where only your friend will
be able to access them?FTP'ing to a web site is out - you either have no guarantee that
they'll be the only one to be able to access the file, or you have to
mess with password protected websites, not something a person is going
to do to send the kids photos to Grandma.
Actually FTP can be made secure.
That and all of the other ideas I might propose require some development
work and some change of attitudes.
Here is the answer igave in private email to fundentally the same
question:
quote
My personal favorite that at one time would have been the easiest to
develop has a MUA that "attaches" the document by storing the text
in an HTTP-accessible archive (on the sender's machine? on the sender's
MTA machine?) and including a URL in the email.
My personal objection to embedded attachments is not a product of the
virus rage going on--it goes back a lot farther and has to do with
system efficiency, security and privacy issues. (Consider a situation
that I have found to common: Person A sends a message transmitting a
document containing sensitive information to person B. For reasons that
make sense, Person A sends "CC" or "BCC" copies to persons C, D, E, and
F.--perhaps to "document" the transmission to B. C-F have no interest in
the document, just the fact that it was transmitted. But the get copies
of it.
A in the process of preparing the message mentions that the document
will be made public at a meeting on a future date.
E realizes that persons G and H need to be at that meeting and
"forwards" the message _and_the_document_ to them. (In one case in my
past, "G" was the last person in Creation that should have gotten the
document early.)
If the message is stored under PKI with A's key all of that and the
system overhead goes away.
There are others.
unquote
In article <20040304163204.8AEF010DA3@gateway.wvi.com>, Jeff Shultz <jeffshultz@wvi.com> writes
Okay, so what are several ways to share files with a friend, where you
don't share any accounts or passwords, and where only your friend will
be able to access them?
Putting the files into an obscurely named and unlinked directory of a website will normally be as good as necessary. The sender still has to mess with ftp, unless he has a web-based uploading system at his disposal (see fotopic.net for an example user interface).
If you are prepared to concede that both parties must be subscribed to the same online community (be it Yahoo-Groups-alike or a messenger product) then the possibilities are endless, and many are not beyond granny's capabilities.
dropload.com seems to me to be the perfect model for anonymous file
delivery over the internet. Their system doesn't use SSL yet, but it
would be the logical next step.
Here is their description:
Dropload is a place for you to drop your files off and have them
picked up by someone else at a later time. Recipients you specify are
sent an email with instructions on how to download the file. Files
are removed from the system after 48 hours, regardless if they have
been picked up or not. Recipients can be anyone with an email address
The whole system uses HTTP for the transfer, no FTP hassles.
Laurence F. Sheldon, Jr. wrote:
Jeff Shultz wrote:
** Reply to message from "Laurence F. Sheldon, Jr."
<LarrySheldon@cox.net> on Wed, 03 Mar 2004 22:04:44 -0600Curtis Maurand wrote:
Until there's an easy way of getting a file to your friend down the street that's as easy as sending an email, we're stuck with this.
[snip]
My personal favorite that at one time would have been the easiest to
develop has a MUA that "attaches" the document by storing the text
in an HTTP-accessible archive (on the sender's machine? on the sender's
MTA machine?) and including a URL in the email.
And how is this going to slow viruses passed around by the mad clickers?
The email has a link they click on and the MUA downloads the message.
This is pretty much how IMAP works anyway, just that the attachment
is available for download at their IMAP server and arrived there over
SMTP rather than some remote HTTP, FTP, or whatever server.
My personal objection to embedded attachments is not a product of the
virus rage going on--
Ah, so this method of delivering content really is not meant to deal
with this.
We have to face it. The only real technical solution I am aware
of is not allowing users to run arbitrary code on their systems. It
looks like if you allow that, someone will be able to socially engineer
enough moro^W users to download malicious code and execute it. C'mon,
the current Bagle strains require the user to unzip the file, manually
enter the password to the zip that's in the message body, then execute
the unzipped file. It's spreading like wildfire. And we wonder who is
gullible enough to buy spamvertized organ enlargement products or fall
for a phishing scam?
Jeff Shultz wrote:
> ** Reply to message from "Laurence F. Sheldon, Jr."
> <LarrySheldon@cox.net> on Wed, 03 Mar 2004 22:04:44 -0600
>
>
> Okay, so what are several ways to share files with a friend, where you
> don't share any accounts or passwords, and where only your friend will
> be able to access them?
[snip]
Actually FTP can be made secure.
That and all of the other ideas I might propose require some development
work and some change of attitudes.Here is the answer igave in private email to fundentally the same
question:quote
[snip]
E realizes that persons G and H need to be at that meeting and
"forwards" the message _and_the_document_ to them. (In one case in my
past, "G" was the last person in Creation that should have gotten the
document early.)If the message is stored under PKI with A's key all of that and the
system overhead goes away.There are others.
unquote
But nothing that's been developed. Joe user's ip address changes on a
regular basis. One would still need to find that machine. DNS gets
cached (some go past TTL's I've set.) and is too static to be an
effective means to get a file.
Most instant messengers have facilities for exchanging files, but both
sides need to be connected at the same time. Having that file in an email
is better.
I like SCP, too. It works well, so well that I use that, instead of ftp.
You still have to find the other end that has its address changed every
day or two. With email, only one end needs to be connected at any one
time. email is about the most convenient and easiest way that I know of
to get pictures of little Johnnie to Grandmother in a way that is easy
for her to understand. Whatever anyone proposes needs to be that easy.
Chances are that Grandma's not a geek like most of us.
Curtis
Too many steps.
Too many steps.
Once it's installed and configured, this one is drag and drop:
<DropChute Letter - Hilgraeve;
They also have a solution for dynamic addressing:
DropChute can work with and connect to dynamic IP addresses through the use of the address server. ldap.dropchute.com. With the address server available to you, you can wait for calls on the Internet using a dynamic IP address assigned by your Internet service provider. Your DropChute will post the address on the address server so others can connect to you.
jc
Curtis Maurand wrote:
Jeff Shultz wrote:
There are others.
unquoteBut nothing that's been developed. Joe user's ip address changes on a
regular basis. One would still need to find that machine. DNS gets
cached (some go past TTL's I've set.) and is too static to be an
effective means to get a file.Most instant messengers have facilities for exchanging files, but both
sides need to be connected at the same time. Having that file in an
email is better.I like SCP, too. It works well, so well that I use that, instead of
ftp. You still have to find the other end that has its address
changed every day or two. With email, only one end needs to be
connected at any one time. email is about the most convenient and
easiest way that I know of to get pictures of little Johnnie to
Grandmother in a way that is easy for her to understand. Whatever
anyone proposes needs to be that easy. Chances are that Grandma's not
a geek like most of us.
In terms of whether the system is open to abuse or not, part of the problem
is simplicity you need to achieve for it to take off in the first place. If
it's simple, it can be automated. If it can be automated it's open to
automated abuse.
(NB/OT: Perhaps the only solution is systems that can detect when they are
being abused and do something to force manual intervention. That could take
whatever form it needs to, from manual account reactivation, more passwords,
or reverse turing tests - depending on which party is required to take
action.
But I don't see systems like this being developed and deployed anytime soon
)