-----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-----
