Re: VMWare Zimbra Mailer | DKIM longterm Mail Replay vulnerability

[Phil Pearl <ppearl () zimbra com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Following up inline...

On Sat, 30 Jan 2016 12:13:46 +0100, <t.schughart () prosec-networks
com> wrote:

> Hi@all,
>
> VMWare Zimbra Mailer Release 8.6.0.GA, latest patch and prior 
> versions with DKIM implementation are vulnerable to longterm Mail 
> Replay attacks.

Note: A quick search would show that Zimbra is, two parents, and more
than two years removed from VMware[1].  We're a part of Synacor[2] now.
   [1] https://www.vmware.com/products/zimbra
   [2] http://investor.synacor.com/releasedetail.cfm?ReleaseID=928079

It is also relevant to point out that Zimbra uses OpenDKIM with
Amavisd-new.

The issue(s) may be a bit more generic than this report seems to
indicate, or perhaps I'm missing some nuanced perspective.  For
example, similar issues were mentioned in a more generic fashion here:

  https://wordtothewise.com/2014/05/dkim-replay-attacks/

> If the expiration header is not set, the signature never expires. 
> This means, that the e-mail, perhaps catched while performing a man
> in the middle attack, can be replayed years after catching it.

This does not appear to be a new finding, nor something specific to
Zimbra per se (anecdotal evidence seems to indicate that the use of
"x=" seems to be extremely in practice).  Please note that that
RFC6376 (see x= on https://tools.ietf.org/html/rfc6376#page-24 within
The DKIM-Signature Header Field section) includes this statement,
"INFORMATIVE NOTE: The 'x=' tag is not intended as an anti-replay
defense." In addition, section "8.6 Replay/Spam attacks" (ref:
https://tools.ietf.org/html/rfc6376#section-8.6) suggests the use of
reputation services to help mitigate this type of attack.

> This can be combined with the spoofed reply-to header field, 
> because the header field is not hashed by Zimbras DKIM 
> implementation.

Indeed. While Section 5.4 of RFC6376 (ref:
https://tools.ietf.org/html/rfc6376#section-5.4 Determine the Header
Fields to Sign) suggests signing Reply-To, it also includes a note,
"The choice of which header fields to sign is non-obvious."  Further,
going to Section 3.3 of RFC6377 (ref:
https://tools.ietf.org/html/rfc6377#section-3.3 Current MLM Effects on
Signatures) we find that, "...Some lists will add or replace header
fields such as "Reply-To" or "Sender" in order to establish that the
message is being sent in the context of the mailing list...".

Given this knowledge, it may be more clear why signing on Reply-To by
default can be quite problematic.  In fact, unfortunately, it's not
uncommon to have Subject changed either.  Like many things, DKIM can
be useful, but it isn't a perfect solution and needs to be tailored to
the individual needs of the entities using it.

> Supporter of vulnerability analysis: Steffen Mauer @this point I 
> want to thank Steffen for his good work =)
>
> Background: To configure DKIM with VMware Zimbra the official 
> documentation advises the administrator to use the zimbra 
> management tools. With the management tools there is no possibility
> to add custom Header’s for hashing it with DKIM or for setting the
> expiration DKIM Header. 
> (https://wiki.zimbra.com/wiki/Configuring_for_DKIM_Signing)

The wiki article is more of a howto than a complete how to do anything
and everything you ever wanted with [Open]DKIM.  If one wants to,
despite earlier caveats, set the 'SignatureTTL' (ref:
http://www.opendkim.org/opendkim.conf.5.html) in the
[/opt/zimbra/conf/]opendkim.conf[.in] file with Zimbra they certainly
can although it will not yet be preserved on upgrades as we don't
provide our own custom config attribute for that at this time.

In addition to what has been discussed so far, I would like to call
attention to section 8.15 (ref:
https://tools.ietf.org/html/rfc6376#section-8.15 Attacks Involving
Extra Header Fields) as this could also be of interest.  If a customer
were to be concerned about such an attack, they could modify the
headers being signed to include the same header twice to help mitigate
that risk.  Some may find this of value, others may not.  YMMV, but
again going to anecdotal evidence, signing in this manner does not
seem to be common place.  Again I'll note, if one modifies
'SignHeaders' in opendkim.comf[.in] the customization is not preserved
across upgrades either.  This (lack of) customization preservation
could change in the future.

> ________________________________________ PoC Headerpart: The DKIM 
> Implementation implements the following DKIM Header: 
> Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=0mail.org; 
> s=76820800-C732-11E5-858E-A0DD11F66BE4; t=1454147943; 
> bh=c/tw0mGbL980zPjwnIKgPM7ubA7wLOVGbMr3y9WADOY=; 
> h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id:
 Date:To:Mime-Version;
> b=c8dL4dRpnjMeV2OxFbz+1Z2n49PDlUx+XsiodKvmAOh1znOxRW3NDKYk7Bwmlw4
 5304uFAwLsBl7M1u7mxr/wdp4fZTEQtfJhhUonNJMKDBOxTdiQPOLhcVKC2tEaSLyK
 pqRvtp9ECFFqHstyRHk57UOzMi8PMRusl8lP5B43kY=
> ________________________________________ Report Timeline:
>
> There has been no response from VMware for 14 Days.

Please let me know if I've missed something.  You're welcome to email
me directly.

For future reference:
  https://wiki.zimbra.com/wiki/Reporting_Vulnerabilities_to_Zimbra

> Best regards / Mit freundlichen Grüßen
>
> Tim Schughart IT Security engineer
>
> ProSec Networks Website: https://www.prosec-networks.com E-Mail: 
> info () prosec networks com Phone: +49(0) 2621 9469 252

Sincerely,
Phil
- --
Zimbra Security Architect
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJWsMTTAAoJEJ6e42GP4T0g91cP/19oCiM2twYBY0IESlW5q7k6
oI+GNbq+NI1o4YexdUERs1pAVePnBhxOrTMh2IsrL3HjMXw5QZlHrehxPpW3EvJG
dwPyXwGV9fjWx39RWgF64N2jJp0nkIBBeQA/ukMqBzTfF/GliS+GZVGzPKe8TmVn
KOEVkZ6HYonVWr4A8eyXSaac+mNFv1tHz6de8YCldD4A+MSQHrXSdVJHKt5iz19p
9jMT9SajQj9A0ywUxx4xUSDH7IPt0b8DlG5c+0iPy9e1k7r7j+Pvyyd+9o7gUe4B
CCFyyxnJ0324Dkb+n5U1AEr1ShLam+9YNZQk5fXLnI/gtcsWZqMf3xwjDfk6e3KI
Uhx7KIEeXG2iKHh0dwQwoOrxksbuamrUEjTvXA3OeVf6M9vpIxwNMtQZpiX2cQ9y
W2vOrl4WaeceCpNWV3JSaudcX8oM74qzWq5C1+1bOC1uaO+V4WFzUsHPcArKx5o9
rWQKyxyHAdfq3TVUlm5gw+ZFqGew2Gobb3w2pnrII9PG5jmuQjTN0WWn5e+QyR60
bxNPnQ96FQuNr+wJA8zDF5+4gBMGykmNbykBH7BIjbDEXyZv5sEuTALBiNmXYUtS
gFPuSLv2RF3oXlt0qQEpS3jQWiTtOs98lGRVmmhGEqfJyV6Xtk6t3HhD3nFwaqyZ
mWfZD2gjbemzyebeUbIm
=rs0G
-----END PGP SIGNATURE-----