Re: VMWare Zimbra Mailer | DKIM longterm Mail Replay vulnerability Feb 02 2016 03:01PM
Phil Pearl (ppearl zimbra com)
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

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:


> 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:
> b=c8dL4dRpnjMeV2OxFbz+1Z2n49PDlUx+XsiodKvmAOh1znOxRW3NDKYk7Bwmlw4
> ________________________________________ 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:

> 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

- --
Zimbra Security Architect
Version: GnuPG v2.0.22 (GNU/Linux)


[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus