A recent post by German software developer and security researcher Steffen Ulrich claims that it’s possible to create emails that pass both DKIM and DMARC validation, but which show malicious content controlled by an attacker and not signed by the message’s DKIM key.
Ulrich rightly summarizes the importance of SPF, DKIM, and DMARC in preventing sender spoofing, which is frequently used to make a phishing email “more credible since it seems to come from a known and trusted sender.” In fact, domain spoofing is the largest single technique used by phishers, and it’s particularly pernicious, since in the absence of authentication it’s possible to make the phishing emails look very credible indeed.
However, Ulrich’s post zeroes in on a couple of supposed vulnerabilities to DKIM that are not very significant in practice.
The first supposed vulnerability he describes is the possibility of inserting multiple Subject and other headers, giving an attacker the ability to reuse a DKIM-signed set of legitimate headers but have the mail include an alternate versions of these headers.
Even if successfully exploited, for almost all headers this simply has the effect of causing the message to display improperly — not very useful to an attacker.
The one header that may be hypothetically displayed to the recipient is an altered Subject. That’s more significant, but still of limited utility to an attacker. But in practice even this exploit isn’t much of an issue. it’s telling that Ulrich’s test bed is Thunderbird, an email client with a very small user base. (It’s not in the top 10 email clients worldwide and its market share is certainly well below 1 percent.) In addition, his test system uses the independently developed Thunderbird DKIM plugin for validation, not the DKIM signature result from GMail.
That’s because modern mail services like GMail, Office 365, and others are aware of these kind of issues. So when they detect multiple Subject headers, they may fail authentication of the message, redirect it to spam, display a warning, or take other actions.
Moreover, if a sender is really concerned about this kind of edge-case exploit, and is concerned that the receiver will not be sophisticated enough to address it, the DKIM RFC provides clear guidance on how to use oversigning to prevent this issue at the source.
A second potential vulnerability Ulrich highlights depends on the use of the optional “l” (lowercase L, for “length”) attribute in the DKIM signature, which can be used to limit how much of the message body is signed. The l attribute is a vestige of an earlier era in Internet email, when the majority of messages were short and text-only. The l attribute was meant as a way of allowing messages to pass DKIM authentication even if a forwarder or other service had appended a footer, which was once common practice.
As Ulrich notes, even the authors of the DKIM standard recognized that the l attribute was a risky and not particularly effective way to solve that problem.
As a result, almost no senders today use the attribute, and email best practices advise against it. Those few senders that do use it should eliminate it, because they risk accidental authentication failure, just as Ulrich notes. Finally, Ulrich notes that DKIM occasionally breaks when mail systems translate 8BITMIME-encoded messages into 7-bit ASCII. As he observes, this is only occasionally a problem, and only when such messages transit servers that don’t support 8-bit MIME, such as 1&1 or AOL. It’s important to note that this issue (affecting a very small number of messages) isn’t a vulnerability of any kind — it’s just a case where DKIM signatures should pass, but may fail. There are a few other such edge-case situations as well, and while they are unfortunate, they don’t impact the overall reliability of DKIM and related email authentication protocols. In reality, Ulrich has “discovered” a few legitimate, real-world operational issues with DKIM, all of which the email industry has been aware of for some time and has been addressing. He has not, however, discovered any new vulnerabilities, and his post doesn’t outline a workable vector that an attacker could actually exploit. Photo credit: dvanzuijlekom/Flickr via Photopin