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/
[2] http://investor.synacor.com/
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/
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/
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/
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/
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/
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/
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/
[/opt/zimbra/conf/]opendkim.
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/
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-A0DD
______________________________
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/
Best regards / Mit freundlichen Grüßen
Tim Schughart
IT Security engineer
ProSec Networks
Website: https://www.prosec-networks.co
E-Mail: info@prosec.networks.com
Phone: +49(0) 2621 9469 252
Sincerely,
Phil
Komentarų nėra:
Rašyti komentarą