DKIM and injected headers

If you look at the DKIM-Signature header in any piece of email signed with DKIM you’ll see that one of the fields it contains, the h= field, lists some email header names, for example:

h=From:Subject:Date:To:MIME-Version:Content-Type

Those are the headers that were signed when the mail was sent, and they’re the only headers that will be checked by the DKIM validator. There are some header fields that can occur multiple times, but they’re seldom ones that you’d be interested in signing (if you ever are, check out the DKIM RFC for the details of how that works).
Yesterday I talked about DKIM replay attacks, how replayed messages looked a little odd and had bad To: headers, and mentioned that header duplication might be a problem. You can’t modify a signed header without breaking the DKIM signature – but what happens if someone takes your signed message, adds a new Subject: or To: header in addition to the existing one, and then sends it on to a new set of recipients?
RFC 5322 says that you can’t have multiple Subject or To headers, but violating specifications is where protocol attacks usually get interesting. If the attacker is careful, they can add a second Subject: header and some DKIM validation code will consider the resulting (invalid) message to still be validly signed – the signature says it’s signed one Subject header, and there’s one Subject header that hasn’t changed, so that one validates.
What will be displayed to the end user, if there are multiple Subjects? That’s undefined behaviour – the message is violating email standards, so the MUA could do anything and still be within spec. It could legitimately halt, play La Marseillaise, electrocute the user and then catch fire. More likely, it’ll display one of the two Subject fields – most likely it’ll predictably show either the first one or the last one.
If you’re an attacker trying to hijack someone else’s reputation by replaying signed mail this is a wonderful opportunity – it means that you’re potentially able to replay signed mail, displaying modified To: and Subject: fields to the final recipients, avoiding the red flag of having the recipient not be in the To: field. It might only work reliably for some MUAs, but even if it just worked at Yahoo or Gmail or Hotmail it’d be worth doing.
DKIM has two, slightly opposing, views on what to do about this. The first one is more theoretical: DKIM is only defined for use with email messages, if there are two Subject: headers then it’s not an email message so it’s out of scope for DKIM to even have an opinion on the situation. The operational implication of that is that ISPs receiving should reject any email they receive that violates the email specs before their DKIM validator even looks at it – and it’s likely that ISPs who aren’t already doing this will start being stricter about what violations of RFC 5322 they will accept.
The second is more practical. DKIM allows you to “sign” that a header doesn’t exist – if you tell a DKIM signer to sign, for example, Reply-To: and there’s no Reply-To: field in the message when it’s signed then adding a Reply-To: field will break the signature. And DKIM allows you to sign a repeated header field, just by including it multiple times in the list of fields to sign.
We can combine these two features to enforce that there is only a single, unchanged copy of any given header. To do that, we just need to include the Subject (and To, and From, and maybe others) twice in the list of headers to sign. The first entry is to sign the content of the Subject: header, the second entry is to assert that there isn’t a second Subject: header.
So we’d change from

h=From:Subject:Date:To:MIME-Version:Content-Type

to

h=From:From:Subject:Subject:Date:To:To:MIME-Version:Content-Type

and then any attempt to add additional From:, Subject: or To: fields will break the signature. If you configure your DKIM signer to do that, you’re protected from having those fields tampered with. This is discussed in a bit more rigorous detail in the DKIM RFC.
ESP reputations are being attacked by this approach today. You should consider updating your DKIM signing (and locking down your evaluation accounts) fairly urgently. Don’t forget that these changes only apply to new mail you send out – they won’t prevent an attacker from replaying mail you’ve sent previously unless you rotate your DKIM keys.

Related Posts

DMARC: Please Be Careful!

(Cross posted from Spam Resource.)
Every couple of days, somebody new pops up on the DMARC-Discuss mailing list to ask some question or share an observation. It’s great to see people interested and joining the conversation. Clearly, DMARC interest and adoption are growing. What’s really frustrating, though, is that for about a quarter of the new subscribers, their first mailing list message goes to the spam folder in my Gmail account. It has become sort of an intelligence test I apply to new subscribers — I’ve stopped digging those messages out of the spam folder. I’m figuring that if they can’t figure out how to implement a DMARC record, or they don’t understand that it’s not really compatible with mailing lists nor is it meant for hobbyist domains, then I think perhaps they’ve got some things they’ve got to figure out before they’re ready to join the discussion.
To that end, let me take a moment to jot down some recommendations for folks who are considering implementing DMARC.

Read More

DKIM replay attacks

Replay attacks on DKIM signed messages
When you receive an email validly signed with DKIM by example.com that might not mean that example.com sent the email to you, or that they even sent this email at all.
What it does tell you is that at some point in the past, example.com signed an email with exactly the same headers and body and sent it to someone. That’s often close enough to the same thing. But if that original recipient were to resend the email to you completely unchanged then the DKIM signature would still validate when you received it. That’s not a bug; it’s one of the design features of DKIM that it typically survives mail forwarding.
That original recipient could also forward the exact same email to a million of their closest friends, and the DKIM signature would validate at each of those million recipients ISPs. This is one form of a replay attack, and it isn’t something DKIM prevents.
DKIM doesn’t prevent replay, but does mitigate it
Completely eliminating replay attacks over SMTP is difficult – it’s inherently a store-and-forward protocol, so there’s no way to have the sender and recipient do any sort of handshake to ensure that a particular signature is only used once. It’s not unheard of for email to be delayed for days, and delays of hours aren’t unusual, so allowing a signature to be valid for only a few seconds after it’s sent won’t work. And the design requirement that DKIM signature survive forwarding means that it has to survive the final recipient’s email address not being the same as the email address the mail was originally sent to so you can’t include the envelope recipient in the signature.
So what does DKIM do to mitigate replay attacks? The answer to that is surprising – almost everything DKIM does is there to mitigate them. The DKIM signature depends on the body of the message, the subject line and the content of any other headers the sender chooses to include; changing any of that will invalidate the signature. That means that while anyone can grab a copy of an email sent by, for example, paypal and forward it on to someone else, if they modify the content at all it will no longer have paypal’s signature. So an attacker can’t just grab someone else’s signed email and replace it with modified content – and if they can’t do that, where’s the benefit to a spammer or phisher to replay a message?
But all that work is for naught if you allow the attacker to choose the content before you sign the message. There are several ways an attacker can do that, but one example that’s particularly relevant today is ESP trial accounts.
I’m stealing your reputation
If you allow anonymous signups for trial accounts that let a potential customer try out your system you’ll want to put very tight limits on how it can be used, so as to avoid spammers signing up and spamming through your servers. Maybe you’ll limit the number of email addresses the trial user can upload, or the number of emails they can send. At the most extreme you might even limit the trial account to sending mail solely to the trial users own (confirmed) email address.
But if an attacker can send even one piece of email they create through your trial account to themselves, and you sign that email, they can take it and send it to a million recipients – and it’ll still have your DKIM signature on it so it’ll use your reputation to avoid filters and end up in the recipients inbox. And then the recipients will report it as spam, and all that spam will be counted against the reputation associated with your DKIM identifier. If you share a DKIM identifier (“d=”) across all your customers that could cause all your customer mail to start being rejected or sent to the spam folder. (Even if you don’t it could still affect your delivery negatively, as spam filtering systems – both automated and human – sometimes aren’t entirely rational or predictable).
Spam that’s sent like this will be a little “off”, compared to legitimate email – the To: field won’t have the email address of the recipient, for instance, and there’ll be no personalization in the Subject or body of the message. It’s no worse than most spam, and it’s more than balanced out by being able to hijack someone else’s reputation.
So if you provide any way for unvetted non-customers to send email through your systems you should consider adding some DKIM limitations to the constraints you already have on that mail path. Not signing with DKIM at all avoids the problem altogether, but also means you can’t demonstrate your DKIM prowess to legitimate potential customers. You might want to sign with a DKIM d= domain that’s different to your production signatures, perhaps even a completely different top level domain to avoid any risk of confusion (but don’t try and hide that it’s your domain – that’s what spammers do).
Other operational mistakes
There are some grubby corners of the email and DKIM specs that sometimes interact to cause other holes that this sort of reputation hijacker can exploit. I’ll talk about header duplication tomorrow.

Read More

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Read More