Subject: [apps-discuss] update to rfc5965

From: Franck Martin <[email-masked]>
Date: Sat, 6 Jul 2013 17:31:34 -0500 (CDT)

http://tools.ietf.org/html/rfc5965 

Specifies the format of Abuse Reporting Format of emails. 

2.d indicates the report should contain either the headers of the reported email as a text/rfc822-headers MIME part or the complete message as an message/rfc822. However if the message reported contains spam, virus, bad links, or in general malware, the complete report is likely to be discarded by the receiver anti-spam filters, never reaching abuse desks for processing. 

It is common amongst security professionals to exchange such dangerous payloads as an encrypted zip file with the common password "infected". This format allows to bypass anti-spam filters as the MTA/MUA is not able to decrypt the attachment to analyze the content. 

It i difficult to request abuse desk to create a separate email infrastructure for [email-masked] and especially to disable anti-spam and anti-virus checks. Some of these addresses are part of email hosted in the cloud. 

I suggest we add the possibility to send the complete email as message/rcf822 email within either an encrypted zip file or within a GPG symmetrically encrypted file, both using the common password "infected". 

The MIME type should be 
message/rfc822-zip-crypt for an encrypted zip file 
message/rfc822-gpg-crypt for the gpg encrypted file 

gpg and zip are widely used on many systems. 

I'm gathering comments, and will tentatively write a draft if no major block is received.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Jul 2013 00:42:27 -0700

Briefly:

On Sat, Jul 6, 2013 at 3:31 PM, Franck Martin <[email-masked]>wrote:

> I suggest we add the possibility to send the complete email as
> message/rcf822 email within either an encrypted zip file or within a GPG
> symmetrically encrypted file, both using the common password "infected".
>
> The MIME type should be
Has anyone implemented this?

It strikes me that putting a specific password in a standards document is
unlikely to fly.  It might be better to include a new media type parameter
to indicate the password used to create the encrypted form.

You'd also need to register the media types in your proposal.  You might
check with the media type reviewer for advice.  I think the new hotness
would be to use "+" where you have "-".

You might also be able to reuse existing stuff like what's in RFC3156.

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Sun, 07 Jul 2013 15:31:56 -0000

Murray S. Kucherawy wrote:

It strikes me that putting a specific password in a standards document
is unlikely to fly.  It might be better to include a new media type
parameter to indicate the password used to create the encrypted form.

I would worry that the same problem Franck's trying to workaround here
would resurface. That is, scanners would read "inside" the ZIP. Of
course, maybe they would anyway with a specific media type and a known
password.

I don't think that a fixed password in this instance is wrong, given
the purpose of the encryption is not actually to encrypt, per-se.

I have to wonder if there's an alternative, like a media type that is
itself defined as base64 encoded, but I note Franck's statement that a
ZIP with a known password is the deployed workaround; standardizing
this running code seems like the simplest option.

Dave.

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2013 18:38:42 -0000

>Has anyone implemented this?

Zip with a known password is a convention in the very small malware
research community, but I haven't seen it anywhere else.

Personally, I don't think that kludges to work around defective
implementations belong in standards.  The problem is that some
organizations run mail to their abuse mailbox through spam filters.
To the extent that a standard should address that at all, it should
say Don't Do That.

R's,
John

PS: I also think that it's hard to think of a worse idea than a standard
way to get malware past spam filters.

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Jul 2013 17:31:44 -0700 (PDT)

> research community, but I haven't seen it anywhere else.

And that's where it should stay. Anything that can be used to
transfer malware to someone who knows how to deal with it can also be
used to transfer malware to someone who doesn't know how to deal with it.

I'm sorry, but the notion of standardizing such a thing is nothing short of
crazy.

> To the extent that a standard should address that at all, it should

Exactly. We keep trying to use standards in these sorts of convoluted ways to
fix problems that can and should be attacked head-on. This is a losing
proposition.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Jul 2013 22:08:10 -0700

On Sun, Jul 7, 2013 at 8:31 AM, Dave Cridland <[email-masked]> wrote:

> would resurface. That is, scanners would read "inside" the ZIP. Of course,
> maybe they would anyway with a specific media type and a known password.
>
>  I don't think that a fixed password in this instance is wrong, given the
> purpose of the encryption is not actually to encrypt, per-se.
>
> itself defined as base64 encoded, but I note Franck's statement that a ZIP
> with a known password is the deployed workaround; standardizing this
> running code seems like the simplest option.
>
>
I'm just thinking that if the common practice shifts to using a different
password, now we need a new RFC that updates the other one.  That doesn't
seem to me to be scalable.

Maybe what we need is a media type whose definition spells out the fact
that the encoding is meant to obscure the content from everything except
analysis software.

-MSK

---

From: SM <[email-masked]>
Date: Sun, 07 Jul 2013 21:43:29 -0700

Hi Franck,
At 15:31 06-07-2013, Franck Martin wrote:
>2.d indicates the report should contain either the headers of the 
>reported email as a text/rfc822-headers MIME part or the complete 
>message as an message/rfc822. However if the message reported 
>contains spam, virus, bad links, or in general malware, the complete 
>report is likely to be discarded by the receiver anti-spam filters, 
>never reaching abuse desks for processing.
>
>It is common amongst security professionals to exchange such 
>dangerous payloads as an encrypted zip file with the common password 
>"infected". This format allows to bypass anti-spam filters as the 
>MTA/MUA is not able to decrypt the attachment to analyze the content.
>
>It i difficult to request abuse desk to create a separate email 
>infrastructure for [email-masked] and especially to disable 
>anti-spam and anti-virus checks. Some of these addresses are part of 
>email hosted in the cloud.

One of the purposes of the report is to inform the operator about 
email abuse.  In my opinion such a message might have usually 
undesirable content.  The problem is that the operator is using a 
content filter for their abuse mailbox.  It is well-known that it's 
not a good idea to do that.  Whether they do that because they are 
using the "cloud" is immaterial.  When something is difficult for 
non-technical reasons it is ample reason not to try to fix it by 
technical means unless profit is all that matters.

Security professionals exchanging dangerous payloads by using with 
encrypted to bypass content filters can be described as being 
realistic or something else.  After all, if security professionals do 
that, other people can do that too.

>message/rcf822 email within either an encrypted zip file or within a 
>GPG symmetrically encrypted file, both using the common password "infected".

The problem is not the suggestion.  It's what will happen after that.

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Mon, 8 Jul 2013 00:38:08 -0700

On Jul 7, 2013, at 10:08 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

> I would worry that the same problem Franck's trying to workaround here would resurface. That is, scanners would read "inside" the ZIP. Of course, maybe they would anyway with a specific media type and a known password.
>  
> I don't think that a fixed password in this instance is wrong, given the purpose of the encryption is not actually to encrypt, per-se.
>  
> I have to wonder if there's an alternative, like a media type that is itself defined as base64 encoded, but I note Franck's statement that a ZIP with a known password is the deployed workaround; standardizing this running code seems like the simplest option.
> 
> 
> I'm just thinking that if the common practice shifts to using a different password, now we need a new RFC that updates the other one.  That doesn't seem to me to be scalable.
> 
> Maybe what we need is a media type whose definition spells out the fact that the encoding is meant to obscure the content from everything except analysis software.
> 
The password could be set as an extra field in message/feedback-report as well as indicated in the text part.

---

From: Franck Martin <[email-masked]>
Date: Mon, 8 Jul 2013 01:00:46 -0700

On Jul 7, 2013, at 9:43 PM, SM <[email-masked]> wrote:

> One of the purposes of the report is to inform the operator about email abuse.  In my opinion such a message might have usually undesirable content.  The problem is that the operator is using a content filter for their abuse mailbox.  It is well-known that it's not a good idea to do that.  Whether they do that because they are using the "cloud" is immaterial.  When something is difficult for non-technical reasons it is ample reason not to try to fix it by technical means unless profit is all that matters.
> 
> Security professionals exchanging dangerous payloads by using with encrypted to bypass content filters can be described as being realistic or something else.  After all, if security professionals do that, other people can do that too.
> 

The problem is that we are moving towards all Internet resources must publish an abuse email address. Abuse desks seldom controls the way email comes into their ticketing system (if any). I was indicating the cloud just as an obvious example.

As for what happens after that? Well the text portion should be explicit enough so that a tier one respondent knows he needs to take precautions.

"This email is in the Abuse Reporting Format. Cf RFC...
One of the attachment contains the email we received in its entirety, because we believe it may contains virus, malware, we are sending it  encrypted with the following password: infected. We suggest you take all the necessary precautions before decrypting and reading this email."

As noted in another email, if we pass the password, this allows automatic processing as well as being able to choose any password.

I would also argue the current ARF puts more people at risk, because a user can simply open the attachment in their mail client, rather than having them to enter a password in another software than the mail client before being able to read the email.

As for miscreants, they can today send encrypted zip files and have done so in the past. I don't see this practice much, so it may not be as effective as they'd like it to be. Anyone has some data here?

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Jul 2013 11:07:16 +0200

> that the encoding is meant to obscure the content from everything except

A string saying *VIRUS*, or anything to that meaning, had better show up
right in the subject, rather than hide somewhere in an entity header.
Ditto for *SPAM*, after Spamassassin experience.

Would that be considered a "typical forwarding prefix"?  Bullet f of
Section 2 seems to be a good candidate for an update anyway.

jm2c

---

From: Franck Martin <[email-masked]>
Date: Mon, 8 Jul 2013 02:20:08 -0700

> Section 2 seems to be a good candidate for an update anyway.
Yes I differ from it, by prefixing "Abuse report for: " so it is clear what it is...

---

From: "John Levine" <[email-masked]>
Date: 8 Jul 2013 16:02:10 -0000

>seem to me to be scalable.

I gather that the proposal here is to 1) invent something, and then 2)
hope that MTA operators around the world implement it.

If we're going to ask MTA operators do change what they do, how about
a simplified one step process where we don't invent anything, and they
adjust their MTAs to stop running abuse mail through spam filters?

R's,
John

---

From: SM <[email-masked]>
Date: Mon, 08 Jul 2013 05:56:35 -0700

Hi Franck,
At 01:00 08-07-2013, Franck Martin wrote:
>As noted in another email, if we pass the password, this allows 
>automatic processing as well as being able to choose any password.

I am not keen about the "automatic processing" part as it is a recipe 
for disaster.

>I would also argue the current ARF puts more people at risk, because 
>a user can simply open the attachment in their mail client, rather 
>than having them to enter a password in another software than the 
>mail client before being able to read the email.

I took a quick look at the current specification and I see a warning 
in the Security Considerations section.  I assume that people 
implementing that specification has read and  understood what it 
means before writing code and before selling that code to abuse desks.

>As for miscreants, they can today send encrypted zip files and have 
>done so in the past. I don't see this practice much, so it may not 
>be as effective as they'd like it to be. Anyone has some data here?

The proposed update might make that practice effective.  I was 
looking for some data.  I don't have anything useful.

These miscreants seem brighter than their counterparts as they have 
managed to circumvent whatever methods their counterparts created to 
thwart their efforts. :-)

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Mon, 8 Jul 2013 12:33:27 -0500 (CDT)

----- Original Message -----
> From: "SM" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Monday, July 8, 2013 5:56:35 AM
> Subject: Re: [apps-discuss] update to rfc5965
> 
> Hi Franck,

How is it different from today, the message is in plain text? In the contrary, I would trust more a machine to process the ARF correctly than some lowly paid "customer success" rep at an abuse desk... 

> means before writing code and before selling that code to abuse desks.

You assume wrong.

There are only two specific software to do abuse desk that I know of:
http://wordtothewise.com/products/abacus.html
http://abusehq.abusix.com/

And they are not widely used

All the rest is for "general support" like RT, which does not treat an ARF email differently from others (AFAIK).

> thwart their efforts. :-)

the Shield and the Sword... but the answer is not let's stop making shields... it is let's make swords.

---

From: SM <[email-masked]>
Date: Mon, 08 Jul 2013 14:06:00 -0700

Hi Franck,
At 10:33 08-07-2013, Franck Martin wrote:
>How is it different from today, the message is in plain text? In the 
>contrary, I would trust more a machine to process the ARF correctly 
>than some lowly paid "customer success" rep at an abuse desk...

The problem was described as being caused by "the cloud".  If there 
isn't any difference there isn't much of a reason for a change.

>All the rest is for "general support" like RT, which does not treat 
>an ARF email differently from others (AFAIK).

Ok.

Regards,
-sm