==================================================================== CERT-Renater Note d'Information No. 2012/VULN425 ____________________________________________________________________ DATE : 24/10/2012 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running DKIM Verifiers. ====================================================================== http://www.kb.cert.org/vuls/id/268267 ______________________________________________________________________ Vulnerability Note VU#268267 DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust Original Release date: 24 oct. 2012 | Last revised: 24 oct. 2012 Overview DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust when messages are signed using test or small bit signing 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. Vendor Information (Learn More) Vendor Status Date Notified Date Updated Google Affected 22 Aug 2012 23 Oct 2012 Microsoft Corporation Affected 22 Aug 2012 23 Oct 2012 Yahoo, Inc. Affected 22 Aug 2012 23 Oct 2012 If you are a vendor and your product is affected, let us know. CVSS Metrics (Learn More) 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 3,5 CDP:MH/TD:H/CR:ND/IR:ND/AR:ND References https://tools.ietf.org/html/rfc6376 http://eprint.iacr.org/2010/006.pdf http://cwe.mitre.org/data/definitions/347.html http://cwe.mitre.org/data/definitions/326.html http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/ Credit Thanks to Zachary Harris for reporting this vulnerability. This document was written by Michael Orlando. Other Information CVE IDs: Unknown Date Public: 23 oct. 2012 Date First Published: 24 oct. 2012 Date Last Updated: 24 oct. 2012 Document Revision: 33 Feedback If you have feedback, comments, or additional information about this vulnerability, please send us email. ====================================================================== ========================================================= Serveur de référence du CERT-Renater https://services.renater.fr/ssi/ ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + =========================================================