From: full-disclosure at illuminated.nl (Aschwin Wesselius)
Subject: Re: E-Mail viruses

Jorge Daza wrote:

> Other problem that comes to my mind, weak shared secrets might solve the
> problem in some way for spreading massive viruses but not for directed
> attacks. In those cases probably the attacker is already reading the
> email of some or all of the employees, thus she surely knows the secret
> extension. Even if the attacker can't read the email, lets consider the
> strength of a secret that is sent plaintext on every message. Not good.
> 
> Of course this solution can be too complex for home users, that can
> still rely on crypto, but not to receive attachments from people they
> don't even know.
> 
> But I guess it could be implemented in bussiness environments.
> 

I don't know if it is far fetched, but we all know the "Reply-To" header
part........

What about the implementation of something like a "Attachments-To"
header??? An mail client can extract Reply-To headers, so why couldn't
they extract such headers as well?

People can fill in this variable just as they do with the Reply-To thing
If people do have another e-mail address strictly devoted to
attachments, very much under inspection of virus-killers etc., they  can
put that into this field when they fill in their account details at the
time they configure their client. If they don't have any extra's they
can leave it blank of fill it in with the same as usual. Just like a
Reply-To field is handled.

The receiving mail-client can keep track of this field, just as they do
with the Reply-To field. As soon as they attach an extra file, the
client should be aware of this and use the Attachment-To header as the
destination mail-address by default.

The key is the usage of these email-addresses separately. Plain text can
be handled as plain text. Any attachments wich appearantly will be
unwanted, can be stripped of with no mercy by any mail processing
service. Mail addresses with attachments can be inspected by
virus-killers, but anyhow how could a virus-maker depent on an extra
email-address or not? Since it would come in handy when "instructions"
about how to treat the attachment are stripped off at the
attachment-address processing.

So, two separate e-mail addresses (wich doesn't have to be that
different anyhow, up to the admin or user like attach.joe@...mon.com or
joe@...ach.common.com) could make a lot of difference. Only, how could
we get (if approved) these changes into the SMTP protocol???

Another solution, is having people make clear that something in the
header should mention an attachment already (e.g "ATT Subjectline". But
this is, like Jorge already implied not good policy in large businesses
where training and changes could become daily tasks.

Just being creative.....

Aschwin Wesselius

BTW: this is my very first post on the list, so any hints on misbehavior
of the netiquette are welcome. I'm not a security expert, but do have
security in mind. ;-)

Powered by blists - more mailing lists