search menu icon-carat-right cmu-wordmark

CERT Coordination Center


DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust

Vulnerability Note VU#268267

Original Release Date: 2012-10-24 | Last Revised: 2016-03-16

Overview

DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust when messages are signed using keys that are too weak (< 1024 bits) or that are marked as test keys.

Description

RFC 6376 states "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. This can be an author's organization, an operational relay, or one of their agents. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message."

1) CWE-347: Improper Verification of Cryptographic Signature: DKIM information is conveyed in an email header called a DKIM-Signature header field. A Signer can indicate that a domain is testing DKIM by setting the DKIM Selector Flag (t=) flag to t=y. Some verifiers accept DKIM messages in testing mode when the messages should be treated as if they were not DKIM signed. From RFC 6376:

t= Flags, represented as a colon-separated list of names (plain-   text; OPTIONAL, default is no flags set).  Unrecognized flags MUST   be ignored.  The defined flags are as follows:   y  This domain is testing DKIM.  Verifiers MUST NOT treat messages      from Signers in testing mode differently from unsigned email,      even should the signature fail to verify.


A DKIM-compliant email client, including web-based clients, should not convey any DKIM-related trust to the user about messages in testing mode.

2) CWE-326: Inadequate Encryption Strength: DKIM signing keys with fewer than 1024 bits are weak. From RFC 6376:
Since short RSA keys more easily succumb to off-line attacks,   Signers MUST use RSA keys of at least 1024 bits for long-lived   keys.


The standard lists other factors that influence the choice of key size, implying that 1024-bit keys are not always necessary if the Signer assumes the risk that smaller keys will not be cracked before the message is verified, the signature expires, or the Signer stops using the key. Note that key sizes up to and including RSA-768 have been factored.

The standard does not require Verifiers to reject signatures made by keys with fewer than 1024 bits, however Verifiers may distinguish between e.g. signatures made with 512-bit keys or 1024 bit keys. It may be an important to recipients to know whether or not a DKIM signature could have been spoofed by an attacker who was able to factor a small RSA key.

Furthermore, a number of RSA keys of fewer than 1024 bits are used in production environments. Check the length of DKIM keys and consider using 1024 bit or longer keys, particularly for long-lived keys.

To identify keys with fewer than 1024 bits or test keys users are advised to inspect the server's RSA signing key.

Impact

It is possible that an attacker could factor the encryption key for a domain that is using DKIM allowing them to sign emails originating from that domain. An attacker may be able to use a test signing key that is treated as trusted.

Solution

System administrators should replace all RSA signing keys fewer that 1024 bits and configure their systems to not use or allow testing mode on production servers.

Users of OpenDKIM are advised to upgrade to 2.6.8 or 2.7.0 and above. The vendor had stated, "In both releases, signatures with key sizes below a configurable limit will be automatically restricted from yielding a "pass" result, and such keys will not be allowed to be used for signature generation. The limit will default to 1024. This applies both to the filter and the library."

Vendor Information

268267
Expand all

Google

Notified:  August 22, 2012 Updated:  October 23, 2012

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

This vendor was reported to have one or many domains affected by either of this vulnerabilities.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Microsoft Corporation

Notified:  August 22, 2012 Updated:  October 23, 2012

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

This vendor was reported to have one or many domains affected by either of this vulnerabilities.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Yahoo, Inc.

Notified:  August 22, 2012 Updated:  October 23, 2012

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

This vendor was reported to have one or many domains affected by either of this vulnerabilities.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Bluehost

Updated:  March 11, 2016

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

There are no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Yandex

Updated:  March 15, 2016

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

There are no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base 4.6 AV:N/AC:H/Au:M/C:C/I:N/A:N
Temporal 3.5 E:U/RL:U/RC:UC
Environmental 6.1 CDP:MH/TD:H/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Zachary Harris for reporting this vulnerability.

This document was written by Michael Orlando.

Other Information

CVE IDs: None
Date Public: 2012-10-23
Date First Published: 2012-10-24
Date Last Updated: 2016-03-16 01:55 UTC
Document Revision: 45

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.