Subject: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 26 Apr 2015 00:34:16 +0900

J. Gomez writes:

 > Yes, the user did it to himself, but what does he know?

Obviously too little to be trusted with an email account.  Fire the
corporate training department!

 > Please note this attack works successfully even if the user has no
 > administrative rights on his computer, and could potentially be
 > made to work equally well with Linux and MacOSX users too (if they
 > were a big enough demographic target to make it profitable vs cost
 > of development).

AFAICS the cost of porting is very low compared to original
development.  I would guess that the real issue is that they don't
have a good way to identify the executable format for the recipient
system, and so send a payload that will work on well over 90% of
recipients.

I also doubt it would work as well on Mac OS X, where the user would
be prompted for his password to confirm permission to execute an
application received from an untrusted source.  Surely some would type
the password, but I suspect enough would be deterred to lower the
click rate to unprofitable levels.

 > The lessons which I think we can learn from this are:

ISTM we already knew the lessons you list, and they inform every
discussion I've seen on this list.

My personal opinion is that, on the contrary, people are already way
too quick to discard proposals simply because they involve changes to
MUAs.  Of course, the reality that this is an IETF WG, and what we can
do that has effect with high probability is change wire protocols.
MUA presentation is outside of our bailiwick, and nobody really has a
good way to get ideas for MUAs broadly implemented the way we can
influence MTA implementations.

 > So I thought this could be of interest to keep in mind, when some
 > solution may be suggested to the DMARC indirect flows problems
 > which advocates some kind of MUA behavior regarding message
 > presentation.

"No Silver Bullet".  There are no "solutions" to these problems, only
improvements.  The fact that *some* users will dig a phish out of the
spam bucket and cut/paste a disabled URL into their browsers so that
they can be victimized despite the best efforts of their mail agents
doesn't mean that others who *would* click if it were presented as
valid mail would *not* go to such lengths for mail in their spam
folders, or perhaps would be deterred at the "cut/paste" stage.

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 25 Apr 2015 19:26:08 +0200

> corporate training department!

Not an option. And sorry but it is not affordable to employ security experts in everyday clerical tasks. So the affected user remains on the payroll, and the company takes the hit in lost productivity because of email being inherently insecure, and because the security experts cannot agree to make it secure after 30 years of Internet email been invented.

> application received from an untrusted source.

I am not so sure, but I cannot test it right now in OS X. From an untrusted source came the ZIP file, but the EXE inside it is --when opened from the ZIP-- temporarily extracted to a $TEMP folder in the user's profile and run from there, so I guess the operating system has no way of knowing whether that EXE running form the user's $TEMP folder came from the untrusted Internet or not.

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 26 Apr 2015 16:23:05 +0900

J. Gomez writes:

 > Not an option. And sorry but it is not affordable to employ
 > security experts in everyday clerical tasks.

It doesn't require *any* *security* expertise on the part of the
clerks to deal with the exploit you described in a business context.

Since it's direct mail, in a business context it's reasonable to
suppose you have a database of qualified vendors including their email
addresses, and one would hope an IT department capable of implementing
DMARC and filtering out URLs not backed by a DMARC pass from a vendor
registered with your company.  Ie, you deal only with companies which
always send DMARC-conforming mail and publish p=reject, and have IT
configure the MTA to quarantine any other mail addressed to clerks
which contains clickable links.

So all the clerks need to learn is to report unclickable links so that
threats can be forwarded to corporate security and unregistered but
valid vendor addresses can be registered.

We already have that exploit beat in the business context; it's now up
to businesses to adopt safe practices.  The problems we must still
address are other problems.

 > because of email being inherently insecure, and because the
 > security experts cannot agree to make it secure after 30 years of
 > Internet email been invented.

The exploit you described is indeed *inherent* in a mail system which
allows mail to be sent from anyone to anyone without previous
acquaintance.  In that context, the mail-reading user is always going
to be the biggest part of the attack surface.

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 26 Apr 2015 11:34:00 +0200

> which contains clickable links.

So before the clerks can arrange to do business with a new Courier (because the old Courier happens to be on strike, or not service an area, or is more expensive for certain kinds of packages), they should have to first vet it through the IT dept. so that IT dept. can whitelist their sending email addresses/domains? And the same for any other provider/client the clerks are going to deal with through email? And the same for the Sales dept., who when following leads by necessity have to deal with not-yet-formally-engaged prospective clients/providers?

Sorry, but real everyday business does not work like this (unless maybe at IBM, some huge University, or the Cuban Government, perhaps).

> valid vendor addresses can be registered.

One clerk (a.k.a. "information-age worker" nowadays) does the workload of four clerks 20 years ago. They are over-worked, they work fast and furious and when, for example, presenting on-line taxes and what-not they usually go by the last day in the tax period. So now the confirmation email to validate their account on the Government on-line taxes web site (which recently moved from https://taxes.ministry.fr to https://taxes.ministy.gouv.fr) is suddenly not clickable, in the last day of the tax period, at 17:45h in the evening? The IT dept. could be better, but they certainly are not suicidal.

Regards,
J.Gomez

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Apr 2015 16:31:40 -0400

On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote:
> MUA presentation is outside of our bailiwick, ......

Stephen,  we (SSI) have the following MUA and/or interface points that 
is still supported:

o Telnet/Dialup console/text-based, 80x25 Vt10x/ANSI interfaces, the 
display fields are generally fixed length and short,  WCX P-code language.
o Web-based mail Client.  WCX P-Code Language.
o Native GUI Mail Client. MFC C/C++
o RFC-based POP3 server interface.  MFC C/C++
o RFC-based NNTP server Interface.  MFC C/C++

and a RPC-based client/server MAIL API with multiple languages 
support, like sysop editor tools written by us and 3rd party 
developers.  It contains a fixed TMsgHeader structure that allows for 
any other client to be written but more importantly represents a 
commonality between all integrated parts and among heterogeneous mail 
network systems.  All systems have a common denominator:

     From:
     Date:
     To:
     Subject:
     -------
     BODY

Today, there are only two requirements in the RFC 2822/5322 format; 
From: and Date:  It was relaxed from RFC822 requiring the To: field as 
well.

Lets not assume that all systems are RFC x822/5322 based. Local policy 
can transform the message and as long as it is not a passthru and it 
has reached its final destination, the backend does have a lot of 
security conscious controls.  That has been the design rule of thumb 
since I wrote Silver Xpress (and offline MUA for Fidonet/Internet) in 
the early 80s.  In our Wildcat! Mail Hosting package, Preserving MIME 
is an SYSOP option, not a requirement for users.  The only reason it 
is now enabled more, is because users are more multi-media ready. MUA 
display rendering was lost in the regeneration of RFCx822/5322 
messages so preserving MIME helps with the WYSIWYG (WIZ-ee-wig) concept.

Also consider that RFC message overhead is getting whack, over bloated 
and wasteful.  I have sysops who will pull the MIME and HTML and 
provide a pure text transformation.  If the special user has a 
Preserve MIME need, a request a made to the operator who will decide 
to set it or not.   3rd party developers have written WCX tools to 
help operators to make it more as a default today.

> ...... and nobody really has a

Its far easier to single source the solution at the backend threat 
entry points.

Lets not forget that the Receiver (including the Mediator receiver, 
not just the end-user  receiver) also benefits by reducing the 
fraudulent mail and blocking them at the door.  Its not about just 
protecting the originator or the end-users.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Apr 2015 10:22:27 +0900

> Stephen,  we (SSI) have the following MUA and/or interface points that 

Knowing what your product *does* is useless to me, unless you provide it
to one or more of the following: AOL, Yahoo!, GMail, Hotmail, and the
Outlook family.  I'm far more interesting in *rationale* (defined as
"arguments more detailed than writing POLICY in all caps") *for design*.

 > Lets not assume that all systems are RFC x822/5322 based.

The Internet is, and that's what we're here to discuss and improve,
no?  If the MDA/MUA functions transform the message, tracking the
information that used to be in the header is their problem.  But to
the extent that MDAs and MUAs preserve and handle the RFC 822 format,
some techniques we consider here may be appropriately recommended to
MUA developers (eg, in a BCP), and may be useful in design of non-
Internet message processors.

 > Also consider that RFC message overhead is getting whack, over
 > bloated and wasteful.

Redundancy is the fundamental constituent of robustness.

In any case, in my INBOX, the median size Internet message is about
20KB, of which about 4KB is header (20%).  However because of spam and
attachments (before saving and stripping attachments) header content
of non-spam is less than 2%, on heavy spam days, well under 1%.  By
contrast, spam, unnecessary office attachments, and quote bloat
probably account for an order of magnitude more "bloat" than headers.

If this "header bloat" causes a real problem in processing, tell us
about the real problem.

 > I have sysops who will pull the MIME and HTML and provide a pure
 > text transformation.  If the special user has a Preserve MIME need,
 > a request a made to the operator who will decide to set it or not.
 > 3rd party developers have written WCX tools to help operators to
 > make it more as a default today.

Obviously users of your product account for a tiny minority of
Internet mail, then, as I personally don't know anybody who would
consider "MIME is more of a default" as adequate for handling their
mail streams.[1]  Even my Emacs-MUA-using colleagues get pictures of
their babies from their spouses and send them to the grandparents.

 > protecting the originator or the end-users.

The problem I'm trying to solve at the moment is not that too little
"bad" mail gets blocked (though that is still a problem).  It's that
current protocols block 100% of "good" mail of certain classes (where
"class" is sufficiently detailed as to include the DMARC policies of
Originator and Receiver).

Perhaps others are more interested in blocking more bad mail than I
am, but AFAICS DMARC has gone as far as possible in blocking bad mail
based on author domain alignment (I really don't think Doug Otis's
proposal to use Sender instead or in addition can help).  I haven't
seen any suggestions to improve bad mail blocking here, except for
your advocacy of stricter "policy", but as a Mediator developer, I
can't be happy about going in that direction without third-party
authorization, and we don't have a consensus on that here, let alone
uptake from DMARC participating Author Domains.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Apr 2015 06:44:50 -0700

On 4/25/2015 8:34 AM, Stephen J. Turnbull wrote:
> Of course, the reality that this is an IETF WG, and what we can
> MUA presentation is outside of our bailiwick,

Exactly.

Which means that an extended thread discussing user behavior is a
distraction from the working group's focus, especially absent careful,
and objective documentation of UCD/UX-related efficacy experiments.

d/

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Apr 2015 13:36:52 -0700

> and objective documentation of UCD/UX-related efficacy experiments.

Dear Dave,

One of the early versions of DMARC included considerations
related to the delivery of messages that fall into the
category of "reject".
,--
Mail Receivers MAY choose to accept email that fails the
DMARC mechanism check even if the Domain Owner has published
a "reject" policy. Mail Receivers SHOULD make a best effort
not to increase the likelihood of phishing if it chooses not
to reject, against policy.
'--

One of the later versions of DMARC cautioned about applying
DMARC policy against user email.  It seems DMARC now expects
to transform SMTP where the identity of the author becomes
less deterministic by being the only identity considered.
The various transformation schemes afford less security by
allowing more ways to obscure the true source of a message
when all that is seen is the From.

When a few domains decide to publish "reject" policies
disruptive for valid and legitimate mediated services do so
by ignoring the role assigned the From and that of the
Sender.  It should not matter how the identity responsible
for actually sending the message is displayed.  It should be
validated where possible and enter into considerations about
whether the message should be rejected and even that the
actual sender be conveyed to recipients when it is not.

At least early on, some recognized a need to mitigate such
disruption where of course, a best effort should not
increase the likelihood of phishing where the actual sender
identity be confirmed.  Something that DMARC currently fails
to provide.  In addition, moving valid messages into
Quarantine folders causes an increasing number of users
dangerously wading through this folder as well.  In this
respect, DMARC is making the problem worse and not better
when DMARC policy abuses valid and legitimate messages by
ignoring the valid role of the Sender for non-transactional
email exchanges.

Regards,
Douglas Otis