BIMI and DMARC Can’t Save You: The Overlooked DKIM Exploit

Analysts at Zone.eu, one the leading domain registrars and web hosting providers in Europe, have observed a vulnerability affecting the global e-mail ecosystem, stemming from unaddressed warnings in the DomainKeys Identified Mail (DKIM) standard that puts billions of users in risk.

This is not an issue in a particular software product but rather a vulnerability resulting from loose interpretations of the standard across numerous implementations that span the vast e-mail ecosystem.

Using this vulnerability, attackers can create forged emails that still pass DKIM’s cryptographic checks that can then be easily replayed to reach the intended victim. These bogus emails are likely to also pass DMARC (Domain-based Message Authentication Reporting and Conformance) policies. Significant amount of organisations worldwide expect DMARC to prevent certain types of phishing attacks both against themselves but also against their recipients.

The severity of this problem has significantly increased with the advent of BIMI (Brand Indicators for Message Identification). BIMI depends on DMARC to verify the authenticity of messages. As a result, if the message passes all these checks, some email services like for example Apple Mail and Gmail will display a brand logo, but this time next to a forged email. Users are instructed by the UI to trust BIMI-branded e-mails, making these modified letters especially legitimate-looking and trustworthy.

BIMI in Gmail and Apple Mail:

We have confirmed that these attacks are usable in practice by modifying DKIM-signed email messages sent by multiple Fortune 500 companies (among others), for whom email integrity is essential. The forged emails arrived in the victims’ inboxes without any difficulty until recently. Though considering the size of the ecosystem this weakness will linger for a while.

The importance of this issue must be recognized even if a sender or receiver has not implemented BIMI. This is a problem with DKIM, as these forgeries pass DKIM and DMARC. If phishing campaigns take advantage of this vulnerability, it can lead to a global increase in the risk of credentials and data being stolen. Hardening DKIM implementations against such attacks is critical on its own.

Technical synopsis

The DKIM standard (RFC 6376) specifies a parameter for defining e-mail body length (“l=”); this tag informs the verifier of an e-mail message of the number of octets in the body of the received e-mail.

The risks of using the body length limit (“l=” tag) have been known at least since the DKIM standard was published (see RFC 6376 section 8.2), but the described security considerations are incomplete as it looks at the “l=” tag in isolation. Our approach is to find letters that have signatures with the “l=” tag and then to either modify an existing Content-Type header or to add a new one to then replace the displayed content.

In our tests, many senders that use the “l=” tag do not sign the Content-Type header, allowing the attacker to replace it with a specially crafted value without breaking the signature. Unfortunately even if the header is signed, it is usually not double-signed to protect against adding an additional (unsigned) Content-Type header to the letter. How to handle multiple Content-Type headers in a single email message is not well-defined, and as such, implementations and resulting dangers differ.

Our approach to exploiting this weakness is replacing the boundary value in the Content-Type header in MIME multipart emails and adding a new MIME structure that uses the modified boundary at the end of the email. Such modification renders the existing MIME structure into a non-visible comment and forces the email client to treat the added structure as the “real” email content. This results in a larger impact and differs from other previously described approaches.

Simplified illustration of the described attack:

Original email content (with annotations):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=domain.com; l=1234; s=test;
  h=date:from:to:message-id:subject:mime-version; <-- Content-Type not signed
  bh=kDDbMi...; b=K8S4Yk2XjoIvBh...
Content-Type: multipart/mixed; boundary="abc"

<<<Multipart Comment start
This is a multi-part message
>>>Multipart Comment end

--abc
Message MIME structure
--abc--[1234 byte cutoff]

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=domain.com; l=1234; s=test;
  h=date:from:to:message-id:subject:mime-version;
  bh=kDDbMi...; b=K8S4Yk2XjoIvBh...
Content-Type: multipart/mixed; boundary="abc--" <-- modified boundary

[Multipart Comment start]
This is a multi-part message

--abc
Message MIME structure
[Multipart Comment end]
--abc--[1234 byte cutoff]

Faked message MIME structure

--abc----

It should be noted that the first line in this forged MIME structure is still signed, which would bypass simple checks against displaying unsigned content. Such an email still of course passes the signature check, but the client uses the appended MIME structure as the email content, completely ignoring the original content.

If the Content-Type header is part of the DKIM signature, adding an additional Content-Type still enables the vulnerability with many email clients.

Modified email content:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=domain.com; l=1234; s=test;
  h=date:from:to:message-id:subject:mime-version:content-type;
  bh=kDDbMi...; b=K8S4Yk2XjoIvBh...
Content-Type: multipart/mixed; boundary="def" <-- prepended boundary
Content-Type: multipart/mixed; boundary="abc"

The signature validation passes as only the bottom Content-Type value will be included in the signature. Still, the email client might use the topmost value when parsing the MIME structure, making the attack viable.

To mitigate this, the Content-Type header should be protected in the signature (must be added twice to the “h=” tag)

  h=date:from:to:message-id:subject:mime-version:content-type:content-type;

In this case, any additional Content-Type header added to the message would invalidate the DKIM signature. This does make the signature more fragile, but if the “l=” tag is to be used, this is better than alternatives.

Related issues

This is not the first time someone has drawn attention to issues like these, but it has gotten significantly more serious. Similar attacks have been previously described by Stephen Ullrich (“Breaking DKIM – on Purpose and by Chance”), and the team at Valimail (“DKIM Fallacies: Debunking Rumors of DKIM’s Vulnerabilities”). This issue can also probably be combined with other “reskin” attacks such as Kobold letters, making such malleability even more dangerous.

The issues with DKIM signatures do not end here. We have observed senders that only sign the first byte in the body with “l=1” (like for example Maropost), which is dangerous on its own. This is also one more reason DKIM assessors should ignore signatures using the “l=” tag.

The oldest malleable letter we have found (that still has the corresponding public key published) is from 2014 and was sent by Microsoft, in addition to the “l=” tag it also uses SHA1. Keys that have been used for RSA-SHA1 signatures should be discarded and the corresponding public keys removed from DNS. This further highlights the issues with extremely long-lived key material.

Unfortunately it’s not the only problem with old key material. A fair amount of senders still use poorly generated or weak 512-bit RSA keys. As desribed by Hanno Böck (“16 years of CVE-2008-0166 – Debian OpenSSL Bug”), 0.24% of Tranco’s Top 1 Million list still have weak Debian keys published, which is quite dangerous.

Practical examples and impact

Analyzing our email traffic we’ve found multiple prominent examples such as tesla.com, trendmicro.com, bloomberg.net, dell.com, cisco.com, ups.com, dhl.com, ebay.com, panasonic.com, whirlpool.com, hilton.com, norton.com, avast.com, radissonhotels.com that have all sent malleable letters. We would say they’re valuable targets for making forgeries.

So far we have observed millions of DKIM signatures with the length tag, from 3040 different domains, of which 32 pass BIMI checks and have a valid VMC. This contradicts Valimail’s claim that “almost no senders today use the attribute.”

Modified DHL letters (screenshots from Gmail):

Mitigation

The key to fixing this vulnerability and avoiding these attacks is already present in the DKIM standard section under “Security Considerations”: 8.2. Misuse of Body Length Limits (“l=” Tag).

We quote: “To avoid this attack, Signers should be extremely wary of using this tag, and Assessors might wish to ignore signatures that use the tag.” This suggestion must be strictly interpreted, definitely more so than the current wording suggests. Initially at least in the context of BIMI, but ideally it should be completely ignored.

At the same time assessors should currently start rejecting letters with old DKIM signatures in order to mitigate misuse of old signatures, be it this attack or any similar ones. This should however be a temporary solution until the length tag and weak signatures (SHA1-RSA or ≤1024-bit keys) can be completely deprecated and ignored.

E-mail senders, especially those who have used the “l=” tag, should rotate their DKIM keys periodically. If this is not done, old e-mails containing the “l=” tag can still be used to create new forgeries. There are more reasons to rotate DKIM keys than just this vulnerability.

Timeline

• 2024-01-26 – Apple and Google was informed about the problem
• 2024-01-31 – CERT-EE was informed about the problem
• 2024-02-02 – Microsoft was informed about the problem
• 2024-02-08 – Google has confirmed the problem exists
• 2024-03-05 – Apple has confirmed that they’re planning on addressing the issue
• 2024-03-07 – Google has confirmed the problem will be fixed
• 2024-03-21 – Microsoft does not consider this an issue
• 2024-04-05 – Google seems to have implemented mitigations against this problem
• 2024-05-07 – Google proposes public disclosure on the 17th of May

Credits & contacts

This issue was observed by Zone.eu analysts Silver Asu (silver@zone.eu) and Andris Reinman (andris@zone.eu). Taavi Eomäe (taavi@zone.eu) coordinated the disclosure between parties alongside CERT-EE (cert@cert.ee). We thank everyone, including Apple and Google, who collaborated with us in mitigating this issue.