Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Re: E-Mail viruses
From: Aschwin Wesselius <full-disclosure () illuminated nl>
Date: Tue, 09 Mar 2004 00:13:05 +0100

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 () common com or
joe () attach 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. ;-)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]